I am sorry, there were many misunderstanding (my argument was not clear enough - and it was too verbose) Let me be a bit more precise. I repeat my (hypothetical) reasoning. --- Steve said: > if it were my > decision *personally*, I would likely judge mplayer/ffmpeg too immature to > be included in a stable release until they did settle on a stable API. Moritz said that linking with internal ffmpeg is bad for security. Suppose all the above two are to be satisfied, then all programs in Debian stable cannot be linked - nor with a Debian ffmpeg family of library packages - neither with their own internal ffmpeg As a corollary, to satisfy both those requirements , we should disable ffmpeg in all of the programs that either contain a copy, or link to an external copy, or both. That leaves VLC as the only program that could play MPEG4 AFAIK --- All the above argument was to explain to Steve that FFMpeg is a widely used library , even though its API is not mature. --- some other remarks: Loïc Minier ha scritto: > 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. :) yeah, I was meaning 'the ffmpeg suite' ... :-) >> 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). BTW: after etch is release, you (AFAICR) are willing to update gst-ffmpeg to use DynLEF (as Josselin was proposing). Whereas, I had prepared a version of ffmpeg and mplayer that could be dynamically linked , see in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=152 so we should all join forces: you , me, Sam, xine people, totem people... [And, yes I know about xine. I built a version myself , to test with my newer ffmpeg packages .] > If we did not have a ffmpeg shared library, I suppose > we would still be able to build xine-lib without ffmpeg support. I guess so > No need to drop xine-lib, not these; only disable ffmpeg. that was what I meant , sorry for misunderstanding > (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). forking has pro and con pro: no sudden API changes con: it is more difficult for gstreamer to follow the "upstream" development of ffmpeg 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. 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. > 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] > - 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? :) I would love them to do a real release, lets say "ffmpeg 1.0" . My hope is that, by time of lenny release, that will be true. > 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 at the same time, xine and gstreamer contains embedded copies (*) of many of the codecs , so they are not broken when the upstream changes so, the get the "pro" but stumble also in the "con".. [(*) then, Debian people try when possible to link to a library package... but this is our choice ; and we do not always do that : e.g. libxine1 contains a copy of libmpeg2 , even if libmpeg2-4 is in Debian ] a.
Attachment:
signature.asc
Description: OpenPGP digital signature