On 10.09.24 15:14, Tomas Härdin wrote:
+++ b/libavformat/mxf.c
+ { {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x1E,0x01,0x00
}, 16, AV_CODEC_ID_DNXUC }, /* DNxUncompressed/SMPTE RDD 50 */
Are really all 16 bytes significant?
I have to correct myself again:
This Entry in the "PictureEssenceCoding" list of 'mxf.c' should
according to the specification look like:
+ { {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x07,0x01,0x00
}, 15, AV_CODEC_ID_DNXUC }, /* DNxUncompressed/SMPTE RDD 50 */
The significant bit count is set to 15, because we do not support any of
the extended fix point format variants.
But in practice I couldn't find such an entry in any of my test samples
generated by DaVinci Resolve until now.
btw. there is an annoying flaw in the ffmpeg mxf parser:
The very common 'fill' boxes, which are used in DNxUncompressed files to
align 'pack' boxes on 265 byte boundaries, are not recognized by ffmpegs
mxf parser and generate lots of
"Dark key 06.0e.2b.34.01.01.01.02.03.01.02.10.01.00.00.00" warnings.
Martin
_______________________________________________
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".
