[FFmpeg-devel] [PATCH v4 2/4] libavformat/mxf: DNxUncompressed MXF related changes

[Tomas Härdin]

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