> On Mar 2, 2017, at 9:59 AM, James Almer <jamr...@gmail.com> wrote: > > 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.
I agree. In the FFV1 spec, it is careful to say that it intentionally does not describe FFV1 version 2. I will submit a patch to the Matroska specification to avoid using relative language based on version 2. Dave Rice _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
