Andreas Cadhalpun
2014-07-27 23:20:59 UTC
Hi all,
some of you may have noticed a weird ffmpeg package in the NEW queue[1].
Let me explain:
In 2011 Libav[2] was forked from FFmpeg[3]. It was a time of great
uncertainty, the fork happened with much drama that didn't help making a
technical cut, and at that peculiar time Debian switched to Libav.
Since then the two projects evolved differently, and we have now a
clearer view.
Some short answers to questions you might have now:
* Why is FFmpeg needed in Debian?
- It has features our users are asking for (mostly support for more
codecs, formats and filters)[4-6].
- Some applications break when built against Libav on Debian,
because they are developed using FFmpeg[7-10].
- There are issues[11-12] in Libav's command line tools, that can't
be reproduced with FFmpeg's tools.
- It has a big and active user and developer community. Those of
them who want to use Debian currently need to install FFmpeg from
third parties or compile their own version from source.
* Do you intend to replace Libav by FFmpeg in Debian?
No, there is no need to replace anything as long as it is maintained.
Currently the main goal is to give multimedia maintainers a choice
between the two sets of libraries to link against, and our users the
choice to use the 'ffmpeg' utility. That is possible, because the
packages are co-installable. (Only the *-dev packages conflict.)
* But I thought they were forks, why don't you just create conflicting
packages?
- Because it can't really work! If we do that, packages built with
FFmpeg won't be installable next to packages built with Libav
unless we have full binary compatibility.
- Binary compatibility can only be achieved with some tradeoffs:
a) Not all soversions of the libraries match, so we would have
to patch that away.
b) FFmpeg would have to be compiled with the configure option
--enable-incompatible-libav-abi, resulting in less tested
code paths.
c) FFmpeg and Libav would need to be updated at the same time.
d) The biggest problem is that this would allow applications only
to use the minimal set of the ABI supported by both.
* I do not believe you, explain that voodoo to me: How is it that it
won't break all of Debian and make kittens cry?
(aka: How is FFmpeg packaged for Debian?)
- We built the packages in a way that avoids filename conflicts.
The sonames of the FFmpeg libraries are suffixed with '-ffmpeg',
e.g. libavcodec-ffmpeg.so.55 instead of libavcodec.so.55.
This also means that only if a package uses pkg-config to detect
the correct linker flags, you can simply install e.g. the
libavcodec-ffmpeg-dev package and it will work transparently.
(About half the packages build with no further change, see
stats below.)
- From a user point of view, the tools have different names anyway,
e.g. ffmpeg and avconv, except for qt-faststart, which is
therefore packaged in a separate binary package that diverts
the Libav version to qt-faststart.libav.
Yes, you can have /usr/bin/ffmpeg and /usr/bin/avconv at the same
time without conflicts.
- The development packages have to conflict, because they provide
header files (and pkg-config files) with identical names in
identical locations.
- To avoid potential problems when a program is linked against
FFmpeg libraries and other libraries, which in turn are linked
against Libav, the symbol versions are changed to e.g.
LIBAVCODEC_FFMPEG_55 instead of LIBAVCODEC_55.
* Ok, let's say I'm a multimedia maintainer and want to try out
building my package against your ffmpeg, what should I do?
- If your package uses pkg-config, which is commonly the case, all
you have to do is to replace all lib{av,swscale,postproc}*-dev
build-dependencies by lib{av,swscale,postproc}*-ffmpeg-dev.
You can keep the Libav build-dependencies as alternatives.
- In the (odd) case your upstream doesn't use pkg-config
(52 packages), it's probably a good idea to start using it, so
that the program can be easily built with both.
The patches are usually quite simple as you can see in this
example:
--- squeezelite-1.6.orig/Makefile
+++ squeezelite-1.6/Makefile
@@ -26,7 +26,7 @@ LINK_ALSA = -lasound
LINK_PORTAUDIO = -lportaudio
LINKALL = -lFLAC -lmad -lvorbisfile -lfaad -lmpg123
-LINKALL_FF = -lavcodec -lavformat -lavutil
+LINKALL_FF = $(shell pkg-config --libs libavcodec libavformat
libavutil)
LINKALL_RESAMPLE = -lsoxr
DEPS = squeezelite.h slimproto.h
Patches for packages using Autoconf or Cmake are similarly
straight-forward.
- Sometimes other minor adjustments are needed. (13 packages)
- There are only 2 packages (opencv and ffms2) that would trigger a
needed transition, but that would be quite manageable as only 4
packages (3 on opencv and 1 on ffms2) depend on both libav*-dev
and the transition-needed library (libopencv-highgui-dev and
libffms2-dev).
Note that the dependencies of libopencv-highgui-dev on
libavcodec-dev, libavformat-dev and libswcale-dev seem
to be unnecessary[13].
* Does it make sense for me to switch my package?
The rule of thumb is, if your upstream uses FFmpeg for development
you probably want to switch to using it, too.
Of the 108 current reverse-build-dependencies of src:libav,
50 only need build-dependency adjustments,
50 can be patched to work with FFmpeg already,
5 can only be patched once FFmpeg is through NEW,
2 FTBFS since a long time and are not in testing [14-15] and
1 currently FTBFS for unrelated reasons [16].
Attached results.txt contains a per package list.
Any maintainer interested in switching should get in touch, and we'll
gladly help preparing the transition. When we're done dealing with those
early birds we intend to file wishlist bugs with patches on other
packages to help maintainers transition if they want to. (We already
have patches for the affected packages.)
The FFmpeg version currently in NEW has been there for more than
2 months and is thus outdated. If you want to test the current
packages, you can build them from the repository on Alioth [17]
(e.g. using git-buildpackage).
Furthermore, we'd like to move the FFmpeg packaging under the umbrella
of the pkg-multimedia team, because this would facilitate future FFmpeg
transitions.
Best regards,
Andreas (on behalf of the FFmpeg team)
1: https://ftp-master.debian.org/new/ffmpeg_7:2.2.1-1.html
2: https://libav.org/
3: https://ffmpeg.org/
4: http://lucy.pkh.me/diff/
5: https://bugs.debian.org/707476
6: https://bugs.debian.org/694616
7: https://bugs.debian.org/732159
8: https://bugs.debian.org/741170
9: https://bugs.debian.org/742896
10: https://bugs.debian.org/745060
11: https://bugs.debian.org/692876
12: https://bugs.debian.org/753923
13: https://bugs.debian.org/745934
14: https://bugs.debian.org/723099
15: https://bugs.debian.org/720796
16: https://bugs.debian.org/747536
17: https://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary
some of you may have noticed a weird ffmpeg package in the NEW queue[1].
Let me explain:
In 2011 Libav[2] was forked from FFmpeg[3]. It was a time of great
uncertainty, the fork happened with much drama that didn't help making a
technical cut, and at that peculiar time Debian switched to Libav.
Since then the two projects evolved differently, and we have now a
clearer view.
Some short answers to questions you might have now:
* Why is FFmpeg needed in Debian?
- It has features our users are asking for (mostly support for more
codecs, formats and filters)[4-6].
- Some applications break when built against Libav on Debian,
because they are developed using FFmpeg[7-10].
- There are issues[11-12] in Libav's command line tools, that can't
be reproduced with FFmpeg's tools.
- It has a big and active user and developer community. Those of
them who want to use Debian currently need to install FFmpeg from
third parties or compile their own version from source.
* Do you intend to replace Libav by FFmpeg in Debian?
No, there is no need to replace anything as long as it is maintained.
Currently the main goal is to give multimedia maintainers a choice
between the two sets of libraries to link against, and our users the
choice to use the 'ffmpeg' utility. That is possible, because the
packages are co-installable. (Only the *-dev packages conflict.)
* But I thought they were forks, why don't you just create conflicting
packages?
- Because it can't really work! If we do that, packages built with
FFmpeg won't be installable next to packages built with Libav
unless we have full binary compatibility.
- Binary compatibility can only be achieved with some tradeoffs:
a) Not all soversions of the libraries match, so we would have
to patch that away.
b) FFmpeg would have to be compiled with the configure option
--enable-incompatible-libav-abi, resulting in less tested
code paths.
c) FFmpeg and Libav would need to be updated at the same time.
d) The biggest problem is that this would allow applications only
to use the minimal set of the ABI supported by both.
* I do not believe you, explain that voodoo to me: How is it that it
won't break all of Debian and make kittens cry?
(aka: How is FFmpeg packaged for Debian?)
- We built the packages in a way that avoids filename conflicts.
The sonames of the FFmpeg libraries are suffixed with '-ffmpeg',
e.g. libavcodec-ffmpeg.so.55 instead of libavcodec.so.55.
This also means that only if a package uses pkg-config to detect
the correct linker flags, you can simply install e.g. the
libavcodec-ffmpeg-dev package and it will work transparently.
(About half the packages build with no further change, see
stats below.)
- From a user point of view, the tools have different names anyway,
e.g. ffmpeg and avconv, except for qt-faststart, which is
therefore packaged in a separate binary package that diverts
the Libav version to qt-faststart.libav.
Yes, you can have /usr/bin/ffmpeg and /usr/bin/avconv at the same
time without conflicts.
- The development packages have to conflict, because they provide
header files (and pkg-config files) with identical names in
identical locations.
- To avoid potential problems when a program is linked against
FFmpeg libraries and other libraries, which in turn are linked
against Libav, the symbol versions are changed to e.g.
LIBAVCODEC_FFMPEG_55 instead of LIBAVCODEC_55.
* Ok, let's say I'm a multimedia maintainer and want to try out
building my package against your ffmpeg, what should I do?
- If your package uses pkg-config, which is commonly the case, all
you have to do is to replace all lib{av,swscale,postproc}*-dev
build-dependencies by lib{av,swscale,postproc}*-ffmpeg-dev.
You can keep the Libav build-dependencies as alternatives.
- In the (odd) case your upstream doesn't use pkg-config
(52 packages), it's probably a good idea to start using it, so
that the program can be easily built with both.
The patches are usually quite simple as you can see in this
example:
--- squeezelite-1.6.orig/Makefile
+++ squeezelite-1.6/Makefile
@@ -26,7 +26,7 @@ LINK_ALSA = -lasound
LINK_PORTAUDIO = -lportaudio
LINKALL = -lFLAC -lmad -lvorbisfile -lfaad -lmpg123
-LINKALL_FF = -lavcodec -lavformat -lavutil
+LINKALL_FF = $(shell pkg-config --libs libavcodec libavformat
libavutil)
LINKALL_RESAMPLE = -lsoxr
DEPS = squeezelite.h slimproto.h
Patches for packages using Autoconf or Cmake are similarly
straight-forward.
- Sometimes other minor adjustments are needed. (13 packages)
- There are only 2 packages (opencv and ffms2) that would trigger a
needed transition, but that would be quite manageable as only 4
packages (3 on opencv and 1 on ffms2) depend on both libav*-dev
and the transition-needed library (libopencv-highgui-dev and
libffms2-dev).
Note that the dependencies of libopencv-highgui-dev on
libavcodec-dev, libavformat-dev and libswcale-dev seem
to be unnecessary[13].
* Does it make sense for me to switch my package?
The rule of thumb is, if your upstream uses FFmpeg for development
you probably want to switch to using it, too.
Of the 108 current reverse-build-dependencies of src:libav,
50 only need build-dependency adjustments,
50 can be patched to work with FFmpeg already,
5 can only be patched once FFmpeg is through NEW,
2 FTBFS since a long time and are not in testing [14-15] and
1 currently FTBFS for unrelated reasons [16].
Attached results.txt contains a per package list.
Any maintainer interested in switching should get in touch, and we'll
gladly help preparing the transition. When we're done dealing with those
early birds we intend to file wishlist bugs with patches on other
packages to help maintainers transition if they want to. (We already
have patches for the affected packages.)
The FFmpeg version currently in NEW has been there for more than
2 months and is thus outdated. If you want to test the current
packages, you can build them from the repository on Alioth [17]
(e.g. using git-buildpackage).
Furthermore, we'd like to move the FFmpeg packaging under the umbrella
of the pkg-multimedia team, because this would facilitate future FFmpeg
transitions.
Best regards,
Andreas (on behalf of the FFmpeg team)
1: https://ftp-master.debian.org/new/ffmpeg_7:2.2.1-1.html
2: https://libav.org/
3: https://ffmpeg.org/
4: http://lucy.pkh.me/diff/
5: https://bugs.debian.org/707476
6: https://bugs.debian.org/694616
7: https://bugs.debian.org/732159
8: https://bugs.debian.org/741170
9: https://bugs.debian.org/742896
10: https://bugs.debian.org/745060
11: https://bugs.debian.org/692876
12: https://bugs.debian.org/753923
13: https://bugs.debian.org/745934
14: https://bugs.debian.org/723099
15: https://bugs.debian.org/720796
16: https://bugs.debian.org/747536
17: https://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary