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