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!
> 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".
