Hi Reinhard,
On 08.08.2014 14:29, Reinhard Tartler wrote:
On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs <matth...@urlichs.de> wrote:
I intended to come up with a more timely full response, but I just
didn't get to it so far.
Thanks for explaining your point of view here.
For now, please refer to http://lwn.net/Articles/607662/,
Have a look at: http://lwn.net/Articles/608040/
I was not there, when the FFmpeg/Libav split happened and I don't want
to judge, whether it was a good thing or not. But it clearly caused a
lot of bad blood between the developers involved, which in my opinion
hurts the development of the multimedia framework in recent times.
http://codecs.multimedia.cx/?p=370 (rather old, but still true), and
If these features weren't used, they wouldn't have been developed.
And many new features have been added to FFmpeg after that post.
http://codecs.multimedia.cx/?p=674 (recent update on that matter)
Let me quote from there:
"But that’s not what kills the fun, “security holes” do.
With an advance of automatic fuzz tools it’s easy to generate millions
of damaged files that crash your decoder and yet there are no tools for
generating correct patches. Fixing those crashes is tedious, requires a
lot of thinking (should I disable it? will it affect decoding correct
files? etc.) and in other words not fun at all."
That seems as if he doesn't want to continue Libav development, because
fixing security issues is tedious work.
It has basically nothing to do with whether FFmpeg is of good quality
security wise or not, or a good or bad competitor against Libav.
Regarding Marco's argument that libav had few friends, well, let me
point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948
for instance.
One person thinking that the code is 'beautiful' is no convincing
argument. The number of people expressing their interest in having
FFmpeg back in Debian is a lot more convincing.
IMHO the best idea at this point would be to toss out libav, and rebuild
the rdeps with ffmpeg. Now, before it's too late for jessie.
I think that is totally out of question: Uploading FFmpeg to our
archive will break the Debian archive so hard that it will take months
to get everything back to testing, if it works at all.
Let me repeat what I wrote in my initial mail in this thread:
Having FFmpeg in the Debian archive breaks absolutely *nothing*, but it
gives developers and users a choice between the two.
Even if Libav were to be removed, a transition to FFmpeg could be rather
smooth, as all the necessary patches already exist.
But you're right that the time to test the resulting packages is getting
rather short for the coming freeze.
Still it can make sense for packages that are tested with FFmpeg
upstream and have known issues with Libav.
So if you and the other Libav maintainers were to support the idea of
having both, the security and release teams could perhaps be convinced
to allow that. This has been my goal from the beginning and I hoped that
would be appreciated.
To the best of my knowledge, there are only two high-profile projects
that play hardball to require FFmpeg: Mplayer and mythtv. Neither of
those do that (again to the best of my knowledge) mainly because of
technical but rather very political reasons. The case of mplayer has
been elaborated extensively in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the
following "discussion" with Reimar - my conclusion from that is while
technically possible, nobody wants to make mplayer work with Libav -
and that's why it was removed, not because of the FFmpeg dependency).
For Mythtv I can only say that they didn't even bother engaging any
discussion.
That FFmpeg has more features is a rather technical argument.
Note that also many other projects are developed mainly with FFmpeg,
they just happen to not break completely when compiled against Libav.
For example, mpv prefers FFmpeg for good reasons:
"Although mpv attempts to work well with both FFmpeg and Libav, FFmpeg
is preferred in general. This is simply because FFmpeg merges from
Libav, and seems to have more features and fewer bugs than Libav." [1]
These features are actually requested by users, see e.g. [2].
(All) other high-profile downstream projects, including VLC or XBMC
(now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may
Just fine? Did you see the bugs I mentioned in my initial mail?
And how does it come that XBMC needs the '--enable-libav-compat'
configure option, which then uses code from lib/xbmc-libav-hacks, to
build against Libav?
provide them with extra features, but why on earth would anyone want 3
different implementations of a ProRes encoder (seriously, and FFmpeg
seems to claim to provide "security support" for each of them), or
support for fringe codecs such as Wing Command 3 (yes, you can decode
the videos from that video game).
One of those ProRes encoders comes from Libav and is provided in FFmpeg
for compatibility with Libav. Supporting both encoders provides the user
with additional choice.
Also security issues in an encoder are less likely, given that it
_encodes_ bitmaps into a bitstream and doesn't have to do complicated
parsing of attacker provided bitstreams into bitmaps like a decoder.
If FFmpeg wouldn't care so much about compatibility with Libav, a lot
less programs could be built with both.
There are a number of legitimate requested backports, such as for some
of FFmpeg's additional filters in libavfilter, and similar. All of
them are rather easy to backport, and this is done on a regular basis.
However, with the due diligence and attention such a widely used and
high-profile library requires.
I'm not sure such ports to Libav would be easy, as I'm under the
impression that many filters in FFmpeg use features not available in Libav.
As far as I can tell, only 3 filters have been ported in the last two
years, including one submission by an external developer. Keeping in
mind that more than 100 additional filters have been added to FFmpeg
this is only a very small number.
The external submission came from a developer of a music player who uses
Debian/Ubuntu and therefore has to use Libav.
"I went with libav simply because it is what is in the Debian and Ubuntu
package managers, and one of my goals is to get this music player
backend into their package managers.
[...]
In order to have this functionality, I ported the "compand" audio filter
from ffmpeg." [3]
Which brings me to my next point: Release frequency. FFmpeg has an
insane frequency of releases, and still seems to "support" (at least
providing updates) to all of them,
Generally FFmpeg supports all releases still widely used.
including 0.5 which is currently in
oldstable (needless to say none of these patches made it to
oldstable-security, why is still a mystery to me).
It was a mystery to me, but I assumed you would know the reasons [4]:
ffmpeg (4:0.5.6-1) stable-security; urgency=low
[...]
* Note while the source package name reads 'ffmpeg', this is actually
the libav-0.5.6 release.
-- Reinhard Tartler <siret...@tauware.de> Mon, 26 Dec 2011 00:14:25 +0100
So even if the package in oldstable is called ffmpeg, it is actually
Libav and thus only got the security updates provided by Libav.
Nothing prevents you from uploading ffmpeg-0.5.14 to squeeze-lts.
The effect of that
is that downstream projects have a hard time to choose what version of
FFmpeg they want to support.
What do you mean?
Every distribution includes the latest possible version and upstream
tracks how long they need to be supported [5].
This brings effectively back to the
situation I was in when I took over maintenance of the package many
years ago: Back then, Michael Niedermeyer strongly recommended all
downstreams to avoid shared libraries and just link statically against
libavcodec.a to avoid problems regarding "incompatible" library
versions. I see exactly this problem arising again: Both mythtv and
mplayer upstream (btw, xbmc as well) bundle some copy of ffmpeg in
their sources and recommend everyone to just use the internal copy to
avoid problems.
Needless to say that this is not acceptable for use in Debian.
Both MPlayer and XBMC can be built against a system version of FFmpeg.
Yes, I agree that this situation is a mess. A big mess. My fear is
that switching to FFmpeg will bring us back to the mess we where 8
years ago, and I worked on for years.
How can switching to FFmpeg undo the development of the last 8 years?
Especially since commits from Libav get merged on a daily basis.
Libav is far from being perfect. That's true. I don't know why exactly
FFmpeg seems to have more manpower, but it's not all black or white.
For instance, there are a number of developers that actively
contribute to both projects and are essential in keeping both projects
in good health.
Indirectly all Libav contributors also contribute to FFmpeg, because
changes in Libav get merged into FFmpeg.
Also I don't really buy the security argument. True,
FFmpeg has more security updates, but backporting them to Libav turned
out to be difficult because many if not most of them turn out to be
either incomplete, invalid or require further clarification. Libav
developers prefer to go the unpleasant road of fully understanding the
issue, which takes extra time.
If that extra time is about a year or more (CVE-2011-3946,
CVE-2013-0851, CVE-2013-0852, CVE-2013-0868) [6], I think it is clearly
far too long.
For all these reasons, I do not see the
necessity to do any drastic and dangerous steps right now.
I now seriously wonder if the last 45 minutes in which I wrote this
email wouldn't have been better spent with preparing the next upload
for stable-security. YMMV.
It would be nice, if you could also spent some time thinking about the
possibility of having both FFmpeg and Libav in Debian.
Best regards,
Andreas
1: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav
2: http://lwn.net/Articles/608012/
3: http://andrewkelley.me/post/quest-build-ultimate-music-player.html
4: https://tracker.debian.org/media/packages/f/ffmpeg/changelog-4%3A0.5.10-1
5: https://trac.ffmpeg.org/wiki/Downstreams
6: https://tracker.debian.org/media/packages/liba/libav/changelog-6%3A10.3-1
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e51190.4040...@googlemail.com
