On Tue, Jul 21, 2015 at 11:12:13PM +0200, Jerome Martinez wrote: > 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.
That's the approach used mostly for audio codecs. Video codecs are supposed to follow specification instead (if there's one). > 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." Most specifications I've seen concentrate on decoding point of view, encoders are supposed to produce compliant bitstream but it's really up to decoder to decide what to do with a non-compliant input (try to decode anyway/error out/launch tetris). > - 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. Even one truly independent implementation is enough IMO. Even better if one party implements an encoder and another party implements a decoder from the specification and they test how well those implementations work with each other. > 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. That's the best way indeed. > Please comment. done _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
