ffmpeg demotion from main to multiverse

Sebastian Dröge mail at slomosnail.de
Mon Aug 29 10:23:11 CDT 2005


Hi,
I propose a demotion of ffmpeg to multiverse. The only main package
using it and one of it libraries (Build-Depends and Depends) is kino,
but kino could be compiled against libdv (which is in main) for the same
purpose (i.e. DV decoding). The only _possible_ disadvantage would be
slower DV decoding on non-x86 architectures.
A debdiff to let kino compile/link against libdv is here[1]

(and before someone asks... gst-ffmpeg ships their own ffmpeg version)

The reasons for the demotion are the following:

1) We currently use the ffmpeg from Debian but this is somewhat stripped
from "funny" formats (AAC for example, libfaad2 is in multiverse). When
ffmpeg is in multiverse we could use Marillat's version [2] of ffmpeg
which supports these formats.

2) Our current ffmpeg package ships only -dev packages for libavcodec
and libpostproc. These contain the static .a archives and no package
with shared .so libraries is available from our ffmpeg package. This
yields to the following problem: when updating ffmpeg all packages using
it need to be recompiled to use the advantages of the updated ffmpeg and
(more important) _every_ binary which links against libavcodec gets 2-3
mb bigger! for example for transcode this makes a real difference as it
contains many binaries linking against libavcodec. The compressed size
of the binary is ~14 MB instead of ~2 MB, the installed size is ~40 MB
instead of ~5 MB. Using Marillat's version [2] also helps in this case.
Shipping only static libraries is also generally discouraged [3]

3) ffmpeg isn't really API stable. We often had packages which FTBFS
because of a newer ffmpeg version and had to be updated which is
non-trivial in many cases. There are these 2 possible solutions:
-One possible solution is using the "only-static-linking" approach, which
 leads to other problems. The next time the package gets build it will
 FTBFS. Also we won't ship the complete source for the binary anymore as
 we have only a newer ffmpeg version in our archives but the package's
 binaries _contain_ an older ffmpeg version. This is a possible
 violation of the GPL! For this "solution" see 2) and [3], too.

-The other, better solution would be to set the shlideps of libavcodec to
 (= $Upstream_Version) so with a ffmpeg update every package will have
 unmet dependencies which gets noticed more easily and can be fixed then
 (by patching or notifying upstream). Marillat's package [2] does this.

But anyway... because of this API unstability I think this package is
wrong placed in main.

4) Even our (and Debians) ffmpeg version has support for some "funny"
formats: it allows mpeg video encoding. I think this would make a move
to restricted or multiverse necessary. This is the reason for 5) too.

5) The future of the package in Debian is really unsure. There was some
discussion on debian-devel [4] whether this will stay in Debian because
of 4). The Debian mplayer package is on NEW s ince many weeks because
of that until this is clarified.

Any further thoughts, arguments pro/con or questions?

Thanks,
Sebastian Dröge


[1]: http://yggdrasil.sytes.net/files/debdiff/kino_0.75-7ubuntu1.debdiff
[2]: ftp://ftp.nerim.net/debian-marillat/pool/main/f/ffmpeg/
[3]: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#staticonlylibs
[4]: http://www.nabble.com/Xvidcap,-mplayer-and-rte-(was-Re:-Fun-with-the-NEW-queue)-n252680.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20050829/4ed0c5c1/attachment-0001.pgp


More information about the ubuntu-devel mailing list