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

Michael Niedermayer michael at niedermayer.cc
Fri Mar 3 01:17:13 EET 2017


On Thu, Mar 02, 2017 at 04:43:27PM -0500, Dave Rice wrote:
> 
> > On Mar 2, 2017, at 9:59 AM, James Almer <jamrial at 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.

agree too and thx

also anyone wanting to know about version 2, the best reference is
probably what the source does 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170303/aa0a55d8/attachment.sig>


More information about the ffmpeg-devel mailing list