[Matroska-devel] [FFmpeg-devel] [libav-devel] Remote participation options for IETF session on MKV/FFV1 at July 22 @ 9 CEST
jerome at mediaarea.net
Tue Jul 21 23:12:13 CEST 2015
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
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
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
More information about the Matroska-devel