[FFmpeg-devel] FOMS 2009 FFmpeg outbrief
Mon Jan 26 22:23:45 CET 2009
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'
- keep the API/ABI as consistent as possible
- fix .pc (package config files)
- less dependency of libavformat on libavcodec would be welcome
- detail API/ABI changes would be very very welcome
- bump a version number every time needed, even for small API/ABI changes
e.g. AVMetadata changes didn't bump version
- feature probing API (to find out supported formats/other
functionality from the libraries rather than guessing from version
e.g. get_fourcc() would simplify this:
- 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
And maybe some more. There were a few rather specific issues raised
but I have left these out because
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.
More information about the ffmpeg-devel