ffmpeg-snapshot

[Reinhard Tartler]

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
   didn't change.

 - 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
   on.   

 - 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
   applications.

 - 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.

Challenges here:

 - 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 [1], 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.

footnotes: 
[1] http://repo.or.cz/w/mplayer-build.git

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4