[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