[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Aurelien Jacobs]

Robert Swain wrote:

> 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

Here they have a variant to #include <ffmpeg/avcodec.h>.
This is wrong and never was meant to be used this way.
They should instead use #include <avcodec.h> with -I/usr/include/ffmpeg
(or similar).

> [...]
> - detail API/ABI changes would be very very welcome

I agree we could improve on this.

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

This is on purpose.
The new AVMetadata API is not finished and will change.
I plan to bump version number when the API will be "finalized".
Until then, people must not use this new API, and if they use
it anyway, they shouldn't complain about API/ABI changes.
This was clearly explained in initial commit message:
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=0cf9fbf0d9ff9c3ba714678903a995fc00e5712b

> I'm now having the idea that maybe it would be a good idea to audit
> how FFmpeg's APIs are used in major programs/libraries (VLC,
> GStreamer, xine, etc.). I think this would provide insight as to where
> examples and documentation are lacking. If something is being done
> wrong, we should document why doing it their way is wrong and how it
> should be done.

I agree, but this is time consuming, and it may not be that easy to
find a volunteer for this.

Aurel