[FFmpeg-devel] [libav-devel] Remote participation options for IETF session on MKV/FFV1 at July 22 @ 9 CEST

[Jerome Martinez]

Le 21/07/2015 20:03, Ronald S. Bultje a écrit :
> +1. I can't stress how important this is. In addition, the spec should 
> be the master, not any one implementation (because then the bugs in 
> that one implementation will "be" the spec, regardless of what the bug 
> is). 

In theory, spec should be the reference, I totally agree.
In practice, both Matroska and FFV1 formal specifications show up after 
these formats are widely used, without relying on any specification. So 
saying that the specification is the reference does not make a lot of 
sense here.

I argue for:
- previous and current versions: specifications are more an official 
state of the art and we try to have a specification the most 
"compatible" with most used tools. If 2 tools are incompatible, we 
discuss with developers case by case about the best method for fixing 
the incompatibility and we write the decision as part of the 
specification. Example of specification which takes care of 
compatibility with files in the wild: "O is a reserved value. Encoders 
MUST NOT store bits_per_raw_sample = 0. Decoders SHOULD accept and 
interpret bits_per_raw_sample = 0 as 8."
- next version: the spec is the master, not any one implementation, and 
we have 2-3 independent implementations ready *before* the formal 
release of the specification.

FYI, we are on the way of having a completely independent FFV1 
parser/decoder in libmediainfo and a complete Matroska and FFV1 
conformance checker tool, without relying on other libraries (e.g. 
ffmpeg, libav, libmatroska) so we hope to catch any issue in the specs 
and/or files created by other tools before the formal release of 
specifications.

Please comment.