[gst-devel] [gst-cvs] thomasvs gst-ffmpeg: gst-ffmpeg/ gst-ffmpeg/ext/ffmpeg/
Thomas Vander Stichele
thomas at apestaart.org
Wed Feb 14 17:55:23 CET 2007
> 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.
AFAIK the plan was always to develop these patches then send them
upstream. The autotools one was commited upstream I think (Ronald ?),
and so could be removed.
> 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
> 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.
I think this idea conflicts with what you said above. Either you pick a
specific revision and fix bugs against that to avoid regressions, or you
track svn, in which case you are *forced* to take the regressions.
The goal of this game is simple: deliver gst-ffmpeg modules of ever
increasing quality without any regressions. Whatever system that makes
this the easiest is pretty much fine.
Tracking a specific revision with which we work (which is what we used
to do *before* we allowed compiling against external ffmpeg) is one way
of doing that - you theoretically mostly have patches to fix regressions
they have in their upstream.
Tracking TRUNK is guaranteed to give you regressions, doesn't sound like
a good idea to me.
Both are orthogonal to the issue of "do we actually submit our patches".
But in the end, the proper way to maintain local patches for a
non-trivial amount of time is to maintain these patch sets as separable
> This might require not updating our
> 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
Not sure how your idea solves the distro problem ? If gst-ffmpeg always
follows trunk, they won't be able to pick a release that matches
whatever snapshot they took any more than when we pick a revision for
> 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
API/ABI is the least of our worries. Sure it is annoying, but you get
told at build time. The worry is about feature regression.
More information about the gstreamer-devel