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

[Jerome Martinez]

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).