On Wed, 11 Sep 2024, Tomas Härdin wrote:
ons 2024-09-11 klockan 01:08 +0200 skrev martin schitter:
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.
Ah, didn't know. But this happens often with ULs. One must carefully
read the wrapping spec!
Actually it should match 14 bytes, because byte 14 defines the codec
being DNXUC. Byte 15 defines the "profile" of the codec (standard format,
or extended fixed point formats), but from the demuxer's point of view it
is irrelevant what profiles / codec features ffmpeg's own decoder
supports. E.g. the user might use the demuxer only and decode the essence
on its own.
Regards,
Marton
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.
Patch welcome ;) But surely we already deal with KAG fill? Maybe the UL
for it just has too large a matching length.. But looking at
mxf_metadata_read_table[] and searching for "fill" it appears we don't?
/Tomas
_______________________________________________
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".
