[gst-devel] [gst-cvs] thomasvs gst-ffmpeg: gst-ffmpeg/ gst-ffmpeg/ext/ffmpeg/

[Edward Hervey]

Hi all again,

 So I've been spending the past 4 hours on attempting to update the
local mirror and an idea came up.

 Why do we need this mirror ? Because the API/ABI/CodecList/FormatList
changes constantly in ffmpeg because of lacks of releases (although
they have some kind of versioning internally).
 But does that really mean we have to have OUR mirror ? Can't we just
specify a ffmpeg revision number against which we can build ?
 Out of the patches currently in our mirror , we have:
 * one for implementing autotools support. Well ffmpeg has got a
simili-configure script which does enough (has the options we need).
 * one for not installing some libraries/tools. Same thing, we can
configure ffmpeg in the same way.
 * some patches that have been merged upstream in the meantime.
 * a patch for removing all the deprecated keywords so we can compile
our ffmpeg mirror with -Wall -Werror.
 * some patches for minor issues that should have been submitted
upstream a LONG time ago (one patch is from 2005 !
http://bugzilla.gnome.org/show_bug.cgi?id=173044).

  I seriously disagree that having those patches (mostly unneeded, or
that should be commited upstream) and the burden a maintaining a
mirror outweighs just checking out a specific revision of ffmpeg and
spending some time insisting on some critical patches going into
ffmpeg.

 Since ffmpeg doesn't want to do releases, I think we should *play the
same game*. Namely : gst-ffmpeg cvs will only work with ffmpeg svn.
Then when we do (pre-)releases, we mark which ffmpeg revision number
that release was done against and ffmpeg will ONLY be able to link
against that specific version. This might require not updating our
dependencies
 This comes to the same as having a mirror... without all the hassle
of maintaining it our side. It would then be up to distro packagers to
take the burden of making sure which release/revision of gst-ffmpeg
they need depending on what ffmpeg version they have installed
system-wide.

 Also, it wouldn't be too much trouble creating a build-slave that
compiles gst-ffmpeg against a trunk checkout of ffmpeg anytime there
is a ffmpeg commit. This would enable us to figure out as early as
possible when there is a change in the API/ABI and change gst-ffmpeg
accordingly.

 In order not to penalize people following our releases and so
tracking bugs doesn't become hell, we would bundle the ffmpeg svn
checkout that we known works with the given release, in more or less
the same way it is done currently (replace checkout of the mirror by a
specific revision checkout of ffmpeg), and we would ONLY support
gst-ffmpeg bugs built with that internal ffmpeg. Up to the package
maintainers to triage bugs their side, check they can reproduce those
bugs with a support gst-ffmpeg, and then post bugs upstream.

  I would like feedback on this idea, since this would remove a LOT of
burden on our side, should satisfy a lot of people, and would make
gst-ffmpeg releases more frequent, more up-to-date and hopefully with
less security issues.

   Edward

> On 2/14/07, Sebastian Dröge <slomo at circular-chaos.org> wrote:
> > On Mi, 2007-02-14 at 14:00 +0100, Thomas Vander Stichele wrote:
> > > On Wed, 2007-02-14 at 01:48 -0500, Ronald S. Bultje wrote:
> > > > Hi Edward,
> > > >
> > > > On Feb 14, 2007, at 1:32 AM, Edward Hervey wrote:
> > > > >  We all now it's a very bad idea and it took us a LONG time before
> > > > > even allowing it. The conditiong on allowing people building on
> > > > > external ffmpeg was that we would NOT support those versions (we can
> > > > > see the difference since the plugin description is different).
> > > >
> > > > Ah, thanks for explaining. I hope you explained how bad an idea it is
> > > > given ffmpeg's non-api/abi stability and lack of proper versioning,
> > > > in addition to non-api things such as codec behaviour, required
> > > > version-specific workarounds and codec wrapping?
> > >
> > > Yep, it was explained to all these distro people, and at the moment
> > > their decision leans towards using a shared ffmpeg for vlc, mplayer,
> > > xine and gstreamer.
> > >
> > > AFAIK this is being done in livna (fedora), debian and ubuntu, and
> > > possibly other distros.
> >
> > gst-ffmpeg in Ubuntu and Debian is still using the internal ffmpeg copy
> > because of all the issues mentioned in this thread. For Debian this will
> > change for next release as Loic explained but for Ubuntu I'm not sure if
> > just keeping the interal ffmpeg copy and caring for security updates is
> > less work than handling all bugs that are reported against gst-ffmpeg.
> >
> > xine/mplayer/vlc are built against the system's ffmpeg though because
> > their cases are much simlper...
> >
> > > I have a hunch they will step back when people start complaining that
> > > none of these versions actually work well, or work well randomly.
> >
> > I hope that instead the ffmpeg people see the advantage of a stable
> > API/ABI and do proper releases... well, one can dream ;)
> >
> > Bye
> >
> >
>
>
> --
> Edward Hervey
> Multimedia editing developer / Fluendo S.A.
> http://www.pitivi.org/
>


-- 
Edward Hervey
Multimedia editing developer / Fluendo S.A.
http://www.pitivi.org/