Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: fixed jp2k_rsiz and 240M matrix

[Marton Balint]

On Sat, 5 Jun 2021, Valerii Zapodovnikov wrote:

Again. 240M matrix is different from BT.601! And 170M is the same
as BT.601. It is primaries that are the same in 240M and 170M, as
for jp2k_rsiz see page 10 of S422M-2006. Yes, IT IS THERE.
---
libavformat/mxf.c    | 2 +-
libavformat/mxfdec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 85a65f8718..7c355d789b 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -132,7 +132,7 @@ const MXFCodecUL ff_mxf_color_space_uls[] = {
    { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x05,0x00,0x00 
}, 14, AVCOL_SPC_RGB }, /* GBR */
    { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x06,0x00,0x00 
}, 14, AVCOL_SPC_BT2020_NCL }, /* ITU-R BT.2020 Non-Constant Luminance */
    /* alternate mappings for encoding */
-    { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x02,0x03,0x00,0x00 
}, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_SMPTE240M */
+    { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x02,0x01,0x00,0x00 
}, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_BT470BG */

    { { 
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 
},  0, AVCOL_SPC_UNSPECIFIED },
};
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 3bf480a3a6..9e92ef4175 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -330,7 +330,7 @@ static const uint8_t mxf_encrypted_triplet_key[]           
= { 0x06,0x0e,0x2b,0x
static const uint8_t mxf_encrypted_essence_container[]     = { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0b,0x01,0x00 
};
static const uint8_t mxf_sony_mpeg4_extradata[]            = { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00 
};
static const uint8_t mxf_avid_project_name[]               = { 
0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf 
};
-static const uint8_t mxf_jp2k_rsiz[]                       = { 
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00 
};
+static const uint8_t mxf_jp2k_rsiz[]                       = { 
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00 
};

Where does the original UL come from? Because based on the original patch 
which added this key, I don't think it is a typo, it looks like this key 
was added for a specific reason. So the better approach seems to be to 
rename the old key to something like mxf_jp2k_rsiz_alternate, and check 
both the official key and the old key.

Also splitting the two changes to two patches would be nicer...

Thanks,
Marton

static const uint8_t mxf_indirect_value_utf16le[]          = { 
0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
 };
static const uint8_t mxf_indirect_value_utf16be[]          = { 
0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
 };
static const uint8_t mxf_apple_coll_max_cll[]              = { 
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x0e,0x20,0x04,0x01,0x05,0x03,0x01,0x01 
};
--
2.30.2

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".