Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Sat, Dec 16, 2006, A Mennucc wrote:
> BTW: after etch is release, you (AFAICR) are willing
> to update gst-ffmpeg to use DynLEF (as Josselin was proposing).
Yes, but only because it was merged upstream, and with the additional
maintenance costs it involves. BTW, an upstream developer already had
an issue building against his own local ffmpeg, and upstream also
claimed they would close any bug from people using Debian's ffmpeg
instead of the copy of ffmpeg in gst-ffmpeg.
> so we should all join forces: you , me, Sam, xine people, totem people...
I'm a maintainer of totem, but totem isn't affected directly, it's only
using xine-lib and gstreamer, not ffmpeg directly in any of the two
flavors.
> for example, in last year ffmpeg people enhanced support for h264, and
> they claim a +10% in speed ; since neither gst-ffmpeg was updated, not
> ffmpeg-in-Debian itself, MPlayer-in-Debian-etch will be the only program
> enjoying those updates.
If ffmpeg's upstream doesn't offer a way to pull stable releases with
only bug fixes and performance improvements, I can understand that
distributions and forks of ffmpeg are careful not to pull too often
from upstream ffmpeg. In other words, the problems come from the fact
that ffmpeg does not have bugfix/stable releases.
BTW, gst-ffmpeg was updated last week and quite regularly in CVS as
well (but not released after each sync given the required amount of
QA). I hope you dare not criticize gst-ffmpeg for not releasing
updated versions as tarballs given the number of tarball releases of
ffmpeg. ;)
> This is another reason why it is a real pity that the work I did in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=152
> was never followed upon.
Err, who did you expect would followup?
> > Now instead of imagining we remove ffmpeg, perhaps you can imagine that
> > ffmpeg moves to offering a stable API, perhaps in a stable branch which
> > is feature frozen but where security fixes can go, we could:
> > - build mplayer, xine-lib, gst-ffmpeg against the ffmpeg shared libs
> [this could already be done, as I said above]
This was only possible too late in the release cycle. The gst-ffmpeg
patch would have been acceptable some 2 months ago, in fact I requested
such a patch, and tried an alternate solution on my own. Check #402793
for the parallel ctte discussion on gst-ffmpeg.
> > Why is ffmpeg so rapidly API breaking? xine-lib and GStreamer have
> > managed to expose very stable APIs for years, and they solve the same
> > type of problems.
> maybe because they live on a different level of abstraction
> xine-lib and gstreamer are "gluing" code: they wrap existing codecs
Yes, but the service that ffmpeg libs offer to xine-lib is exactly the
service xine-lib offers to totem-xine, and the same applies for ffmpeg
/ gst-ffmpeg / totem-gstreamer; yet gstreamer and xine-lib APIs are
stable and see releases. And this even holds true despite the fact the
gstreamer plugins packages wrap dozens of other libraries (~ 50 for
gst-plugins0.8) under the same API and ABI!
--
Loïc Minier <lool@dooz.org>
"Forget your stupid theme park! I'm gonna make my own! With hookers!
And blackjack! In fact, forget the theme park!" -- Bender
Reply to: