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

[martin schitter]

On 11.09.24 21:41, Marton Balint wrote:
>>> 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.

Yes -- that's indeed a good point!

It also makes the error report for unsupported variants more expressive, 
when we only later deny processing in the decoders main dispatcher based 
on their unique fourcc entry.

I was just irritated by this statement in the standard:

   "A Picture Coding Variant code of 02h shall not be used with any
   standard float 10- or 12-bit component values. All other fourcc codes
   are permitted in either variant."

But this advice will only be of importance during muxing and encoding. 
Demux and decoding implementations can silently ignore these subtleties.

Martin