[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: