[CC'ed are the maintainers of reverse (build-)dependencies.
Please reply only to <email@example.com>.
If you're interested in this discussion, consider subscribing that list.]
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:
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:
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.