[FFmpeg-devel] [PATCH v6 2/5] libavformat/mxf: Add ULs for DNxUncompressed

martin schitter ms+git at mur.at
Mon Sep 16 08:02:47 EEST 2024



On 15.09.24 20:26, Tomas Härdin wrote:
> tor 2024-09-12 klockan 07:52 +0200 skrev Martin Schitter:
>> +    { { 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x07,0x01,0x00 }, 14,      AV_CODEC_ID_DNXUC }, /* DNxUncompressed/SMPTE RDD 50 */
>> +    { { 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x1e,0x01,0x00 }, 14,      AV_CODEC_ID_DNXUC, NULL, 14 }, /* DNxUncompressed / SMPTE RDD 50 */
> 
> Why are they different?

these are two different keys:

The first one from 'mxf.c' represents the "SMPTE Label for 
DNxUncompressed Picture Essence Coding" described in chapt. 9 / p. 30 of 
the standard, while the second one in 'mfxdec.c' stands for the "SMPTE 
Label for DNxPacked Essence Container Identification" from chapt. 8 / p. 29.

I can only find the second key in my sample files generated by DaVinci 
Resolve v19. The first key is just taken from the specification without 
any real world verification.

Nevertheless, there is en error in the 8th byte of the second one.
The correct entry should be:

   '06 0e 2b 34 04 01 01 0d 0d 01 03 01 02 1e 01 00'

I already fixed this error in an earlier version, but because of all 
this stupid patch rearrangements and code juggling it somehow reappeared 
again. :(

Hopefully no other changes are effected in the same way. I have just a 
very vague idea, how it could happen at all.

But thanks to your accurate review at least this line will be fixed 
again in my 7th patch set.

martin


More information about the ffmpeg-devel mailing list