Select provider of libav* libraries
andreas.cadhalpun at googlemail.com
Fri May 1 12:03:37 UTC 2015
[CC'ed are the maintainers of reverse (build-)dependencies.
Please reply only to <pkg-multimedia-maintainers at lists.alioth.debian.org>.
If you're interested in this discussion, consider subscribing that list.]
On 29.04.2015 20:56, Alessio Treglia wrote:
> I am afraid that I have to revive this discussion once again now that
> Jessie is out as we have plenty of time before starting doing any
> major work for Stretch: it's really the right time to make a final
> decision about this subject.
> The need to get this dichotomy solved may be found in Moritz's last email:
> On Wed, Apr 29, 2015 at 7:22 PM, Moritz Mühlenhoff <jmm at inutil.org> wrote:
>> To properly migrate over a daemon they need to co-exist for a stable
>> release, while a lib does not. Stretch will only have one of them.
>> Having both for a year along each other will only waste people's time. Now
>> at the beginning of the release cycle is the time to make a decision,
>> not by dragging things into a year as of today. Picking one of the two
>> won't be any simpler in 12 months.
> It appears clear to me that the security team wouldn't be too happy to
> support both FFmpeg and libav:
> Therefore the question still remains:
> On Tue, Aug 26, 2014 at 11:36 PM, Benjamin Drung <bdrung at debian.org> wrote:
>> So I am asking you: Should we ship libav or FFmpeg? Can we reach a
>> consensus on this topic?
Currently FFmpeg  and Libav  packages coexist in unstable without
any technical problems.
However, unless someone can convince the Debian Security Team that
supporting both in a stable release would be acceptable (I couldn't),
a decision has to be made.
I think FFmpeg should be chosen, because it is better than Libav in
practically every way:
* It has more features, e.g. it supports more codecs/formats/filters
and devices .
* Some applications require some of those features and thus don't work
with Libav, e.g. chromium, currently using an embedded copy .
* Bug fixes in FFmpeg are only rarely cherry-picked to Libav, while
most changes in Libav are merged into FFmpeg.
Thus Libav contains bugs not present in FFmpeg.
(See e.g. #783616  for a typical example.)
* The previous point also applies to security fixes.
(See e.g. CVE-2015-3417  for a typical example.)
Thus I'm proposing a transition from FFmpeg to Libav.
The transition consists of two parts: libraries and command line tools.
Transitioning the libraries could be done by switching build-dependencies
from lib*-dev (built from src:libav) to lib*-ffmpeg-dev (built from
src:ffmpeg). But because this would require making source changes
to all reverse build-dependencies, I think it would be better to
rename the libraries from src:libav to lib*-libav-dev and those
from src:ffmpeg to lib*-dev.
Then binNMUs would be sufficient for most reverse build-dependencies.
Transitioning from the libav-tools to the ffmpeg binary package has
to be done for all packages depending on libav-tools. Otherwise they
would become uninstallable. Adjusting recommends/suggests would also
be good, but is not as important.
Reverse build-dependencies requiring work:
* blender: FTBFS #783838, fixed in experimental
* dvswitch: FTBFS #747868, not in testing
* gpac: uses private libavformat define #783879
* gstreamer0.10-ffmpeg: FTBFS #720796, should be removed
* gst-libav1.0: needs build-dependency on libavresample-dev
* jitsi: FTBFS: #759835, fixed in NEW
* mpd: needs version from experimental, see 
* paraview: FTBFS #783842
* taoframework: hardcoded sonames need to be updated
* xbmc: to be replaced by kodi (in NEW), which uses FFmpeg already
Reverse dependencies of libav-tools:
* devede supports both
* dvd-slideshow drop ffmpeg-avconv.patch
* dvdwizard drop port-to-avconv.patch
* ffdiaporama supports both
* gerris drop 04_replace_ffmpeg_by_avconv.patch
* ifetch-tools no direct use (why the dependency?)
* kdenlive supports both
* miro drop 140_use_avconv.patch
* performous-tools drop use-avconv.patch
* python-satellites needs one-line patch for video.py: avconv -> ffmpeg
* python3-audioread drop avconv.patch
* tribler supports both
* videotrans drop 03-ffmpeg_to_avconv.patch
* winff-gtk2,winff-qt supports both
* zoneminder drop libav_path.patch
* zoomer needs one-line patch for zoomer: avconv -> ffmpeg
Other packages needing changes:
* x264 avconv -> ffmpeg in debian/tests/encode-testimage
* imagination drop 30_avconv_port.patch
* transcode drop 07_libav9-preset.patch
Please let me know if you have better ideas about this or think that
something above is not correct.
More information about the pkg-flash-devel