[FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

James Almer jamrial at gmail.com
Thu Mar 2 16:22:41 EET 2017

On 3/2/2017 6:28 AM, Nicolas George wrote:
> Le primidi 11 ventôse, an CCXXV, James Almer a écrit :
>> Ah, i see there's generic code to read and write CodecPrivate elements
>> to and from raw extradata for native codecids where no special handling
>> is required.
>> In any case, the spec says
>> "For FFV1 versions 2 or less, Private Data SHOULD NOT be written."
>> The ffv1 encoder creates extradata for v2 and newer, so the muxer
>> should have a custom case for ffv1 in order to detect v2 streams and
>> avoid writing said extradata.
> I have not looked myself at the situation, I only read what you wrote
> her. According to it, it seems here the FFV1 encoder is violating the
> specification and needs to be fixed.

I can't say if the encoder exporting extradata for version 2 is right or
wrong, as muxers or bsfs could still use it for whatever reason, but at
least according to the draft ffv1 spec by Michael, it's to be stored at
the container level *only* on versions 3 and above.

Michael probably knows best if version 2 is supposed to export this
extradata or not, and if what's currently exported is correct to being
with or not (I see for example that the encoder stores a crc value for
all versions that the decoder in turn purposely skips for version 2).

> The way I see it, we should try to make muxers as generic and
> codec-independent as possible. Most cases where we have codec-specific
> code in muxers are when someone bungled the design, usually an
> industrial committee (but do not ask me how the Ogg people managed to
> make something even worse).
> There are several ways to interpret the quote of the spec above:
> 1a: Encoders SHOULD NOT return extradata to the application.
> 1b: Applications SHOULD discard extradata returned by the encoder.
> 2a: Applications SHOULD NOT give extradata to the muxer.
> 2b: Muxers SHOULD discard extradata given by the application.
> IMHO, the only reasonable one is 1a; it achieves automatically 2a and
> makes 1b and 2b completely unnecessary.

The quote is from the container spec, so it defines muxing and demuxing
guidelines only. If anything, the quote is closest to 2b.

> Regards,
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list