On Tue, Jul 21, 2015 at 04:10:23PM -0400, Dave Rice wrote: > > > On Jul 21, 2015, at 2:59 PM, Michael Niedermayer <[email protected]> > > wrote: > > > > On Tue, Jul 21, 2015 at 02:03:16PM -0400, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Tue, Jul 21, 2015 at 12:58 PM, Kostya Shishkov > >> <[email protected] > >>> wrote: > >> > >>> On Tue, Jul 21, 2015 at 11:52:55AM -0400, Dave Rice wrote: > >>>> Hi all, > >>> [...] > >>>> The FFV1 specification work may also be reviewed at github [5] with > >>> recent rendering in HTML [6] and PDF [7] available. To participate in the > >>> current standardization efforts of FFV1 please visit the ffmpeg-devel > >>> mailing list [8] or the #ffmpeg-devel [8] IRC channel on freenode. > >>> > >>> I'd suggest that any standardisation includes not only "specification" but > >>> also an independent implementation - it helps to figure out what's wrong > >>> with > >>> the specification and maybe gives a small standalone library instead of > >>> something spread out on half a dozen files in a large software project. > >> > >> > >> +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). > >> > >> Thank you Kostya. > > > > that makes sense for future versions but not for past ones > > There is a large number of existing ffv1 files out there. > > Now most likely spec and implementation match anyway but assuming they > > do not match for version 1 then there are 2 options > > A: change the spec for version 1 > > B: change the implementation for version 1 > > IMHO I'd propose option A in most cases. IIRC, the implementation of version > 1 of FFV1 came before the specification for FFV1 was in development and the > goal of the specification is to properly document the implementation. Also > the implementation of version 1 had some sort of event (the removal of the > experimental flag > http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b548f2b91b701e1235608ac882ea6df915167c7e) > that signified a form of official status. The specification of version 1 > started years later (2012?) and has been in gradual development with no event > or commit that has signified that the specification is official. IMO the > implementation of version 1 is complete and in use and the specification > continues to be under development to define the implementation. At some > point, hopefully after enough eyes verify that the implementation and the > specification match, the specification should be marked as official (ideally > through an open standards organization). Still it seems wise to, a > s Opus did, declare what happens if a mismatch between the spec and the > implementation is discovered at a later point.
C: go for version 2 standardised and implemented sanely (or FFv1/A :) I'd like to point out that creating a new implementation when you know what you do is not hard in this case, modifying current decoder to support such profile/modification should be trivial too. > > If now all implementations match and just the spec mismatches then > > > > If the spec is changed it would probably affect noone > > Presently MediaArea is tasked with developing a conformance checker with > FFV1. Jerome has attempted this work solely off of the specification and not > the implementation, but the specification is not sufficiently > self-descriptive to support developing another implementation without a > review of the existing implementation. This issue is why we had initially > proposed a standardization project. Welcome to my world. I've seen enough incomplete specifications, specifications that simply contained source code (VP8...) or specifications that told you to look at the source code (DTS tables...). This one has a good chance to become one of those too. > > If the implementation is changed then suddenly there are 2 > > interpretations of what version 1 means and possibly no easy way to > > find out if a existing file used the old or new one (as both would > > claim to be version 1). That would be really bad, especially for a > > lossless format. > > Agreed. Lossless format? With CRCs embedded too? It does not sound that hard to test whether decoder interprets input correctly. And encoders abusing or violating standard are quite common for widespread formats anyway. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
