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

[Dave Rice]

> On Jul 21, 2015, at 2:59 PM, Michael Niedermayer <michael at niedermayer.cc> 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 <kostya.shishkov at gmail.com
>>> 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, as Opus did, declare what happens if a mismatch between the spec and the implementation is discovered at a later point.

> 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.

> 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.

> IMO if there ever is a difference found, the exact case and difference
> need to be carefully analyzed and all options considered with what
> impact they would have on implementations and users

[...]

Dave Rice