[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Måns Rullgård]

Robert Swain <robert.swain at gmail.com> writes:

> 2009/1/26 Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org>:
>> On Monday, 26 January 2009 at 17:26, Robert Swain wrote:
>>> 2009/1/26 M?ns Rullg?rd <mans at mansr.com>:
>>> > "Ronald S. Bultje" <rsbultje at gmail.com> writes:
>>> >> However, I honestly don't think making releases will change the
>>> >> complaining about ffmpeg at all. It would be so good if they would
>>> >> interact in and contribute to this discussion.
>>> >
>>> > Given that most of the complaints are invalid, e.g. the API hasn't
>>> > changed nearly as often as they say, there really isn't much we can
>>> > do.  If people want to make up false claims about FFmpeg, and then
>>> > complain about them, they'll keep doing that no matter what we do.
>>>
>>> The apathetic approach won't encourage progress. I strongly recommend
>>> documenting the API changes and how to transition between them,
>>> coupled with svn revisions of the version bumps as suggested by
>>> Stefano earlier in the thread. This gives some evidence to argue
>>> against the claims rather than us saying that it's invalid and them
>>> complaining that it's unstable. Eventually this knowledgebase will be
>>> popularised if we keep pushing it and the fud will stop.
>>
>> I strongly agree. There's still a lot of misconception originating from
>> over three years ago being repeated around. I try to correct it whenever
>> I come across it being mentioned, but I've been told that it'd be better
>> if "the developers" cleared it up prominently on the homepage.
>>
>> Regular releases, even if they don't get more testing than SVN HEAD,
>> along with clearly documented API changes will surely calm many
>> confused minds.
>
> I just had a chat with some of the videolan developers to see if I
> could get them involved in this discussion. We ended up having a
> discussion off list, but these were their points:
>
> - stop renaming/moving public API files/their contents for 'internal'
> consistency
>   e.g. http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.c;h=2d67ef75703068983a65447b186c9448f9e640b6;hb=HEAD#l38

We've done that ONCE.  It's unlikely to happen again.  The old layout
was causing problems of its own too.

> - keep the API/ABI as consistent as possible
>   e.g. http://git.videolan.org/?p=vlc.git;a=commitdiff;h=0a778174db0192075a3194fb05b06a034ad940d2
> - fix .pc (package config files)

That's impossible until all those who demands this agree on what the
correct files should look like.

> - less dependency of libavformat on libavcodec would be welcome

That's an orthogonal issue.  Besides, changing it would mean *massive*
API/ABI breakage.

> - detail API/ABI changes would be very very welcome

svn log avcodec.h etc...

> - bump a version number every time needed, even for small API/ABI changes
>   e.g. AVMetadata changes didn't bump version
>          http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=66c05cd02ee454bba603feccf69f5dcc7239021a

Backward compatible changes don't need a major version bump.  Updating
the minor number when things are added is of course nice since it lets
apps check for a specific number before using some feature.  We try to
do this, but sometimes people forget.

> - feature probing API (to find out supported formats/other
> functionality from the libraries rather than guessing from version
> number and
>   other information)
>   e.g. get_fourcc() would simplify this:
> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/fourcc.c;

That table maps lavc codec IDs to VLCs internal ID system.  Are they
really suggesting that *we* supply ID tags internal to *every* app
that uses lav*?  Or just to them, selfishly?

> - releases will not improve version consistency from distros as
> distros control the versions of software they package and they all use
> different versions of the same software

Quite.

-- 
M?ns Rullg?rd
mans at mansr.com