Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
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.
> totem-xine
> xine-ui
> gxine
> [other 20 programs]
No need to drop xine-lib, not these; only disable ffmpeg.
> 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.
--
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: