[Ffmpeg-devel] Re: time for a release?

[Michael Niedermayer]

Hi

On Fri, Dec 16, 2005 at 07:07:06PM +0100, Reinhard Tartler wrote:
[...]
> >Michel Bardiaux mbardiaux at mediaxim.be wrote:
> >>>it's been a while since the last release and since then there has
> >>>been a lot of development and many new features have been added to
> >>>FFmpeg along with fixes for a good deal of bugs.  In short, I think
> >>>it's time to make a new release.
> 
> >It does not make sense to issue a 'release' since at the first bug 
> >report regarding the 'release', the reply will be 'use cvs'.
> 
> Well, one big problem we currently have (and other distrubtions as
> well!) is that ffmpeg does not provide a stable API or ABI. This makes
> it very difficult to package programs which use ffmpeg. The interim
> solution projects like xine and mplayer choose is to include copies of
> CVS snapshots from ffmpeg. This is a nightmare to support, because for
> every security update has to update each package on its own.

a stable API&ABI would reduce but not solve this because some projects
dislike PIC/shared libs due to the speed loss

so if you/someone seriously want to help, there are the following things to do
* API/ABI stuff
 * subscribe & read ffmpeg-dev/cvslog and help us designing flexible and
   stable APIs and ABIs for the various parts
 * complain when API/ABI compatibility is broken, suggest alternatives if
   you know any
* PIC/shared libs
 * fix gcc so it generates less retarded code
 * learn how all the PIC/ELF stuff works and think about how it could be done
   more efficiently, for example IIRC every static & global variable has its
   own entry in the GOT table, so not only do you loose 1 register (ebx on 
   x86) to point to the GOT but every access to a global variable needs you
   to look at th GOT, thats silly as things within one lib shouldnt move
   relative to themselfs, but then maybe iam wrong somehow iam no PIC expert


[...]
> Since ffmpeg is used in quite a lot of projects, I'm pretty sure that
> there actually are people interested in backporting fixes from CVS to a
> stable release, which go towards a point release.

if there where a volunteer there would be releases! or how should we have
been able to stop all volunteers from maintaining there own releases of
a free software project like ffmpeg?


[...]

> The problem now is, that we do want to support software like xine and
> mplayer, but we cannot, because they include 'problematic' parts of
> ffmpeg. If they could rely on a stable ffmpeg, so that they don't need
> to maintain an own fork of ffmpeg, it would be a lot easier for us to
> support those packages.

how many users would actually use a player without mpeg*/divx/h26* support?

[...]
-- 
Michael