Re: Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
From: Reinhard Tartler <siretart@tauware.de>
Loïc Minier <lool+debian@via.ecp.fr> writes:
> On Sat, Dec 16, 2006, A Mennucc wrote:
>> we delete ffmpeg from Debian stable,
>> since it is not really a library yet
>
> We can also keep ffmpeg (the binary), without its lib. :)
>
>> so we also delete ffmpeg from inside:
>> libxine1 , used in
>
> xine-lib builds against Debian's ffmpeg AFAICT, *not* against its
> internal copy (it build-deps against libavformat-dev, libpostproc-dev,
> libavcodec-dev). If we did not have a ffmpeg shared library, I suppose
> we would still be able to build xine-lib without ffmpeg support.
I switched xine-lib to debian's ffmpeg against advice from upstream. I
didn't get any negative feedback about it, though, so I decided that
etch will go with xine-lib using debian's ffmpeg.
Please note that it seems to me, that xine doesn't use as much from
ffmpeg as mplayer, so I'm not sure if these two projects are that
comparable in this point.
Given that there are other examples of code duplication (think about the
xulrunner/icedove/iceape mess), I'd vote for giving mplayer an exception
for etch, and offer Sam help with updating ffmpeg more regularly.
>> totem-xine
>> xine-ui
>> gxine
>> [other 20 programs]
>
> No need to drop xine-lib, not these; only disable ffmpeg.
xine-lib without ffmpeg is of very little use.
Please note that xine-ui and gxine don't ship ffmpeg on its own, but
rather link against libxine. Quite a difference.
>> gstreamer-ffmpeg , used in
>> totem-gstreamer
>> openoffice.org
>> libgnash0 [flash implementation]
>> gnomebaker
>> geekast-binary
>> bmpx
>
> (And way more packages.) But please note that gst-ffmpeg is a real
> fork of ffmpeg which applies stability and functionality fixes around
> its snapshot in order to fix ffmpeg regressions. This is all wrapped
> in the GStreamer (stable) API transparently, and the program you
> mention are still usable without gst-ffmpeg (gst-plugins-base, -ugly,
> -bad also provide codecs).
>
>
> 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
> - fix security holes in a single place
> - upload new ffmpeg versions without breaking mplayer, xine-lib,
> gst-ffmpeg or requiring a rebuild
>
> Doesn't it sound nicer? :)
>
> 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.
The reason is, that nobody is actually interested in maintaining a
stable ffmpeg tree, but a lot of people are asking for it. There has
been at least one offer for this on the ffmpeg mailing list, but this
effort doesn't bring any results. FFmpeg developers on the other hand
rather like hacking, and don't seem to care much about other projects
than mplayer.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reply to: