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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
