[FFmpeg-devel] FOMS 2009 FFmpeg outbrief
Mon Jan 26 23:05:05 CET 2009
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'
> 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*
> - 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
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:
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
mans at mansr.com
More information about the ffmpeg-devel