[FFmpeg-devel] FFv1.3 standardization

Luca Barbato lu_zero at gentoo.org
Sat Oct 27 20:19:45 CEST 2012


On 10/27/2012 07:39 PM, Michael Niedermayer wrote:
> Hi all
> 
> On Sat, Oct 27, 2012 at 12:09:14PM -0400, Dave Rice wrote:
>> On Oct 19, 2012, at 2:18 PM, Luca Barbato wrote:
>>
>>> On 10/19/2012 04:36 PM, Dave Rice wrote:
>>>> Have you seen the initial work here: https://github.com/FFmpeg/FFV1
>>>> Also: http://www.ffmpeg.org/~michael/ffv1.html
>>>> Also: http://www.ffmpeg.org/~michael/ffv1-draft/ffv1.html
>>>
>>> yes and that's why I want it moved in a format less strange (lyx is not
>>> common) and documented in a way that is more readable: the current draft
>>> is not understandable by people not having experience with code and in
>>> that case it still looks strange.
>>
>> If not lyx do you propose another format? Texinfo?
>>
>> Also some of the recent commits related to ffv1 also pertain for the specification. Rather than drafting the ffv1 specification within the current github space at https://github.com/FFmpeg/FFV1, would it make more sense to develop ffv1's specification within the libav/ffmpeg projects themselves (such as in http://git.libav.org/?p=libav.git;a=tree;f=doc and http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc)?
> 
> The official FFv1 spec is in lyx format at https://github.com/FFmpeg/FFV1
> its also available as html, txt, pdf and can trivially be converted
> to pretty much any other format one might want.
> http://www.ffmpeg.org/~michael/ffv1.html
> http://www.ffmpeg.org/~michael/ffv1.txt
> http://www.ffmpeg.org/~michael/ffv1.pdf

I already stated lyx is a poor choice for collaboration since few people
use it and it isn't any less cumbersome than plain latex.

> If someone, luca? wants to improve it in some way, its very easy to
> clone the git repo on github and change it to their hearts desire.
> Then just send me a pull request and ill make sure the changes get
> reviewed and integrated. The official FFv1 spec is actively
> maintained by me.

I'll keep reformatting what you write in the wiki so other can edit it
to make the whole specification easy to understand.

> about the suggestion of moving it to a wiki, i belive a wiki is a
> poor choice for a specification as a specification must be correct and
> a wiki allows too broad and unchecked editing. We wouldnt want someone
> reword text in it that she might find hard to understand but that
> after the rewording then turns out to have totally different meaning
> and resulting in incompatible implementations.

Wiki is easy for everybody to format and edit, once the result pleases
all the interested parties I'd like to have the specification redacted
in xmlrfc and send to the IETF.

Once that is done there isn't any problem.

> about submiting it to a standards body, i think thats a great idea but
> we first should finish 1.3, converting the spec for this to the needed
> format seems a minor technicallity to me but maybe iam missing
> something

My suggestion is to:

- use the wiki to hopefully come up with a document easy to understand
  and describing the actual format.
- foster interest and get somebody to make another implementation that
  is completely unrelated.
- collect all the inputs from the experience and redact the xmlrfc
- send it to the IETF

> Either way, i see it with great concern that libav started writing a
> ffv1 spec in their doc directory and has already introduced changes
> to ffv1 without any kind of discussion on the nut mailing list.
> seeing that and then seeing libav developers contact you in private
> about moving the spec to a different place and format. Iam not sure
> what i should be thinking about that.

You are confusing NUT with FFV1.

I'm one of the few supporters and active users of NUT. I have vested
interests in have NUT working better and support the features I need.

I'm following FFV1 even if I'm not using it only because I consider it a
decent format and got asked to help, I got contacted in private and I
answered questions and spent time over it out of good will.

lu



More information about the ffmpeg-devel mailing list