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

Michael Niedermayer <[email protected]>
Newsgroups gmane.comp.video.ffmpeg.devel,gmane.comp.video.libav.devel,gmane.comp.multimedia.matroska.devel
Message-ID <20150721185934.GF4728@nb4>
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

If now all implementations match and just the spec mismatches then

If the spec is changed it would probably affect noone

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.

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


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.

_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
signature.asc (application/pgp-signature, 181 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlWulpYACgkQYR7HhwQLD6tg+wCeKA1Oqx+2I09KORVIgOwA7w7g
dvIAniPRvUnjOJJ9qN4slbHw4F1a/nt8
=d4nR
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.