[FFmpeg-devel] [PATCH] FFV1 specification: Add more details about the configuration record

Michael Niedermayer michaelni at gmx.at
Thu May 14 00:48:00 CEST 2015

On Wed, May 13, 2015 at 11:34:45PM +0200, Jerome Martinez wrote:
> Le 13/05/2015 21:58, Michael Niedermayer a écrit :
> >Does the text somewhere say why just avi and mp4 are listed as
> >containers ? (i didnt spot that but i might have missed it)
> They are the only containers I know supporting FFV1 (Matroska is not
> listed here because it does not support FFV1 directly: it uses the
> AVI compatibility layer, so currently implementation in Matroska is
> defined by implementation in AVI + definition of AVI compatibility
> layer in Matroska)
> It is not possible to be exhaustive, there is no standardized way to
> say that "if there is a configuration record, it must be at here",
> and e.g. for MOV the glbl box is never defined in Apple specs not in
> ISO specs, it is specific to FFmpeg even if it is aimed to be used
> for all formats requesting a configuration record.
> If by chance ISO accepts FFV1 in MP4, they could request that the
> configuration record is in a "fv1C" box or other change instead of
> the glbl box... Usually the file format maintainer writes rules but
> if I understood well what happened in the case of FFV1 in MP4/MOV,
> FFmpeg decided to use "home made" glbl box and I try to write such
> reality in the specification, not easy.
> So this is case per case, file format per file format, I list what I
> am aware of.
> Are you aware of another possible container for FFV1 and supported
> by FFmpeg?

nut and ffm surely work too

> >  It should make it clear that these are not the only containers
> >supported but that nearly any container can be used
> Agreed.
> Is it OK with:
> "This configuration record can be placed in any file format
> supporting configuration records, fitting as much as possible with
> how the file format uses to store configuration records. The
> configuration record storage place and NumBytes are currently
> defined and supported by this specification for the following
> container formats:"


> Note: when I finish to technically update the specification, I'll
> ask a native English speaker for reviewing the whole spec.


> LyX Document
> >[...]
> >>@@ -2728,7 +3056,7 @@ if( version < 2 )
> >>  \begin_inset space ~
> >>  \end_inset
> >>-FrameHeader01( )
> >>+if( keyframe && !ConfigurationRecordIsPresent)
> >is it better to add indirection here instead of spelling out that
> >its version < 2 ?
> at this moment of the parsing, version is not defined in the case of
> a bitstream conforming to version < 2 (it is defined just after).
> In the current FFV1 specification, it does not make sense (version
> is tested before being defined)
> I don't see how to describe correctly the bitstream with "version < 2" here.

hmm ok


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150514/744b1fb7/attachment.asc>

More information about the ffmpeg-devel mailing list