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

[James Almer]

On 3/2/2017 11:47 AM, Tobias Rapp wrote:
> On 02.03.2017 15:22, James Almer wrote:
>> 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.
>> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.1
> 
> The IETF draft explicitly excludes to specify FFV1 version 2:
> https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.8.1
> 
> IIRC there have been some edits to remove references to version 2 in the IETF draft. In the older document at http://www.ffmpeg.org/%7Emichael/ffv1.html#configuration-record the section contains "version >= 2".
> 
> Regards,
> Tobias

Well, that makes things a bit more complex.
Maybe the Matroska spec should follow and also avoid mentioning v2?
That way we could just pretend those files don't exist and not bother
trying to drop their extradata during muxing.