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?
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.
this is not an indirection for nothing, this is avoiding to use a single
field for different purpose: version is for indicating the version, not
for knowing if there was a configuration record.
this is the reason I propose to have 2 different fields: 1 for version,
1 for knowing if there was a configuration record before the parsing of
a frame.
This does not prevent the decoder to use a different algorithm, but a
specification is not optimized code: saying that version is < 2 before
we read version from the bitstream is not correct from my point of view
(we don't know the version because we did not read it, so we can not say
that version is < 2).
From my point of view, this is also more future proof: you may decide
that version 5 can accept both cases (with or without configuration
record), it would be easier to update the specification (with "version <
2", you forbids forever any new version without configuration records).
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
