siretart at tauware.de
Mon Oct 12 11:05:58 UTC 2009
Loïc Minier <lool at dooz.org> writes:
> My understanding is that the ffmpeg we have in Debian/Ubuntu is
> relatively stabilized and aligned with other distros (Gentoo IIRC).
> Would it make sense to provide a ffmpeg-snapshot like gcc-snapshot
> which we would update as we see fit? Perhaps to allow people to play
> with latest upstream stuff and also to have them test for regression or
> upstream fixes. It could be kept out of testing like gcc-snapshot.
> What do you folks think?
I've been thinking about this as well. Let me lists my thoughts on this:
- The FFmpeg libraries make intensive use of internal structures that
are not exported externally; e.g. libavcodec usees a lot of structs
in libavutil (historically, some of them started ad-hoc in libavcodec
and then got moved to libavutil), and the same does happen in
libavformat, which uses internals of both libavcodec and libavutil.
This means that you cannot expect a newer libavcodec to be usable
against an "older" libavutil, even when the soname of libavutil
- Debian-multimedia.org is already replacing debian's FFmpeg libraries
with newer versions from upstream. The result can be seen fairly
frequently in forms of bugreports against the debian vlc and mplayer
packages: crashes, unresolved symbols while program loading and so
- This could be strictly speaking considered as an ABI break and would
require a SONAME change. The ffmpeg developers disagree here and
don't really support mixing library versions. Therefore, I'd suggest
that a potential ffmpeg-snapshot package must not replace the
libraries from the current packages in order to not break existing
- If we go that way, how are applications supposed to use the new
ffmpeg-snapshot libraries then?
- Packages that need a newer FFmpeg usually include a newer copy of
ffmpeg in their sources.
I've been thinking about the following
- Instead of doing a ffmpeg-snapshot, let's imagine a mplayer-snapshot
package. Mplayer includes FFmpeg via svn:externals, so ffmpeg is
per-definition always up-to-date.
- From these sources, build both mplayer and FFmpeg.
- This beast is of course hard to support in a stable release. Upstream
always recommends to keep up-to-date, which is not reasonable in
stable debian and ubuntu releases.
- (Minor) mplayer includes an (older) copy of libass. Actually, libass
originates from mplayer, but can nowadays be found as a googlecode
project which we already package in debian for vlc and
others. mplayer can however also use the system libass AFAIUI.
While talking to Uoti Urpala (one of the most active contributors of
mplayer), he notified me about his git imports of mplayer and
FFmpeg. Because of the difficulties with svn:externals, he maintains an
mplayer-build build infrastructure , that uses git submodules to build
all of libass, FFmpeg and mplayer.
My current plan would be to investigate this build infrastructure
further and see, if we could package this as 'mplayer-snapshot'.
So far what I've seen here:
- mplayer-build imports the git import, that is not an exact mirror of
mplayer. Uoti includes a number of new developments here, that might
or might not end up in mplayer trunk
- the most important change here is that mplayer no longer uses FFmpeg
internals, but restricts to the external API (yay!). Unfortunately,
it seems that a post-0.5 FFmpeg is required.
Reinhard Tartler, KeyID 945348A4
More information about the pkg-multimedia-maintainers