Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

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

[Thorsten Glaser]

Post by Andreas Cadhalpun
* 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.)

Hm, I wonder if this will work, see the JPEG discussion.

But I'd *love* to see ffmpeg replace libav and to get
my mplayer back, which is currently on hold.

Thanks,
//mirabilos

[Andreas Cadhalpun]

Post by Thorsten Glaser

Post by Andreas Cadhalpun
* 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.)

Hm, I wonder if this will work, see the JPEG discussion.

Well, it would work, if the security and release teams would agree with it.

Post by Thorsten Glaser
But I'd *love* to see ffmpeg replace libav and to get
my mplayer back, which is currently on hold.

Once FFmpeg is back in the archive, it'll be easy to reintroduce
MPlayer. It has been removed from sid, since it fails to build against
Libav, but it builds fine against FFmpeg.
(It uses some of the features only provided by FFmpeg.)

Best regards,
Andreas

[Matthias Urlichs]

Hi,

Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It
has been removed from sid, since it fails to build against Libav, but it
builds fine against FFmpeg.
(It uses some of the features only provided by FFmpeg.)

Yet another reason why solely depending on libav is a bad idea.

That leaves the question of the "official" opinion of the libav
maintainers (pkg-multimedia-***@lists.alioth.debian.org).
Did none of them write anything in "defense" of libav, or have I simply
missed it?

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.

[Marco d'Itri]

Post by Matthias Urlichs
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.

Agreed. The interested parties should really raise this with the CTTE
ASAP.

[Alessio Treglia]

Hi,

Post by Matthias Urlichs
That leaves the question of the "official" opinion of the libav
Did none of them write anything in "defense" of libav, or have I simply
missed it?
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.

This is an eminently bad idea. As I said before, it's too late for
Jessie already.

Many Jessie's multimedia framework and packages have been developed
and QA'd with libav.

We've spent a lot of time over the past months talking to upstreams,
forwarding them our patches and make sure their programs and libraries
work with libav.
We've spent ***months*** in making the whole thing work, and dropping
libav in favour of FFmpeg at this point, roughly few weeks from the
freeze deadline, would be definitely insane.

Cheers.

[Matthias Urlichs]

Hi,

Post by Alessio Treglia
We've spent a lot of time over the past months talking to upstreams,
forwarding them our patches and make sure their programs and libraries
work with libav.
We've spent ***months*** in making the whole thing work, and dropping
libav in favour of FFmpeg at this point, roughly few weeks from the
freeze deadline, would be definitely insane.

Yes, that work might be "wasted". But I don't think that it's a good idea
to base the decision of whether or not X is better for Debian on the fact
that somebody did a lot of work for Y instead.

Yes, the freeze is not that far away. But frankly, how much effort would it
be to switch now? As far as I can tell from this discussion, the answer is
"not a whole lot". The bulk of ffmpeg/libav's reverse dependencies is just
a simple binNMU away, and as the libraries seem to be co-installable we
don't even need a big transition.

We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd
hate to report some intractable codec bug which Upstream closes with an
"it works with FFmpeg" comment -- what would you recommend me to do in
that situation, next year -- install the ffmpeg libs from Experimental
and rebuild the offender?

[Jonas Smedegaard]

Quoting Matthias Urlichs (2014-08-08 21:22:38)

Post by Matthias Urlichs

Post by Alessio Treglia
We've spent a lot of time over the past months talking to upstreams,
forwarding them our patches and make sure their programs and
libraries work with libav.
We've spent ***months*** in making the whole thing work, and dropping
libav in favour of FFmpeg at this point, roughly few weeks from the
freeze deadline, would be definitely insane.

Yes, that work might be "wasted". But I don't think that it's a good
idea to base the decision of whether or not X is better for Debian on
the fact that somebody did a lot of work for Y instead.
Yes, the freeze is not that far away. But frankly, how much effort
would it be to switch now? As far as I can tell from this discussion,
the answer is "not a whole lot". The bulk of ffmpeg/libav's reverse
dependencies is just a simple binNMU away, and as the libraries seem
to be co-installable we don't even need a big transition.
We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd
hate to report some intractable codec bug which Upstream closes with
an "it works with FFmpeg" comment -- what would you recommend me to do
in that situation, next year -- install the ffmpeg libs from
Experimental and rebuild the offender?

I would recommend you to take into account who is actually going to
maintain this in Debian. Perhaps those who've maintained libav in the
past will loose interest if switching to FFmpeg (or that it will attract
others who are far better at it or maintenance becomes much easier, but
I doubt that).

Just please distinguish between those in this thread telling what they
do themselves and those (bogusly!) dictating others to do stuff.


- Jonas

[Jean-Yves Avenard]

Hi.

Only going to reply to some of the misinformation provided in the post
from Reinhard Tartler <***@gmail.com>
(https://lists.debian.org/debian-devel/2014/08/msg00160.html)

For the background: I am the de-facto maintainer of the MythTV's FFmpeg fork.

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.

MythTV has always used its own internal fork of FFmpeg. I have been
involved in this project for close to a decade, and not once during
that time has MythTV been using a system libav*.

What political reasons are you referring to?
We were syncing against FFmpeg against before their childish fight
started, we continued syncing against FFmpeg after that. No more no
less.

One of the core developer of LibAV is Janne Grunau, who was also a
MythTV developer. He stopped being an active member of MythTV due to
lack of time.

MythTV do not work against stock FFmpeg and never will. We run a
heavily modified version of FFmpeg, you can call it a fork.
In particular, we use our own mpeg-ts demuxer, we support things like
MHEG, DVB/ATSC/Teletext subtitles that FFmpeg do not.
We have attempted for many years to get our changes merged in FFmpeg
but gave up.

You say MythTV didn't bother engaging any discussions? what
discussions are you referring to ? I certainly have never been
contacted by either teams.

What I can recall however is me submitting an issue to both FFmpeg and
LibAV trac. The problem was dismissed in LibAV and fixed within a
couple of days in FFmpeg.
LibAV had decided to totally remove some core APIs that we make use of
(in this case it was fast mpeg decoding used by our commercial
detection system).
FFmpeg re-introduced it at our demand.

FFmpeg also have kept the old VDPAU decoding API, LibAV removed it.

As such, it is easier for us to sync against FFmpeg than it is against
LibAV. I call this technical reasons. there's nothing political into
it.

FFmpeg cherry-pick or merge any changes occurring in LibAV in a matter
of days. So by syncing against FFmpeg we enjoy the best of both
worlds.

To end this message: I fail to see how debian's decision on which
version of FFmpeg or LibAV would have any impact on MythTV, we use
neither

[wm4]

On Sat, 9 Aug 2014 11:46:40 +1000

Post by Jean-Yves Avenard
MythTV do not work against stock FFmpeg and never will. We run a
heavily modified version of FFmpeg, you can call it a fork.
In particular, we use our own mpeg-ts demuxer, we support things like
MHEG, DVB/ATSC/Teletext subtitles that FFmpeg do not.
We have attempted for many years to get our changes merged in FFmpeg
but gave up.

Off-topic, but: it might be easier nowadays?

The strangest things that are not even related to video decoding are
getting merged - surely it's possible to merge things such as teletext.

[Matthias Urlichs]

Hi,

Post by Jean-Yves Avenard
We have attempted for many years to get our changes merged in FFmpeg
but gave up.

It might be a good idea to restart this effort.

Post by Jean-Yves Avenard
To end this message: I fail to see how debian's decision on which
version of FFmpeg or LibAV would have any impact on MythTV, we use
neither

Most forks cause additional work which, in the long term, is better spent
elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal
world, you wouldn't need the mythtv fork either.

Debian's position is that we _really_ want to avoid having multiple copies
of essentially the same code in the archive; it's additional work for the
security team (if they even know about the copies), needlessly eats memory
when the two are in use simultaneously, and causes no end of trouble when a
plug-in is linked against copy A while the main code (or another plugin)
uses copy B (unless everybody is very careful WRT symbol versioning).

[Kieran Kunhya]

Post by Matthias Urlichs
Most forks cause additional work which, in the long term, is better spent
elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal
world, you wouldn't need the mythtv fork either.
Debian's position is that we _really_ want to avoid having multiple copies
of essentially the same code in the archive; it's additional work for the
security team (if they even know about the copies), needlessly eats memory
when the two are in use simultaneously, and causes no end of trouble when a
plug-in is linked against copy A while the main code (or another plugin)
uses copy B (unless everybody is very careful WRT symbol versioning).

The reality is that in the current state of affairs static linking is
the *only* way you are guaranteed to have the features you expect and
avoid ABI mismatches. It's very complicated when your users complain
about bugs in an underlying library that is either too old on a system
or the wrong flavour of the fork. Then your users have to rebuild a
massive dependency chain to fix that bug or hope for the best in the
future.

We also use a fork specifically to work around very wasteful
calculations in libswscale during 10-bit chroma conversion that
involve multiplying a pixel by a 2^n value with 32-bit precision and
then shifting that value down by n back to 16-bit precision (achieving
nothing). The fix breaks other codepaths that we don't use but the
performance gain is big enough to warrant a fork.

FWIW I think debian should also enable libavresample. This code has
been proven to be more robust internally and was designed by a larger
group instead of libswresample which was basically one person (and
literally appeared in git out of nowhere).

Kieran

[Andreas Cadhalpun]

Hi Kieran,

Post by Kieran Kunhya
The reality is that in the current state of affairs static linking is
the *only* way you are guaranteed to have the features you expect and
avoid ABI mismatches. It's very complicated when your users complain
about bugs in an underlying library that is either too old on a system
or the wrong flavour of the fork. Then your users have to rebuild a
massive dependency chain to fix that bug or hope for the best in the
future.

I can understand that statically linking is easier from an upstream
point of view, but it has important disadvantages for a distribution
such as Debian and thus should be avoided if possible.
It is also the responsibility of a distribution to make sure that there
are no ABI mismatches or similar problems.

Post by Kieran Kunhya
We also use a fork specifically to work around very wasteful
calculations in libswscale during 10-bit chroma conversion that
involve multiplying a pixel by a 2^n value with 32-bit precision and
then shifting that value down by n back to 16-bit precision (achieving
nothing). The fix breaks other codepaths that we don't use but the
performance gain is big enough to warrant a fork.

Can you provide a commit/diff/link for reference?
The way you describe it makes it appear as if these calculations are
needed sometimes, but not always. If so, there should be away to teach
libswscale to only do these calculations if they are necessary.

Post by Kieran Kunhya
FWIW I think debian should also enable libavresample. This code has
been proven to be more robust internally and was designed by a larger
group instead of libswresample which was basically one person (and
literally appeared in git out of nowhere).

FWIW I already enabled libavresample in the Debian FFmpeg package for
compatibility reasons [1].
Still I would be interested in any proof of libavresample being 'more
robust internally'.

Best regards,
Andreas

1:
https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/commit/?id=e6d32135ec5ada648465aba8d4daad58b86ff8d0

[Kieran Kunhya]

On 9 August 2014 19:25, Andreas Cadhalpun

I can understand that statically linking is easier from an upstream point of
view, but it has important disadvantages for a distribution such as Debian
and thus should be avoided if possible.
It is also the responsibility of a distribution to make sure that there are
no ABI mismatches or similar problems.

I'm not saying Debian should do that - just that it is sometimes
worthwhile for people like myself and mythtv to do so.

Can you provide a commit/diff/link for reference?
The way you describe it makes it appear as if these calculations are needed
sometimes, but not always. If so, there should be away to teach libswscale
to only do these calculations if they are necessary.

I hacked it in:
https://github.com/kierank/ffmpeg-obe/commit/5a354020872bec61bea6be7604ec8809af463021

I made it a bit cleaner later but still ugly overall.

Kieran

[wm4]

On Sat, 09 Aug 2014 20:25:09 +0200

Post by Andreas Cadhalpun
Hi Kieran,

Post by Kieran Kunhya
The reality is that in the current state of affairs static linking is
the *only* way you are guaranteed to have the features you expect and
avoid ABI mismatches. It's very complicated when your users complain
about bugs in an underlying library that is either too old on a system
or the wrong flavour of the fork. Then your users have to rebuild a
massive dependency chain to fix that bug or hope for the best in the
future.

I can understand that statically linking is easier from an upstream
point of view, but it has important disadvantages for a distribution
such as Debian and thus should be avoided if possible.
It is also the responsibility of a distribution to make sure that there
are no ABI mismatches or similar problems.

Post by Kieran Kunhya
We also use a fork specifically to work around very wasteful
calculations in libswscale during 10-bit chroma conversion that
involve multiplying a pixel by a 2^n value with 32-bit precision and
then shifting that value down by n back to 16-bit precision (achieving
nothing). The fix breaks other codepaths that we don't use but the
performance gain is big enough to warrant a fork.

Can you provide a commit/diff/link for reference?
The way you describe it makes it appear as if these calculations are
needed sometimes, but not always. If so, there should be away to teach
libswscale to only do these calculations if they are necessary.

Post by Kieran Kunhya
FWIW I think debian should also enable libavresample. This code has
been proven to be more robust internally and was designed by a larger
group instead of libswresample which was basically one person (and
literally appeared in git out of nowhere).

FWIW I already enabled libavresample in the Debian FFmpeg package for
compatibility reasons [1].

That's pretty nice! Maybe now people don't have to deal with two
extremely similar yet slightly different resampling libraries. It
really takes the cake when you try making your software work with both
FFmpeg and Libav.

Unfortunately, FFmpeg vehemently resists against enabling lavr by
default.

Post by Andreas Cadhalpun
Still I would be interested in any proof of libavresample being 'more
robust internally'.
Best regards,
Andreas
https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/commit/?id=e6d32135ec5ada648465aba8d4daad58b86ff8d0
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Nicolas George]

Post by wm4
Unfortunately, FFmpeg vehemently resists against enabling lavr by
default.

If someone cared enough, they would be making their case: posting
benchmarks, listing features present in each library but absent in the
other, comparing the APIs to see which one is most convenient for which
task, etc.

Regards,

[wm4]

On Sun, 10 Aug 2014 13:25:03 +0200

Post by Nicolas George

Post by wm4
Unfortunately, FFmpeg vehemently resists against enabling lavr by
default.

If someone cared enough, they would be making their case: posting
benchmarks, listing features present in each library but absent in the
other, comparing the APIs to see which one is most convenient for which
task, etc.

You seem to be under the impression that this matters.

I don't want to have to develop for two slightly similar but
different APIs, the end. And I don't want anyone else having to do that
either.

You're welcome to add a lavr API wrapper to swr, or to merge swr
features into lavr, or to convince Libav to pick up swr in favor of
lavr - just don't torture me with your API wars, OK?

[Nicolas George]

Post by wm4
You seem to be under the impression that this matters.

That is the only thing that matters in FFmpeg: people work on what they
consider important.

Post by wm4
I don't want to have to develop for two slightly similar but
different APIs, the end. And I don't want anyone else having to do that
either.
You're welcome to add a lavr API wrapper to swr, or to merge swr
features into lavr, or to convince Libav to pick up swr in favor of
lavr - just don't torture me with your API wars, OK?

You demand a lot, but nobody has a duty to meet your demands.

Yes, the situation with the two resampling libraries is bad for users, but
it will only be resolved if someone who cares about it does the job. I do
not. And as with the rest of FFmpeg, technical arguments will decide the
course of the project. If you were to prove that lavr is superior to lswr,
it would certainly be adopted.

But nothing will happen if nobody steps in.

Regards,

[Michael Niedermayer]

Post by Nicolas George

Post by wm4
You seem to be under the impression that this matters.

That is the only thing that matters in FFmpeg: people work on what they
consider important.

Post by wm4
I don't want to have to develop for two slightly similar but
different APIs, the end. And I don't want anyone else having to do that
either.
You're welcome to add a lavr API wrapper to swr, or to merge swr
features into lavr, or to convince Libav to pick up swr in favor of
lavr - just don't torture me with your API wars, OK?

You demand a lot, but nobody has a duty to meet your demands.
Yes, the situation with the two resampling libraries is bad for users, but
it will only be resolved if someone who cares about it does the job. I do
not. And as with the rest of FFmpeg, technical arguments will decide the
course of the project. If you were to prove that lavr is superior to lswr,
it would certainly be adopted.
But nothing will happen if nobody steps in.

theres another aspect that was mentioned on IRC but i belive not the
ML.
swr is easy to maintain for us, we can change it in any way if we
need to.
avr is maintained by libav and if we need or want major changes thats
not nearly so easy.
also while there are some very loud advocates pushing for avr
none of them has volunteered to maintain avr or provide security
support for it.This makes the suggestion to use avr quite dishonest
IMO.

I definitively will not maintain avr, its just a fork of my swr code
and iam happy to merge improvments back into swr.
and while some may claim theres no such thing as the need for a
avr maintainer in ffmpeg. trying to build ffmpeg with avr and trying
the avr regression tests will show that it simply doesnt work that
way.

So i would suggest that we all work together and pull on the same
string in the same direction and work on swr.
That also includes all the libav developers, everyone of them is
welcome without exception to work on swr, if they feel its lacking
something that avr has, patches, pull requests or direct commits are
welcome!
If API users feel that swr is not similar enough to avr, some
API wraper to provide the avr API from a swr implemetation is welcome

[...]

[Michael Niedermayer]

On Sat, Aug 09, 2014 at 06:26:19PM +0100, Kieran Kunhya wrote:
[...]

... and was designed by a larger
group instead of libswresample which was basically one person (and
literally appeared in git out of nowhere).

For the record:
$ git shortlog libswresample/ | grep '^[^ ]'
Alexander Strasser (1):
Andreas Cadhalpun (1):
Andrew Wason (1):
Carl Eugen Hoyos (4):
Clément Bœsch (45):
Derek Buitenhuis (1):
Hendrik Leppkes (1):
James Almer (19):
Justin Ruggles (4):
Lou Logan (2):
Mans Rullgard (3):
Martin Storsjö (1):
Marton Balint (2):
Matt Oliver (2):
Michael Niedermayer (308):
Nicolas George (8):
Paul B Mahol (4):
Reimar Döffinger (3):
Rob Sykes (7):
Ronald S. Bultje (15):
Stefano Sabatini (6):
Timothy Gu (10):
jamal (2):

$ git shortlog libavresample/ | grep '^[^ ]'
Anton Khirnov (25):
Derek Buitenhuis (2):
Diego Biurrun (22):
Hendrik Leppkes (1):
James Almer (2):
Janne Grunau (5):
John Stebbins (2):
Justin Ruggles (71):
Luca Barbato (1):
Mans Rullgard (4):
Martin Storsjö (6):
Michael Niedermayer (97):
Peter Meerwald (1):
Reimar Döffinger (2):
Ronald S. Bultje (2):
Thilo Borgmann (1):
Tim Walker (2):


[...]

[Kieran Kunhya]

[...]

... and was designed by a larger
group instead of libswresample which was basically one person (and
literally appeared in git out of nowhere).

http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b5875b91113a0f3de6ad61e9ff8b74b81de94760

There was no mailing list discussion and initial bugs had to be
discussed on ffmpeg-cvs. It appeared out of nowhere and there was no
discussion about the API. Many of the contributors were cleaning the
inline asm up or various other fixes or had worked on the original
resample code.

The comparison you make is highly misleading. On the other hand
libavresample was developed by consensus and the API discussed
beforehand.

[Jean-Yves Avenard]

Post by Matthias Urlichs
Most forks cause additional work which, in the long term, is better spent
elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal
world, you wouldn't need the mythtv fork either.
Debian's position is that we _really_ want to avoid having multiple copies
of essentially the same code in the archive; it's additional work for the
security team (if they even know about the copies), needlessly eats memory
when the two are in use simultaneously, and causes no end of trouble when a
plug-in is linked against copy A while the main code (or another plugin)
uses copy B (unless everybody is very careful WRT symbol versioning).

I beg to differ.

What would be a massive amount of waste, both in time and resources,
would be to have a project such as MythTV having to handle multiple
versions of a dependency.

Especially one such as libav* where the API changes often, and more
often than not in a totally incompatible manner from one API to the
next.
Including rename of constants (code enums id for example). You would
have to keep your own headers (like what Firefox/Mozilla is doing) and
have multiple code paths only adding to the difficulty of proper
coverage testing...

Keeping your own static version is the only reasonable approach.
As far as naming and conflicts, I don't see what the problem is unless
it's improperly packaged, or for example when the packagers decide
that they know better than the original authors and start to do weird
thing, modify the code as they wish. That's where the issues are most
of the time.
Sounds familiar ? :)

[Matthias Urlichs]

Hi,

Post by Jean-Yves Avenard
Including rename of constants (code enums id for example).

Another nail in libav's coffin, then.

IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.

Post by Jean-Yves Avenard
Keeping your own static version is the only reasonable approach.

That may be OK on Windows. However, a proper Linux distribution is supposed
to be an integrated whole and not a haphazard collection of programs, each
bringing along their own copy of core libraries and their own un- or
semi-fixed security problems.

[Andrew Kelley]

Post by Matthias Urlichs

Post by Jean-Yves Avenard
Including rename of constants (code enums id for example).

Another nail in libav's coffin, then.
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.

High quality libraries must iterate on their API. Especially for a library
trying to solve such a complex problem as audio and video encoding and
decoding for every codec and format. It is unreasonable to expect no
incompatible changes. Also both ffmpeg and libav codebases have a lot of
legacy cruft. Libav is making a more concentrated effort at improving this,
and the evolving API is a side-effect of that.

[Matthias Urlichs]

Hi,

It is unreasonable to expect no incompatible changes.

When somebody renames constants, a compatibility #ifdef or two is not too
much to ask, IMHO.

Libav is making a more concentrated effort at improving this,
and the evolving API is a side-effect of that.

That begs the question whether they're still essentially the same library,
i.e. whether it's at all reasonable to expect code built using FFmpeg to
work with libav. Consequently, Debian should at least include it, even
if it really _is_ too late to switch (which I'm not conviced of).

[wm4]

On Sun, 10 Aug 2014 09:43:03 +0200

Post by Matthias Urlichs
Hi,

It is unreasonable to expect no incompatible changes.

When somebody renames constants, a compatibility #ifdef or two is not too
much to ask, IMHO.

AFAIK such a thing existed, but it's possible that they weren't kept
around long enough.

Post by Matthias Urlichs

Libav is making a more concentrated effort at improving this,
and the evolving API is a side-effect of that.

That begs the question whether they're still essentially the same library,
i.e. whether it's at all reasonable to expect code built using FFmpeg to
work with libav. Consequently, Debian should at least include it, even
if it really _is_ too late to switch (which I'm not conviced of).

Huh? FFmpeg merges all API changes from Libav. For the record, many
changes Libav does are _good_.

[Theodore Ts'o]

Post by Andrew Kelley
High quality libraries must iterate on their API. Especially for a library
trying to solve such a complex problem as audio and video encoding and
decoding for every codec and format. It is unreasonable to expect no
incompatible changes. Also both ffmpeg and libav codebases have a lot of
legacy cruft. Libav is making a more concentrated effort at improving this,
and the evolving API is a side-effect of that.

I beg to differ. My definition of a "high quality library" is one
where careful design is taken into account when designing the
ABI/API's in the first place, and which if absolutely necessary, uses
ELF symbol versioning to maintain ABI compatibility.

There are plenty of "high quality libraries" (glibc, libext2fs, etc.)
where we've been able to maintain full ABI compatibility even while
adding new features --- including in the case of libext2fs, migrating
from 32-bit to 64-bit block numbers. And if you're careful in your
design and implementation, the amount of cruft required can be kept to
a very low minimum.

- Ted

[Reimar Döffinger]

Hello,

Apologies for not being able to resist answering even if it is getting
off-topic.

Post by Theodore Ts'o

Post by Andrew Kelley
High quality libraries must iterate on their API. Especially for a library
trying to solve such a complex problem as audio and video encoding and
decoding for every codec and format. It is unreasonable to expect no
incompatible changes. Also both ffmpeg and libav codebases have a lot of
legacy cruft. Libav is making a more concentrated effort at improving this,
and the evolving API is a side-effect of that.

I beg to differ. My definition of a "high quality library" is one
where careful design is taken into account when designing the
ABI/API's in the first place, and which if absolutely necessary, uses
ELF symbol versioning to maintain ABI compatibility.
There are plenty of "high quality libraries" (glibc, libext2fs, etc.)
where we've been able to maintain full ABI compatibility even while
adding new features --- including in the case of libext2fs, migrating
from 32-bit to 64-bit block numbers. And if you're careful in your
design and implementation, the amount of cruft required can be kept to
a very low minimum.

While you certainly have a point that we have a lot to learn and improve,
your comparison is not entirely fair, for reasons like

a) glibc, libext2fs are much older projects, we still have to
pay for old sins, from times where everyone was happy when
their video played at all on Linux and nobody complained about
ABI compatibility. Not to mention few of us having much experience
in software development.

b) A good number of our users are on Windows, which makes symbol
versioning a very undesirable solution. Sometimes that means alternative
solutions which are messier or more likely to break compatibility by
accident

c) For libext2fs your users won't claim a file system is ext2, when it
is actually btrfs and still expect your ext2 library to work with it!
That is very much the standard in multimedia ("everything is .avi",
"I don't care what format it is, I just want it to play", ...).
Nor do you have competing ext2 implementations adding completely
mis-designed extensions to it, with everyone expecting you to support it, that
definitely makes API design a _lot_ more challenging.

d) At least in the case of glibc that backwards-compatibility is not at
all free to its current users. _IO_stdin_used is a prime example of that,
anyone playing with methods to reduce binary size/strip symbols will stumble
over that and curse very loudly at some point.
I certainly would have preferred it to not be ABI compatible in that
case!

Regards,
Reimar

[wm4]

On Mon, 11 Aug 2014 20:40:28 +0200

Post by Reimar Döffinger
Hello,
Apologies for not being able to resist answering even if it is getting
off-topic.

Post by Theodore Ts'o

Post by Andrew Kelley
High quality libraries must iterate on their API. Especially for a library
trying to solve such a complex problem as audio and video encoding and
decoding for every codec and format. It is unreasonable to expect no
incompatible changes. Also both ffmpeg and libav codebases have a lot of
legacy cruft. Libav is making a more concentrated effort at improving this,
and the evolving API is a side-effect of that.

I beg to differ. My definition of a "high quality library" is one
where careful design is taken into account when designing the
ABI/API's in the first place, and which if absolutely necessary, uses
ELF symbol versioning to maintain ABI compatibility.
There are plenty of "high quality libraries" (glibc, libext2fs, etc.)
where we've been able to maintain full ABI compatibility even while
adding new features --- including in the case of libext2fs, migrating
from 32-bit to 64-bit block numbers. And if you're careful in your
design and implementation, the amount of cruft required can be kept to
a very low minimum.

While you certainly have a point that we have a lot to learn and improve,
your comparison is not entirely fair, for reasons like
a) glibc, libext2fs are much older projects, we still have to
pay for old sins, from times where everyone was happy when
their video played at all on Linux and nobody complained about
ABI compatibility. Not to mention few of us having much experience
in software development.

Build something on a newer glibc system, and try to run the binary on
an older system. It most likely won't work - even if it could in
theory. (At least it was this way some years ago. Probably still is.)
So glibc might achieve some ABI backwards-compatibility, but the truth
is that they have many many issues, and the symbol versioning merely
paints them over. They can only dream of ABI compatibility as solid
as kernel32.dll's.

Post by Reimar Döffinger
b) A good number of our users are on Windows, which makes symbol
versioning a very undesirable solution. Sometimes that means alternative
solutions which are messier or more likely to break compatibility by
accident

To be fair, FFmpeg does its own "manual" symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public structs. Imagine a new API user fighting to
guess which fields in AVCodecContext must be set, or which must not be
set. Seasoned FFmpeg developers probably don't know the horror.

Post by Reimar Döffinger
c) For libext2fs your users won't claim a file system is ext2, when it
is actually btrfs and still expect your ext2 library to work with it!
That is very much the standard in multimedia ("everything is .avi",
"I don't care what format it is, I just want it to play", ...).
Nor do you have competing ext2 implementations adding completely
mis-designed extensions to it, with everyone expecting you to support it, that
definitely makes API design a _lot_ more challenging.

Even more importantly, libext2fs has a very specific use case. Not only
is there only ext2fs "vendor", it's also a pretty simple problem. IF
you really want to make a fair comparison, you'd have to compare FFmpeg
with a filesystem abstraction library that allows low-level accesses.

I think the largest issue with FFmpeg is actually that it's so
low-level. Users usually have to connect the individual libraries
themselves, and that is very error prone. Hell, even the official
FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem
to be broken to hell.

I think there should be a higher-level FFmpeg library that takes care
of these things.

Post by Reimar Döffinger
d) At least in the case of glibc that backwards-compatibility is not at
all free to its current users. _IO_stdin_used is a prime example of that,
anyone playing with methods to reduce binary size/strip symbols will stumble
over that and curse very loudly at some point.
I certainly would have preferred it to not be ABI compatible in that
case!

I have the feeling glibc would have it easier if they wouldn't expose so
many internals. If you compile a program written against standard C and
POSIX, it will reference the strangest glibc symbols.

Post by Reimar Döffinger
Regards,
Reimar
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Theodore Ts'o]

Post by wm4
To be fair, FFmpeg does its own "manual" symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public structs. Imagine a new API user fighting to
guess which fields in AVCodecContext must be set, or which must not be
set. Seasoned FFmpeg developers probably don't know the horror.

There are some best practices in API design; one of them is to
minimize public structs as much as possible. Instead, have blind
pointers which are handed back by an "initialize object" function, and
then have setter/getter functions that allow you to fetch various
parameters or flags which modify how the object behaves. This allows
you to add or deprecate new flags, configuration parameters, in a
relatively sane way.

I have this dream/fantasy where all of the energy over developing and
maintaining two forks was replaced by a spirit of cooperations and the
developers working together to design a new API from scratch that
could be guaranteed to be stable, and then applications migrated over
to use this stable, well-designed, future-proofed API.

Call me a naive, over-optimistic dreamer, but.... :-)

(And, the yes, the new API probably should be a bit higher level.)

"Can we all just get along?" --

- Ted

[wm4]

On Mon, 11 Aug 2014 18:34:23 -0400

Post by Theodore Ts'o

Post by wm4
To be fair, FFmpeg does its own "manual" symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public structs. Imagine a new API user fighting to
guess which fields in AVCodecContext must be set, or which must not be
set. Seasoned FFmpeg developers probably don't know the horror.

There are some best practices in API design; one of them is to
minimize public structs as much as possible. Instead, have blind
pointers which are handed back by an "initialize object" function, and
then have setter/getter functions that allow you to fetch various
parameters or flags which modify how the object behaves. This allows
you to add or deprecate new flags, configuration parameters, in a
relatively sane way.

Yes. Unfortunately, central data structures are still public, and just
making them opaque and adding accessors on top of them would lead to a
major compatibility issue, and all developers using ffmpeg would
complain big time.

In fact, the API cleanup is an ongoing process, and is what causes the
incompatibilities with each release. For example, a C library should
have a consistent naming schema. FFmpeg/Libav decided to use AV and av_
as prefixes for all symbols in the public header files. This required
fixing some symbols, which of course broke some applications.

Post by Theodore Ts'o
I have this dream/fantasy where all of the energy over developing and
maintaining two forks was replaced by a spirit of cooperations and the
developers working together to design a new API from scratch that
could be guaranteed to be stable, and then applications migrated over
to use this stable, well-designed, future-proofed API.
Call me a naive, over-optimistic dreamer, but.... :-)
(And, the yes, the new API probably should be a bit higher level.)
"Can we all just get along?" -- http://youtu.be/1sONfxPCTU0
- Ted

Yes, that would be nice. The FFmpeg/Libav split is mostly a
political/social issue though: it seems some (not all) members from
each side just can't deal with some (not all) members from the other
side.

How do you fix this? It seems impossible.

(Also, btw.: sometimes the low level aspect of the libraries is simply
needed. It's just that most applications would be better off with a
more high level API.)

[Matthias Urlichs]

Hi,

Post by wm4
In fact, the API cleanup is an ongoing process, and is what causes the
incompatibilities with each release. For example, a C library should
have a consistent naming schema. FFmpeg/Libav decided to use AV and av_
as prefixes for all symbols in the public header files. This required
fixing some symbols, which of course broke some applications.

One could add weak aliases and/or marked-as-deprecated C macros
instead of doing a "hard" renaming.

To be fair, the GCC change which even allowed emitting a warning upon use
of a macro isn't _that_ old …

Post by wm4
Yes, that would be nice. The FFmpeg/Libav split is mostly a
political/social issue though: it seems some (not all) members from
each side just can't deal with some (not all) members from the other
side.
How do you fix this? It seems impossible.

Kick the non-cooperating people off both projects. :-P

(One slight problem with this solution is that the net effect is likely to
be three forks instead of two, not one …)

Post by wm4
(Also, btw.: sometimes the low level aspect of the libraries is simply
needed. It's just that most applications would be better off with a
more high level API.)

Most CS problems can be solved by adding yet another level of indirection –
except for the problem of having too many levels of indirection and –
relevant here – the associated decrease in speed.

[wm4]

On Tue, 12 Aug 2014 16:51:40 +0200

Post by Matthias Urlichs
Hi,

Post by wm4
In fact, the API cleanup is an ongoing process, and is what causes the
incompatibilities with each release. For example, a C library should
have a consistent naming schema. FFmpeg/Libav decided to use AV and av_
as prefixes for all symbols in the public header files. This required
fixing some symbols, which of course broke some applications.

One could add weak aliases and/or marked-as-deprecated C macros
instead of doing a "hard" renaming.

But this was done:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=104e10fb426f903ba9157fdbfe30292d0e4c3d72

FFmpeg still has them, Libav removed them about half a year after
adding them.

Post by Matthias Urlichs
To be fair, the GCC change which even allowed emitting a warning upon use
of a macro isn't _that_ old …

Post by wm4
Yes, that would be nice. The FFmpeg/Libav split is mostly a
political/social issue though: it seems some (not all) members from
each side just can't deal with some (not all) members from the other
side.
How do you fix this? It seems impossible.

Kick the non-cooperating people off both projects. :-P
(One slight problem with this solution is that the net effect is likely to
be three forks instead of two, not one …)

Yes, or kill the project entirely, since key people would have to be
kicked off. A bit of a problem, as you see.

Post by Matthias Urlichs

Post by wm4
(Also, btw.: sometimes the low level aspect of the libraries is simply
needed. It's just that most applications would be better off with a
more high level API.)

Most CS problems can be solved by adding yet another level of indirection –
except for the problem of having too many levels of indirection and –
relevant here – the associated decrease in speed.

Speed wouldn't be affected here, since the "hard work" is done in
libavcodec anyway.

[compn]

On Tue, 12 Aug 2014 16:51:40 +0200

Post by Matthias Urlichs
Hi,

Post by wm4
Yes, that would be nice. The FFmpeg/Libav split is mostly a
political/social issue though: it seems some (not all) members from
each side just can't deal with some (not all) members from the other
side.
How do you fix this? It seems impossible.

Kick the non-cooperating people off both projects. :-P

at least 6+ devels refuse to work with each other , thats only a
quick estimation, i havent polled everyone lately. ffmpeg and libav devs
dont even TALK to each other. theres a couple devs who frequent both
irc/lists, most do not.

Post by Matthias Urlichs
(One slight problem with this solution is that the net effect is
likely to be three forks instead of two, not one …)

i wrote up a current status of the projects,
http://wiki.multimedia.cx/index.php?title=User_talk:Compn

yes, you are correct, baptiste left and created ffmbc.
ffmbc is nice, if we play our cards correctly we can get it merged into
ffmpeg.

-compn

[Attila Kinali]

On Tue, 12 Aug 2014 14:04:32 -0400

Post by compn
at least 6+ devels refuse to work with each other , thats only a
quick estimation, i havent polled everyone lately. ffmpeg and libav devs
dont even TALK to each other. theres a couple devs who frequent both
irc/lists, most do not.

This is not entirely true. There are people who talk to eachother.
But it is mostly kept under wraps as some zealots think that talking
to "the others" is a mortal sin and anyone who does it needs to be
punished.

Heck, i remember how i was sitting with some FFmpeg guys during lunch at
the Videolan Developers Days last year. We had some discussion
going on, nothing serious, mostly smalltalk, but still a discussion.
When Diego Biurrun joined our table everyone suddenly fell silent.
It felt like being in some second rate sitcom...

But that's personal issues between the developers and does not
belong to debian-devel.

Post by compn
i wrote up a current status of the projects,
http://wiki.multimedia.cx/index.php?title=User_talk:Compn

Thanks for writing that up. There are certain things i would
like to add there or write diffently, but i will contact you off list
for that.


Attila Kinali

[Matthias Urlichs]

Hi,

Post by wm4
Build something on a newer glibc system, and try to run the binary on
an older system. It most likely won't work - even if it could in
theory. (At least it was this way some years ago. Probably still is.)

What would be the point of introducing new or updated interfaces
if you then couldn't use them?

ABI backwards compatibility is not a goal I would want to spend any time
on. Forward compatibility, on the other hand …

Post by wm4
To be fair, FFmpeg does its own "manual" symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public structs. Imagine a new API user fighting to
guess which fields in AVCodecContext must be set, or which must not be
set. Seasoned FFmpeg developers probably don't know the horror.

That's reasonably easy – you add a function to allocate the structure for
you. That function sets a version field and/or initializes everything to
a sane default. Also, you never shrink the structure, or move fields.

Obviously, you also tell people to never ever embed the thing directly in
something else, assuming that you can't keep it opaque entirely.

Of course, it's only easy if you design your API that way from the
beginning …

Post by wm4
I think the largest issue with FFmpeg is actually that it's so
low-level. Users usually have to connect the individual libraries
themselves, and that is very error prone. Hell, even the official
FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem
to be broken to hell.
I think there should be a higher-level FFmpeg library that takes care
of these things.

gstreamer-ffmpeg?

[wm4]

On Tue, 12 Aug 2014 02:54:39 +0200

Post by Matthias Urlichs
Hi,

Post by wm4
Build something on a newer glibc system, and try to run the binary on
an older system. It most likely won't work - even if it could in
theory. (At least it was this way some years ago. Probably still is.)

What would be the point of introducing new or updated interfaces
if you then couldn't use them?

Apparently this happens even if an application only uses C99 and POSIX
standard symbols.

Post by Matthias Urlichs
ABI backwards compatibility is not a goal I would want to spend any time
on. Forward compatibility, on the other hand …

Well, I think it's a pretty common complaint from commercial software
vendors. That you can't distribute precompiled binaries reasonably.

Post by Matthias Urlichs

Post by wm4
To be fair, FFmpeg does its own "manual" symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public structs. Imagine a new API user fighting to
guess which fields in AVCodecContext must be set, or which must not be
set. Seasoned FFmpeg developers probably don't know the horror.

That's reasonably easy – you add a function to allocate the structure for
you. That function sets a version field and/or initializes everything to
a sane default. Also, you never shrink the structure, or move fields.
Obviously, you also tell people to never ever embed the thing directly in
something else, assuming that you can't keep it opaque entirely.

That's already the case with most libav* data structures.

Post by Matthias Urlichs
Of course, it's only easy if you design your API that way from the
beginning …

Post by wm4
I think the largest issue with FFmpeg is actually that it's so
low-level. Users usually have to connect the individual libraries
themselves, and that is very error prone. Hell, even the official
FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem
to be broken to hell.
I think there should be a higher-level FFmpeg library that takes care
of these things.

gstreamer-ffmpeg?

gstreamer has more problems than it solves. (Forces glib/gobject on
you, GTK-style OOP, pretty crashy, tons of low-quality plugins,
complicated API and design, ...)

[Matthias Urlichs]

Hi,

Post by wm4

Post by Matthias Urlichs
ABI backwards compatibility is not a goal I would want to spend any time
on. Forward compatibility, on the other hand …

Well, I think it's a pretty common complaint from commercial software
vendors. That you can't distribute precompiled binaries reasonably.

They need to compile the software with the lowest-possible version of the
library which they can reasonably use (and which is still API compatible
with the hightest that's in general use).

This is hardly rocket science, but requires care from all participants.

Post by wm4

Post by Matthias Urlichs
gstreamer-ffmpeg?

gstreamer has more problems than it solves. (Forces glib/gobject on
you, GTK-style OOP, pretty crashy, tons of low-quality plugins,
complicated API and design, ...)

Yeah, I know. Missing Snarky Smiley Syndrome on my part.

[Jean-Yves Avenard]

Hi

Post by Matthias Urlichs
Hi,
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.

Then it becomes unreasonable for a piece of software to be compatible
with multiple version of the same library, and support all of those.

When a used come to use complaining that something is broken, that a
file doesn't play or what else. It's a moot point trying to expect
them to understand that the issue is due to a 3rd party library.

MythTV aimed to be an appliance-like application. You install it and
you forget about it.

[Andrew Kelley]

Post by Jean-Yves Avenard
Then it becomes unreasonable for a piece of software to be compatible
with multiple version of the same library, and support all of those.

IMO it's not worth the effort to support multiple versions of the same
library. If you want to use an old library, use an old version of the
software.

[Jean-Yves Avenard]

Post by Andrew Kelley
IMO it's not worth the effort to support multiple versions of the same
library. If you want to use an old library, use an old version of the
software.

In our case, we have very long release cycles. Usually only once a
year at best. We have users on virtually all platforms. We can't
assume the OS/distribution it will be running on will have the library
we're hoping for.

In the perfect world, sure all platforms would all be running the same
versions of a given lib at a given time... In practice it never
happens.

[Andreas Cadhalpun]

Hi Reinhard,

Post by Matthias Urlichs
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.

This is exactly what Libav is doing: The deprecation process for
symbols, APIs, enums, etc. takes *years*, because so many software
packages in Debian and else where use them, and it is so believably
painful to change them. Just have a look at the last two Libav
transitions, and the massive amount of patches it took to get packages
fixed and eventually to get Debian to the new Libav release.
Now enter FFmpeg.

FFmpeg also has a deprecation process and keeps deprecated features
around longer than Libav. For example, avcodec_encode_video,
av_close_input_file and avcodec_decode_audio3 are still present in
FFmpeg, but already removed from Libav.

FFmpeg has a significant higher release frequency, (it seems to me
about every 3-4 months), so that you would get a deprecation cycle
that is considerably less than a year.

The deprecation cycle is not related to the release frequency, as many
FFmpeg release are API/ABI backwards compatible with the previous one.

In practice, the deprecation
cycle more or less seems to match Libav's cycle, because at least
right now, FFmpeg tracks Libav's API. If that were not the case (and
I promise you FFmpeg would stop tracking Libav as soon as it replaces
Libav in Debian), I can almost guarantee [1] you that FFmpeg would
very much prefer to resume to the deprecation cycle the project
before: None, i.e., every piece of software is expected to keep up
with FFmpeg's master branch for reasons Jean-Yves outlines.

I think you won't be able to keep that promise, because it wouldn't make
much sense to stop merging changes from Libav (especially, if they are
useful) after doing it for such a long time. Even in the unlikely event
that this might happen, there is no reason to change the handling of
deprecations.

[1] at least statements such as
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html
strongly suggest this (at least if you have followed the
libavresample/libswresample mess).

I'm understanding this mail differently: What Michael is explaining is
that it is more difficult for FFmpeg to change things in libavresample
than in libswresample, because Libav is unlikely to merge back changes,
but FFmpeg tries to be compatible with Libav.

In reality, there hasn't been any backwards incompatible change in
libswresample (still soversion 0), but there has been one in
libavresample (now at soversion 1).

Post by Matthias Urlichs

Post by Jean-Yves Avenard
Keeping your own static version is the only reasonable approach.

That may be OK on Windows. However, a proper Linux distribution is supposed
to be an integrated whole and not a haphazard collection of programs, each
bringing along their own copy of core libraries and their own un- or
semi-fixed security problems.

BTW Jean-Yves outlines an approach that used to be very common on the
past: Pick some particular snapshot of FFmpeg and maintain that in a
downstream project, and expect users to use that because it is too
much effort to keep up with FFmpeg's release frequency.

It is easy to 'keep up' with releases that are API/ABI compatible, which
many FFmpeg releases are.
One doesn't even have to recompile dependent programs (if they are not
buggy), one can just install the new version of the libraries.

Prominent
examples of projects that did this (and actually, still do) include
xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess
I was talking about in my previous email: dozens of embedded
code-copies that were accepted into the Debian archive.

As you must know, xine-lib and xbmc are - and mplayer was - compiled
against the system version of Libav in Debian.

Over many years, I've spearheaded a significant effort in Debian with
packaging and in upstream with introducing a release culture in FFmpeg
(as release manager) to get to somewhat same release frequencies, so
that downstream projects at least had a chance to agree on common
versions of FFmpeg. At the time of the split, I was worried that this
work would have been in vain.

It appears your work has not have been in vain, as FFmpeg's current
release culture takes into account that any backwards incompatible API
change means a lot of work for everyone using it. I believe this is
handled now much better than in the times before the 0.5 release.

If you are unhappy with how the releases are managed in FFmpeg, you can
always send your concerns to ffmpeg-devel (and I think you still have
commit rights for FFmpeg's git repository as well).

Considering that most active developers
of FFmpeg at that time (which coincidentally supported my approach to
release management and frequency) joined what is now known as Libav, I
continued my work as upstream release manager in Libav, because I
consider Libav as much more suited for Debian than FFmpeg. Today, I
still firmly believe that this was the right move for Debian as a
project.

Conversely, I firmly believe, that the absence of FFmpeg from the
archive is bad for Debian's users. The reasons for that can be found in
my initial mail in this thread.

I do strongly believe that projects that require people to use FFmpeg
actually mean to use their own private fork (cf. the mythtv debacle),

As far as I know, MythTV is the only example for a program that cannot
be compiled with a system version of FFmpeg and instead uses its own fork.

and given the amount of packages in Debian, it would significantly
much more effort to "port" (or "patch" as Andreas is phrasing it) them

As I explained in my initial mail in this thread [1], most of these
patches are only necessary for switching the packages to pkg-config to
detect the FFmpeg linker flags.
If the FFmpeg in Debian would use the upstream library names, i.e. the
same as Libav, these patches would not be necessary. One still can avoid
soname clashes by using the --enable-raise-major configure option and
thus bumping all major soversion by 100, but this is not done in order
to not use the same namespace that Libav in Debian currently uses and
because some programs (I only know of vlc) check for a maximum version
of the libraries.

There are only a few other changes necessary, and most of them are also
needed for Libav 10 (or even totally unrelated to FFmpeg/Libav).
For the benefit of everyone, here is a comprehensive list of those:
* acoustid-fingerprinter: Still uses CodecID in a codepath not used,
when compiled against Libav.
* bino: Currently fails to build due to a gettext version mismatch [2].
* dvswitch: Still uses CodecID (and also avcodec_encode_video, but
that is still present in FFmpeg.) [3]
* ffdiaporama: The libav10.patch introduces incompatible API
(avfilter_graph_parse).
* k3b: Still uses CodecID (and also av_close_input_file and
avcodec_decode_audio3, but these are still present in FFmpeg.)
Therefore the FFmpeg plugin has been disabled. [4]
* libextractor: Misses build-dependencies for the FFmpeg plugin. [5]
* miro: Still uses CodecID (and also fails to build with Libav 10). [6]
* mplayer2: MP_INPUT_BUFFER_PADDING_SIZE has to be increased to 32,
because FFmpeg needs 32-byte padding.
* netgen: Still uses CodecID, av_get_pict_type_char,
avcodec_alloc_context and avcodec_open, but the linking with libav
libraries has been disabled, see [7].
* renpy: Still uses AVCODEC_MAX_AUDIO_FRAME_SIZE in a codepath not
used, when compiled against Libav.
* xbmc: The '--enable-libav-compat' needs to be removed, when compiling
against FFmpeg.
* zoneminder: Misses a build-dependency on libgcrypt11-dev. [8]

As you seem to not believe me, I'm going to send all the patches to the
BTS, so that everyone can judge the amount of work for themselves.

Making sure they work with the version of Libav's libavcodec.so
implementation.

This seems like more work, because, for example, I don't know about any
patches fixing the problems XMBC has with Libav and they don't seem to
be straightforward to fix.

This thread has shown a couple of examples that
support this argument: Mythtv, but also mplayer that claims to work
with a system libavcodec.so, which is true as long as it matches the
version that is was built against.

MythTV shows nothing, because it uses its own fork and MPlayer works
fine with a system FFmpeg. There is no need to recompile it, except for
a major soversion bump, unless it has bugs I don't know about. Do you
know of such bugs?

I'm using a version of MPlayer compiled against FFmpeg 2.2 with the
FFmpeg libraries from 2.3 and it works for me.

This is what makes mplayer so hard
to package, and was ultimately the reason why I requested mplayer's
removal (which is more than ironic, given that back then, I fought
with ftp-master for many years to get it included into Debian in the
first place).

I have read MPlayer's removal bug and it shows clearly that the only
reason for its removal was, that it can't be compiled with Libav and
upstream is not interested in working on this, because of the missing
features in Libav.

On a related note: Most Libav developers are very tired of the
constant flamewars and defamation attempts that arises from FFmpeg.

I'm also very tired of flamewars in general and happy that this
discussion hasn't become one.

Over years, Libav tries to convinced everyone by providing usable
software releases.

That didn't succeed very well, at least not for me and all the other
people for which Libav doesn't work correctly.

Nevertheless, this particular debate is very
worrisome: The silence from the Libav camp seems to not to be taken as
consent. Quite the contrary is true.

Do you want to say here, that there are many people preferring Libav,
who haven't participated in this discussion?

This might or might not be true, but I would welcome anyone, who makes a
technical argument.

How to proceed from here? TBH, I'm not sure. Ideally, both projects
would find some common ground and "just merge" (however that would
technically look like).

Indeed, that would be the ideal solution, ...

However, this very debate within Debian shows
that this is unlikely to happen anytime soon: There is way to much
disagreement on very fundamental questions that require agreement
within a free software project, and the hostile and aggressive tone
the majority of participants in this debate exhibit does not help with
making progress on that front either.

... but I'm also under the impression that there is still too much bad
blood between both upstreams for this to happen.

On Fri, Aug 8, 2014 at 2:06 PM, Andreas Cadhalpun

Post by Matthias Urlichs
It would be nice, if you could also spent some time thinking about
the possibility of having both FFmpeg and Libav in Debian.

Please believe me that I did spend a lot of time thinking about this.
I firmly do not think that this is a reasonable approach. Please see
my other email on debian-devel as explanation.

To me it seems your other mail (above) doesn't mention the possibility
of having both, only:
"FFmpeg would stop tracking Libav as soon as it replaces Libav in Debian"

But if you are opposed to having both and also opposed to letting FFmpeg
replace Libav, it seems that it will be impossible to get a consensus here.

Therefore the technical committee will have to decide between:
a) having both FFmpeg and Libav in Debian
b) only having FFmpeg in Debian
c) only having Libav in Debian

As I haven't seen any convincing technical argument for only having
Libav, I doubt the technical committee's decision will be c).

Best regards,
Andreas


1: I'm getting tired of this phrase...
2: https://bugs.debian.org/757280
3: https://bugs.debian.org/747868
4: https://bugs.debian.org/739312
5: https://bugs.debian.org/755810
6: https://bugs.debian.org/748861
7: https://bugs.debian.org/751344
8: https://bugs.debian.org/745819

[Ben Hutchings]

On Sun, 2014-08-10 at 23:02 +0200, Andreas Cadhalpun wrote:
[...]

Post by Andreas Cadhalpun
* dvswitch: Still uses CodecID (and also avcodec_encode_video, but
that is still present in FFmpeg.) [3]

[...]

dvswitch was also broken by the removal of support for downscaled
decoding of DV video. I don't know whether that change is specific to
libav or was also made in FFmpeg.

Ben.

[Holger Levsen]

Hi,

Post by Ben Hutchings
dvswitch was also broken by the removal of support for downscaled
decoding of DV video. I don't know whether that change is specific to
libav or was also made in FFmpeg.

dvswitch is still broken and there is no dvswitch in jessie...

We have a daily job testing against libav from git, but that was alwayys
broken everyday in the last half year or so. Maybe it would be useful to setup
building against ffmpeg.


cheers,
Holger

[Peter B.]

Post by Matthias Urlichs
We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd
hate to report some intractable codec bug which Upstream closes with
an "it works with FFmpeg" comment

Oh, btw, just a few days ago, that's exactly what happened on kdenlive [1].
A developer posted the following statement on an issue which is open for
more than 1.5 years now:

[quote]
Confirm this is a libav problem, use builds with ffmpeg or wait debian
(&derivatives) to bring ffmpeg back
[/quote]

Just thought this might fit here...


Regards,
Pb


== References:
[1] http://www.kdenlive.org/mantis/view.php?id=2943#c10195

[Carl Eugen Hoyos]

Post by Alessio Treglia
Many Jessie's multimedia framework and packages
have been developed and QA'd with libav.

Could you name one framework or package that does
not work with FFmpeg (or does not have less bugs
with FFmpeg than with avconv libraries)?

I have never tested GStreamer myself but several
users reported that it compiles with FFmpeg and
that using FFmpeg fixed their issues.

Carl Eugen

[wm4]

On Fri, 8 Aug 2014 15:06:20 +0100

Post by Alessio Treglia
Hi,

Post by Matthias Urlichs
That leaves the question of the "official" opinion of the libav
Did none of them write anything in "defense" of libav, or have I simply
missed it?
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.

This is an eminently bad idea. As I said before, it's too late for
Jessie already.
Many Jessie's multimedia framework and packages have been developed
and QA'd with libav.
We've spent a lot of time over the past months talking to upstreams,
forwarding them our patches and make sure their programs and libraries
work with libav.
We've spent ***months*** in making the whole thing work, and dropping
libav in favour of FFmpeg at this point, roughly few weeks from the
freeze deadline, would be definitely insane.

I'm very interested in why packages would work with Libav, but not with
FFmpeg. I know for a fact that FFmpeg API is more compatible in general
(deprecated functionality is generally kept longer than in Libav, not
all API Libav removed is removed from FFmpeg). And also, FFmpeg's API
is a superset of Libav. So it could happen that a project doesn't work
with Libav because it uses FFmpeg-exclusive API, but not the other way
around.

The only real incompatibilities I know are:
- avfilter_graph_parse() function signature (can be fixed with some
ifdeffery)
- libavresample disabled by default (FFmpeg being trapped by their own
bullshit, wonderful)

Also, if does happen that software written for Libav works with the
latest Libav release, but not the latest FFmpeg release. This is simply
because Libav doesn't release as often, which increases the likelihood
that this project didn't update to newer APIs yet. But since Libav 10
was released relatively recently, and Libav 11 is planned to be
API-compatible, that should not be an issue currently.

[Jose Luis Rivas]

Post by Andreas Cadhalpun
Hi all,
some of you may have noticed a weird ffmpeg package in the NEW queue[1].
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.

Hi Andreas and everyone,

FWIW, my experience with this is that I had to make my own FFmpeg
package a while ago [0] because I needed it for a project I was working
on at the moment [1].

[0] https://github.com/ghostbar/FFmpeg.deb
[1] https://github.com/ghostbar/RTSP-Streaming.js

The reason for having to package my own FFmpeg is the current libav
which is taking the space of ffmpeg seemed to conflict with every other
ffmpeg package out there, including marillat's and for my project I
actually needed ffmpeg, not libav since it didn't had the functionality.
(More specifically: the ability to take still images from an rtsp
stream).

Not having FFmpeg available in the debian repositories is a nuissance,
and certainly having libav instead which seems to be a fork yet not
having the full FFmpeg functionality and using the same package name is
worst. I didn't figured this out at first because the binary said
`ffmpeg`. Of course, I'm talking about [2] since now that seems to not
be an issue yet remains the lack of functionality.

[2] https://packages.debian.org/wheezy/ffmpeg

If the issue is that this would mean having to fix security bugs twice
then it would be reasonable to stop shipping libav and instead ship
ffmpeg, since has more functionality and AFAICS from their repos bunch
of active bug-fixing.

I honestly do not understand why ffmpeg is not in the repos nor why
there seems to be an active movement to block it.

Kind regards.

[David Favor]

Post by Andreas Cadhalpun
Hi all,
some of you may have noticed a weird ffmpeg package in the NEW queue[1].

... ... ...

and make kittens cry...

... ... ...

Primary reason for Debian kittens crying right now... is ffmpeg being missing...

[Niv Sardi]

I feel the debate is going a bit on a tangent in this thread, so I'd like
to take an opportunity to recenter it a tad.​

​We have many issues that were risen in this thread, ​
​but ​
I believe that the cut has to be made by the people that we have in special
roles for; -security for security concerns, -release for release scheduling
and required transitions and our many maintainers of multimedia related
packages to know what they want to link their packages against
​​
​, and well, as it has been named, tech-ctte for technical matters that we
can't resolve in -devel.​

​In few words​
,
​this is how I understand​
the core of Andreas' plan, and has motivated many technical decisions in
the packaging.

​Many ​
​​
sensible
​ technical decisions that lead to a polite and correct way to go.

Now, our main blocker to get onto the next steps Andreas has exposed with
great detail in his original mail is that the package has been sitting in
NEW for the last
​3​
months.

As people voiced their feelings, it seems the vast majority does not
opposes having FFmpeg in experimental
​​.

So my point here is:
​Shouldn't we first get it in the archive ? ​
how can we help speed​ing
​ ​
it out of NEW ?

​The current packaging is a 'low-conflict' one, it can be easily
transitioned into replacing libav if that's what gets decided further down
the line. Hence, I see no blocker​ in getting it in.

The licencing has an ancestor with libav, and the new files have been
following the same inclusion pattern. So my guess is that the blocker may
be packaging quality, as the sponsor, I have checked it, but maybe we can
help reconfort ftpmasters with more eyes on it ?
​Thanks,​

[Jean-Yves Avenard]

Hi

Post by wm4
On Sat, 9 Aug 2014 11:46:40 +1000
Off-topic, but: it might be easier nowadays?
The strangest things that are not even related to video decoding are
getting merged - surely it's possible to merge things such as teletext.

In all honesty, we spent months trying to get our changes merge over
the course of 10+ years... There's unfortunately a time where one
gives up.

This is the core reason why we started to maintain our own fork.

We have now limited our changes to the bare minimum, and things have
diverged greatly since. Backporting our changes to our mpegts demuxer
would be significant work. And unfortunately, we are all very time
constrained these days (and me even more so as I've started a new job
at Mozilla)

[Michael Niedermayer]

On Tue, 12 Aug 2014 10:44:35 -0500

When this happened I scoured the net, including mailing lists from both
projects to try and figure out what had happened. The overwhelming
evidence based on mailing list posts, blog posts, forum discussions and
pretty much everywhere else I could look all led me to the overwhelming
conclusion of what I stated before. This is the only time I've ever
seen anything to the contrary stated and I looked good and hard for
another side of the story, as have many other people.

Part of the reason for this is that the people around libav decided
that they didn't want to participate in the mudslinging. Only the most
blatant lies were refuted and all the name calling was mostly ignored.
In hindsight that was a mistake.

I still don't know who is in the right, but at least you've put an end
to the weirdness where only one side of the story existed on the net
and there was just conspicuous silence on the other.

I'd like to give here a short account on what happend before the split,
even though this not the right place. I think i should write up something
longer after my vacations and put it somewhere online.
Before 2011 there were quite a few issues within FFmpeg. Most of those
revolved around Michael Niedermayer playing by his own set of rules
and ignoring the advise of everyone else. His behaviour has resulted
in quite a bit of ... anger.. to put it mildly. A few people left because
of him. Heck, even i wanted to leave everything that was related to
FFmpeg in any way, even though all i did was keeping the server running
and was not involved in the development or anything else at all.

Its a long time ago, but IIRC when i asked about what rules it was
that where broken back then it was a mix of silence and someone who
admited he mixed the rules of FFmpeg up with another project.

Also ive offered my resignation in the past.
I do still offer to resign from the FFmpeg leader position, if it
resolves this split between FFmpeg and Libav and make everyone work
together again. I never understood why people who once where friends
became mutually so hostile

The part i insist on though is that everyone must be able to work
on their code without people uninvolved in that specific parts
maintaince or authorship being able to block their work.

[...]

[Kieran Kunhya]

Post by Michael Niedermayer
Also ive offered my resignation in the past.
I do still offer to resign from the FFmpeg leader position, if it
resolves this split between FFmpeg and Libav and make everyone work
together again. I never understood why people who once where friends
became mutually so hostile

The big elephant in the room in any discussion about even moving an
iota in the direction of something resembling a resolution is that you
as FFmpeg leader are a hidden leader. Every year at VDD when there is
any informal discussion of any reconciliation as Attila alludes to the
line "we can't get anywhere since Michael isn't here" is uttered and
then everyone moves on.

Things have changed a lot in the 3.5 years since the split but since
you never show your face and because many libav people don't follow
FFmpeg they just imagine conditions to be the same and remember the
same anger that caused all this. Yes there is a lot of anger around
still but meeting in person dampens things.

Lets be honest, Google is definitely FFmpeg home turf, at previous
VDDs there were plenty of FFmpeg people and J-b has offered to pay
your travel/accommodation etc for many years - there is literally
nothing more that they could do beyond hosting a conference at your
home. Every year however, it's always silence when talking about this
to you. I appreciate you may not want to meet people face to face but
if you are seriously interested in moving in the right direction this
is the *ONLY* way forward and I cannot stress this more. I suspect you
won't hear it publicly but it's fair to say that this view is
unanimous on both sides of the fence - if you're physically not there
nothing will change and we'll all have to waste stupid amounts of time
dealing with the current state.

Whatever, people can work on their own code happily but the rest of
the world (cf this thread) has to deal with this annoying FFmpeg/libav
madness. Getting it into Debian isn't going to change much (I get the
feeling some FFmpeg people expect it to be a massive game-changer of
some sort).

(of course this is going to get me lots of angry private messages and
emails like the last set of emails)

[Thomas Weber]

Post by Kieran Kunhya

Post by Michael Niedermayer
Also ive offered my resignation in the past.
I do still offer to resign from the FFmpeg leader position, if it
resolves this split between FFmpeg and Libav and make everyone work
together again. I never understood why people who once where friends
became mutually so hostile

The big elephant in the room in any discussion about even moving an
iota in the direction of something resembling a resolution is that you
as FFmpeg leader are a hidden leader. Every year at VDD when there is
any informal discussion of any reconciliation as Attila alludes to the
line "we can't get anywhere since Michael isn't here" is uttered and
then everyone moves on.

Guys,
this is getting nowhere. You need to solve this in a non-public
discussion.
Given the amount of noise this has generated on debian-devel, I am sure
some of the Debian oldtimers[1] will be happy[2] to act as mediators for
such a discussion if it is organized in a somewhat convenient
location/conference/etc and if both sides consider such a mediation
helpful.

[1] With or without previous contacts with ffmpeg/libav.
[2] Think of it like "spending some hours to fix the issue" vs "spending
some hours to read more mails on debian-devel".

Thomas

[Thomas Goirand]

Post by Kieran Kunhya
Whatever, people can work on their own code happily but the rest of
the world (cf this thread) has to deal with this annoying FFmpeg/libav
madness.

Right! Not only a core of a few upstream authors are affected, but also
downstream distributions (where we have to deal with numerous build
issues), and final users (who may loose the possibility to use some nice
software...). If you guys could find a solution to try to work together
again, and merge back both projects, that'd be best for everyone.

Post by Kieran Kunhya
Also ive offered my resignation in the past.
I do still offer to resign from the FFmpeg leader position, if it
resolves this split between FFmpeg and Libav and make everyone work
together again.

Why not just take the offer, and move on?

Thomas Goirand (zigo)

[The Wanderer]

Post by Thomas Goirand

Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader position, if it resolves this split
between FFmpeg and Libav and make everyone work together again.

Why not just take the offer, and move on?

Probably because of the condition he attached to it, which also dates

Post by Thomas Goirand

The part i insist on though is that everyone must be able to work
on their code without people uninvolved in that specific parts
maintaince or authorship being able to block their work.

In other words, as I think I understand it from the discussion back
then: people not involved with a particular area of the code can't NACK
the work of someone who is working on it, and someone who works on a
particular area of the code doesn't have to wait on review of people who
aren't involved with that area of the code.

Since one of the motivations of the people behind the libav side of the
split seems, IIRC, to have been "no code gets in without having been
reviewed by someone other than the author", this was apparently deemed
an unacceptable condition.

- --
The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.

[Thomas Goirand]

Post by The Wanderer

Post by Thomas Goirand

Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader position, if it resolves this split
between FFmpeg and Libav and make everyone work together again.

Why not just take the offer, and move on?

Probably because of the condition he attached to it, which also dates

Post by Thomas Goirand

The part i insist on though is that everyone must be able to work
on their code without people uninvolved in that specific parts
maintaince or authorship being able to block their work.

In other words, as I think I understand it from the discussion back
then: people not involved with a particular area of the code can't NACK
the work of someone who is working on it, and someone who works on a
particular area of the code doesn't have to wait on review of people who
aren't involved with that area of the code.
Since one of the motivations of the people behind the libav side of the
split seems, IIRC, to have been "no code gets in without having been
reviewed by someone other than the author", this was apparently deemed
an unacceptable condition.

Hum... Well, to me, what's important is that the code gets
peer-reviewed. Setting-up something like gerrit may help, as it can be
setup in a way that review becomes mandatory. Then discussing who's
core-reviewer and can approve this or that part of the code can be setup
within gerrit. This should be discussed, and setup based on technical merit.

Having a NACK review is often disappointing. It goes the wrong way if
there's only a NACK with no comments on how to improve things, so that
the code becomes acceptable. Absolutely everyone should *always* be able
to leave comments, be it positive or negative. With Gerrit, it's
possible to comment directly in the patch, which helps going in the
right direction.

Of course, a technical solution will not solve all social issues, but it
may improve the workflow and process, and avoid frictions.

I hope this helps,
Cheers,

Thomas Goirand (zigo)

[Paul Wise]

Post by Thomas Goirand
Hum... Well, to me, what's important is that the code gets
peer-reviewed.

... by both humans and by automatically by computers; compiler
warnings, static analysis tools, fuzz testers etc.

[Michael Niedermayer]

Post by Thomas Goirand

Post by The Wanderer

Post by Thomas Goirand

Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader position, if it resolves this split
between FFmpeg and Libav and make everyone work together again.

Why not just take the offer, and move on?

Probably because of the condition he attached to it, which also dates

Post by Thomas Goirand

The part i insist on though is that everyone must be able to work
on their code without people uninvolved in that specific parts
maintaince or authorship being able to block their work.

In other words, as I think I understand it from the discussion back
then: people not involved with a particular area of the code can't NACK
the work of someone who is working on it, and someone who works on a
particular area of the code doesn't have to wait on review of people who
aren't involved with that area of the code.
Since one of the motivations of the people behind the libav side of the
split seems, IIRC, to have been "no code gets in without having been
reviewed by someone other than the author", this was apparently deemed
an unacceptable condition.

Hum... Well, to me, what's important is that the code gets
peer-reviewed.

Yes, the tricky part in FFmpeg and Libav in relation to this is that
theres quite a bit of code that is only well understood by a single
person even if you would combine both projects together.
So if that person posts a patch for review, theres noone who could
do a real review

Post by Thomas Goirand
Setting-up something like gerrit may help, as it can be
setup in a way that review becomes mandatory. Then discussing who's
core-reviewer and can approve this or that part of the code can be setup
within gerrit. This should be discussed, and setup based on technical merit.

Not commenting about gerrit as i dont have experience with it, but
FFmpeg currently uses a simple file in main ffmpeg git that lists
which part is maintained by whom, and these developers would in the
rare case of a dispute have the final say in each area.

OTOH, Libav early deleted their forked version of this file, and
iam not aware of any replacement. But others should explain how it
works in Libav ...

Post by Thomas Goirand
Having a NACK review is often disappointing. It goes the wrong way if
there's only a NACK with no comments on how to improve things, so that
the code becomes acceptable.
Absolutely everyone should *always* be able
to leave comments, be it positive or negative.

yes, i fully agree and this also was always so in FFmpeg. In that
sense everyone is welcome to subscribe to ffmpeg-devel and review and
comment patches. That of course includes Libav developers and everyone
else. And more reviewers would also certainly help, so yeah anyone
reading this and wanting to help review patches, you are welcome!

Thanks

[...]

[Thomas Goirand]

Post by Michael Niedermayer
Yes, the tricky part in FFmpeg and Libav in relation to this is that
theres quite a bit of code that is only well understood by a single
person even if you would combine both projects together.

Hum... Hang on here then! Does this mean that, in FFmpeg and/or Libav,
there's some parts of the code which are understood by no-one? Scary!

Post by Michael Niedermayer
So if that person posts a patch for review, theres noone who could
do a real review

Then the person who posts the patch can leave it for review for a while
(you should define a policy so that "for a while" means something: for
example 2 or 3 weeks), and then if there's no negative review, he can
self-approve his patch.

Post by Michael Niedermayer

Post by Thomas Goirand
Absolutely everyone should *always* be able
to leave comments, be it positive or negative.

yes, i fully agree and this also was always so in FFmpeg. In that
sense everyone is welcome to subscribe to ffmpeg-devel and review and
comment patches. That of course includes Libav developers and everyone
else. And more reviewers would also certainly help, so yeah anyone
reading this and wanting to help review patches, you are welcome!

Well, using a mailing list to review patches is something we were doing
10 years ago. You should really consider using Gerrit (or something
equivalent, but I don't know anything that works the way Gerrit does).
The workflow will influence a lot the way contributors interact with
each other. Almost certainly in a *good* way.

Cheers,

Thomas Goirand (zigo)

[The Wanderer]

Post by Thomas Goirand

Post by Michael Niedermayer

Absolutely everyone should *always* be able to leave comments, be
it positive or negative.

yes, i fully agree and this also was always so in FFmpeg. In that
sense everyone is welcome to subscribe to ffmpeg-devel and review
and comment patches. That of course includes Libav developers and
everyone else. And more reviewers would also certainly help, so
yeah anyone reading this and wanting to help review patches, you
are welcome!

Well, using a mailing list to review patches is something we were
doing 10 years ago.

It's also something the Linux kernel is still doing, with apparent
success.

I for one consider it to be a much more public, transparent, and
discoverable way to let proposed patches and the review of same be open
to public view, compared to the way various other projects seem to do
it.

Making sure everything passes through the mailing list, and most if not
all substantive discussion happens on the mailing list, is a lot better
than having some discussion on the mailing lists and some on a bug
tracker and some on IRC and some via private mail and so on. (The most
ridiculously extreme example of this fragmentation that I know of is
probably the Mozilla project.)

There's nothing wrong with having discussion in those various areas, of
course; it's probably inevitable, and it's even a good thing. It's just
that it's a lot harder for someone not intimately involved with the
project to follow discussion if it happens in such a variety of places,
and there's value to be found in making sure that everything passes
through one central (discussion-enabled) point before landing.

- --
The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.

[Thomas Goirand]

Post by The Wanderer
It's also something the Linux kernel is still doing, with apparent
success.

Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using git-review and gerrit is so much better.

Post by The Wanderer
I for one consider it to be a much more public, transparent, and
discoverable way to let proposed patches and the review of same be open
to public view, compared to the way various other projects seem to do
it.
Making sure everything passes through the mailing list, and most if not
all substantive discussion happens on the mailing list, is a lot better
than having some discussion on the mailing lists and some on a bug
tracker and some on IRC and some via private mail and so on. (The most
ridiculously extreme example of this fragmentation that I know of is
probably the Mozilla project.)

This reasoning may work when you have only a small amount of information
to read. When you are overwhelmed with it, having different places to do
different things is a much better approach. Sending patches to a list
simply doesn't scale.

Also, with a list, it's not convenient at all to point out a line in a
patch in a mailing list. You must extract the relevant lines, cut/past
them, and comment them. Instead, double clicking on the line of the
patch which is displayed on a web interface is much more convenient.

Post by The Wanderer
There's nothing wrong with having discussion in those various areas, of
course; it's probably inevitable, and it's even a good thing. It's just
that it's a lot harder for someone not intimately involved with the
project to follow discussion if it happens in such a variety of places,
and there's value to be found in making sure that everything passes
through one central (discussion-enabled) point before landing.

Lists are good tools for discussing where a project should go, release
goals, and so on. They aren't good tools to do patch reviews. I've used
both, and I'm convinced of that.

Thomas Goirand (zigo)

[wm4]

On Sat, 16 Aug 2014 23:29:56 +0800

Post by Thomas Goirand

Post by The Wanderer
It's also something the Linux kernel is still doing, with apparent
success.

Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using git-review and gerrit is so much better.

Post by The Wanderer
I for one consider it to be a much more public, transparent, and
discoverable way to let proposed patches and the review of same be open
to public view, compared to the way various other projects seem to do
it.
Making sure everything passes through the mailing list, and most if not
all substantive discussion happens on the mailing list, is a lot better
than having some discussion on the mailing lists and some on a bug
tracker and some on IRC and some via private mail and so on. (The most
ridiculously extreme example of this fragmentation that I know of is
probably the Mozilla project.)

This reasoning may work when you have only a small amount of information
to read. When you are overwhelmed with it, having different places to do
different things is a much better approach. Sending patches to a list
simply doesn't scale.
Also, with a list, it's not convenient at all to point out a line in a
patch in a mailing list. You must extract the relevant lines, cut/past
them, and comment them. Instead, double clicking on the line of the
patch which is displayed on a web interface is much more convenient.

What? Most patches are posted inline (with git-send-email).

Post by Thomas Goirand

Post by The Wanderer
There's nothing wrong with having discussion in those various areas, of
course; it's probably inevitable, and it's even a good thing. It's just
that it's a lot harder for someone not intimately involved with the
project to follow discussion if it happens in such a variety of places,
and there's value to be found in making sure that everything passes
through one central (discussion-enabled) point before landing.

Lists are good tools for discussing where a project should go, release
goals, and so on. They aren't good tools to do patch reviews. I've used
both, and I'm convinced of that.

What we need is solving the FFmpeg/Libav split, not "well-meant"
suggestions by outsiders how to change our development model.

Post by Thomas Goirand
Thomas Goirand (zigo)
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[Thomas Goirand]

Post by wm4

Post by Thomas Goirand
This reasoning may work when you have only a small amount of information
to read. When you are overwhelmed with it, having different places to do
different things is a much better approach. Sending patches to a list
simply doesn't scale.
Also, with a list, it's not convenient at all to point out a line in a
patch in a mailing list. You must extract the relevant lines, cut/past
them, and comment them. Instead, double clicking on the line of the
patch which is displayed on a web interface is much more convenient.

What? Most patches are posted inline (with git-send-email).

Even worse then! It makes it hard to copy to your local fs.

Anyway, have a look here, if you want to see how the review process works:
https://review.openstack.org/

click on any patch proposal, and see how nice the interaction is (see
patch comments, the result of jenkins unit tests, etc.). This helps a
lot with QA, for sure.

Post by wm4

Post by Thomas Goirand

Post by The Wanderer
There's nothing wrong with having discussion in those various areas, of
course; it's probably inevitable, and it's even a good thing. It's just
that it's a lot harder for someone not intimately involved with the
project to follow discussion if it happens in such a variety of places,
and there's value to be found in making sure that everything passes
through one central (discussion-enabled) point before landing.

Lists are good tools for discussing where a project should go, release
goals, and so on. They aren't good tools to do patch reviews. I've used
both, and I'm convinced of that.

What we need is solving the FFmpeg/Libav split, not "well-meant"
suggestions by outsiders how to change our development model.

The problem, as much as I understand it, was the review process and
enforcing policies. So it's natural to give advice on that, with a tool
which will make sure that policies are enforced. If you don't want
advices, and want to have a private discussion, then why writing to
debian-***@l.d.o?

Thomas

[Thorsten Glaser]

Post by Thomas Goirand
Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using git-review and gerrit is so much better.

Strong NAK here.

First: it breaks the medium used (eMail vs. web).

Second: Gerrit is an accessibility nightmare, not just for
people using Lynx, but also for those who do have
the required webbloatser at hand… and it recently
got even worse.

Having less points where information is exchanged is Good™.

bye,
//mirabilos, speaking from contributor experience in many projects

[Ondřej Surý]

Post by Thomas Goirand

Post by The Wanderer
It's also something the Linux kernel is still doing, with apparent
success.

Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using git-review and gerrit is so much better.

JFTR we have dropped gerrit in favour of gitlab (or github or bitbucket)
pull requests since gerrit was too cumbersome to use.

So, no, gerrit is no miraculous cure-all.

However I think that establishing a procedure that every patch has to
be submitted as a pull request and this pull request needs to be acked
by other developer is a good practice that can be adapted to any project
(the only exception being one-man shows).

Ondrej

[Bálint Réczey]

Hi,

Post by Michael Niedermayer

Post by Thomas Goirand

Post by The Wanderer

Post by Thomas Goirand

Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader position, if it resolves this split
between FFmpeg and Libav and make everyone work together again.

Why not just take the offer, and move on?

Probably because of the condition he attached to it, which also dates

Post by Thomas Goirand

The part i insist on though is that everyone must be able to work
on their code without people uninvolved in that specific parts
maintaince or authorship being able to block their work.

In other words, as I think I understand it from the discussion back
then: people not involved with a particular area of the code can't NACK
the work of someone who is working on it, and someone who works on a
particular area of the code doesn't have to wait on review of people who
aren't involved with that area of the code.
Since one of the motivations of the people behind the libav side of the
split seems, IIRC, to have been "no code gets in without having been
reviewed by someone other than the author", this was apparently deemed
an unacceptable condition.

Hum... Well, to me, what's important is that the code gets
peer-reviewed.

Yes, the tricky part in FFmpeg and Libav in relation to this is that
theres quite a bit of code that is only well understood by a single
person even if you would combine both projects together.
So if that person posts a patch for review, theres noone who could
do a real review

This situation is not totally unique to FFmpeg/Libav. IMO in this
real-life situation peers can do a best-effort review and people doing
so would sooner or later will get familiar with those parts of the
code as well.
In case of a widely used library like this the biggest issue is
breaking the ABI or modifying the ABI in a way which does not align
with the team's vision about the ABI roadmap. That type of change can
be pointed out by less experienced developers, too.
Internal regressions in the code can be easily fixed even if they are
not discovered during testing and enter the release.

Post by Michael Niedermayer

Post by Thomas Goirand
Setting-up something like gerrit may help, as it can be
setup in a way that review becomes mandatory. Then discussing who's
core-reviewer and can approve this or that part of the code can be setup
within gerrit. This should be discussed, and setup based on technical merit.

Not commenting about gerrit as i dont have experience with it, but
FFmpeg currently uses a simple file in main ffmpeg git that lists
which part is maintained by whom, and these developers would in the
rare case of a dispute have the final say in each area.

Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to Gerrit at the
Wireshark project and it helps a lot in coordinating the reviews.

Cheers,
Balint

Post by Michael Niedermayer
OTOH, Libav early deleted their forked version of this file, and
iam not aware of any replacement. But others should explain how it
works in Libav ...

Post by Thomas Goirand
Having a NACK review is often disappointing. It goes the wrong way if
there's only a NACK with no comments on how to improve things, so that
the code becomes acceptable.
Absolutely everyone should *always* be able
to leave comments, be it positive or negative.

yes, i fully agree and this also was always so in FFmpeg. In that
sense everyone is welcome to subscribe to ffmpeg-devel and review and
comment patches. That of course includes Libav developers and everyone
else. And more reviewers would also certainly help, so yeah anyone
reading this and wanting to help review patches, you are welcome!
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

[Nicolas George]

Post by Bálint Réczey
Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to Gerrit at the
Wireshark project and it helps a lot in coordinating the reviews.

I am afraid this discussion on "Gerrit" or other similar tools is pointless:
this is trying to solve a human problem with technical means: it never
works.

Actually, I believe all this peer-review business to be a red herring. On
the FFmpeg side, most patches except the very simple ones are sent to the
mailing-list for peer-review, even patches by people with commit rights
working on their own code; they do so not because a rule states they have
too but because this is the best thing to achieve good code. On the other
hand, I remember having seen patches somewhat rushed through the mandatory
review on libav-devel and applied when someone else still had remarks; I
have not kept tabs on that though.

The real issue between the mandatory peer-review on the mailing-list is,
IMHO, control of the project orientation. Not "is this patch correct?" but
"do we want this patch?".

If you are involved in the project, it is very obvious that both branches
have rather opposed views on the project orientation: libav has made a point
of trimming "unnecessary" features and rejecting new ones while FFmpeg kept
them and added some.

A few examples:

* Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
message said "appears simpler to write a new replacement from scratch",
but in the meantime, users are left without the feature.

* Libav removed the framerate detection code, FFmpeg built on it to handle
it in filtering too. I do not find them right now, but I have found a few
files that avconv wanted to encode at an insane frame rate while ffmpeg
correctly guessed; and right now, -vf fps does not work alone with very
common formats in avconv.

* Libav removed the keyboard interaction ("Press [q] to stop") while FFmpeg
extended it.

Beyond these obvious cases, FFmpeg has gained quite a few features that, I
am pretty certain of it, would not have been accepted into libav: the concat
demuxer (has been called "hack" on the mailing-lists IIRC), the lavfi
sources made for testing, support for some obscure format through an
external library, subtitles hard-burning, etc.

The most galling in this issue is that there is no clear decision behind
this orientation. The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the commit rights are few and of a common mind, they can just give the cold
shoulder to proposed changes that do not suit their personal view of the
project.

Considering these differences in policy, I do not believe the fork can be
merged. Speaking as someone who proposed a few of these "unnecessary"
features, because they were fun or immediately useful, I would not like to
work on a project that would reject them by principle. But I can recognize,
for someone who needs "serious professional" software, the need of working
on something driven with a firmer hand.


Having a fork is not inherently bad, and it becomes necessary when people
have different views for the orientation of the projects.

It becomes bad when people not involved in the project start to suffer from
the consequences of the fork. This is what is happening here, for two
reasons:

* distributions adopting one side of the fork for non-technical reasons;

* one side of the fork not caring about compatibility with the other side.

Of course, these reasons are interconnected.

Regards,

[Bálint Réczey]

Hi Nicolas,

Post by Nicolas George

Post by Bálint Réczey
Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to Gerrit at the
Wireshark project and it helps a lot in coordinating the reviews.

this is trying to solve a human problem with technical means: it never
works.

I did not want to sell Gerrit over mailing-list discussion because the
work-flow is something which should be chosen by the development team
and not outsiders, but wanted to show that tools can help enforcing
some parts of the work-flow.

On the human problems vs. technical means questions I think we have
different opinions. Technical means are exceptionally great tools for
solving _some_ human problems. If the human problem is being not
satisfied with peers' behavior of not following a specific work-flow a
toll which enforces the work-flow would solve it. Making mistakes is
an other (mostly) human problem and we have lintian for example which
helps pointing them out.

Post by Nicolas George
Actually, I believe all this peer-review business to be a red herring. On
the FFmpeg side, most patches except the very simple ones are sent to the
mailing-list for peer-review, even patches by people with commit rights
working on their own code; they do so not because a rule states they have
too but because this is the best thing to achieve good code. On the other
hand, I remember having seen patches somewhat rushed through the mandatory
review on libav-devel and applied when someone else still had remarks; I
have not kept tabs on that though.
The real issue between the mandatory peer-review on the mailing-list is,
IMHO, control of the project orientation. Not "is this patch correct?" but
"do we want this patch?".
If you are involved in the project, it is very obvious that both branches
have rather opposed views on the project orientation: libav has made a point
of trimming "unnecessary" features and rejecting new ones while FFmpeg kept
them and added some.

IMO the trimming/rejecting strategy is not something which would ever
make Libav popular among developers/users and this is how we ended in
the current situation. While Libav's communicated release strategy can
attract integrators and distributions like Debian, FFmpeg attracts
developers/users of software based on Libav/FFmpeg due to more
features.
Sticking to those core strategies the two forks will compete forever
until one of them give up - which I see unlikely to happen voluntarily
- and users will keep complaining about Libav's missing features to
distributions' maintainers where FFmpeg is not packaged.

I think the best way out of this situation would be relaxing the
review requirements on Libav's side and letting not-yet-proven of
FFmpeg features in through an experimental/staging phase. If FFmpeg
devs could collaborate with them this way the two forks could be
converged and finally merged and the combined team could maintain a
lot better media library than the current forks are separately.

Cheers,
Balint

Post by Nicolas George
* Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
message said "appears simpler to write a new replacement from scratch",
but in the meantime, users are left without the feature.
* Libav removed the framerate detection code, FFmpeg built on it to handle
it in filtering too. I do not find them right now, but I have found a few
files that avconv wanted to encode at an insane frame rate while ffmpeg
correctly guessed; and right now, -vf fps does not work alone with very
common formats in avconv.
* Libav removed the keyboard interaction ("Press [q] to stop") while FFmpeg
extended it.
Beyond these obvious cases, FFmpeg has gained quite a few features that, I
am pretty certain of it, would not have been accepted into libav: the concat
demuxer (has been called "hack" on the mailing-lists IIRC), the lavfi
sources made for testing, support for some obscure format through an
external library, subtitles hard-burning, etc.
The most galling in this issue is that there is no clear decision behind
this orientation. The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the commit rights are few and of a common mind, they can just give the cold
shoulder to proposed changes that do not suit their personal view of the
project.
Considering these differences in policy, I do not believe the fork can be
merged. Speaking as someone who proposed a few of these "unnecessary"
features, because they were fun or immediately useful, I would not like to
work on a project that would reject them by principle. But I can recognize,
for someone who needs "serious professional" software, the need of working
on something driven with a firmer hand.
Having a fork is not inherently bad, and it becomes necessary when people
have different views for the orientation of the projects.
It becomes bad when people not involved in the project start to suffer from
the consequences of the fork. This is what is happening here, for two
* distributions adopting one side of the fork for non-technical reasons;
* one side of the fork not caring about compatibility with the other side.
Of course, these reasons are interconnected.
Regards,
--
Nicolas George

[Thomas Goirand]

Post by Nicolas George

Post by Bálint Réczey
Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to Gerrit at the
Wireshark project and it helps a lot in coordinating the reviews.

this is trying to solve a human problem with technical means: it never
works.

The problem was enforcing patch review policies. This technical solution
makes it possible to enforce rules. Sure, it doesn't fix the social
issue completely, but at least if you implement it, it's going to be a
way more difficult to bypass the review system, and the one who does
will really look bad, so it's very unlikely it will happen.

Post by Nicolas George
[...] The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the commit rights are few [...]

Really, when I read "commit rights", in a collaborative process, I feel
like there's something wrong.

Post by Nicolas George
It becomes bad when people not involved in the project start to suffer from
the consequences of the fork. This is what is happening here, for two
* distributions adopting one side of the fork for non-technical reasons;

There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once. Now, the "which
side" debate is a different one, which I don't think Debian people are
interested in (at least, *I* am not): we are just suffering from the
consequences of the fork, as you wrote, and would prefer it never happened.

Post by Nicolas George
* one side of the fork not caring about compatibility with the other side.
Of course, these reasons are interconnected.

Yeah. If both were fully compatible, there would be no issue using one
or the other.

Thomas

[Andreas Cadhalpun]

Hi Thomas,

Post by Thomas Goirand
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once.

Why is it a security problem to have FFmpeg and Libav, but apparently no
problem to have MySQL, MariaDB and PerconaDB?

This seems quite arbitrary to me, especially since there have been
already 36 CVEs in 2014 for MySQL [1], of which 26 apparently are also
relevant for MariaDB [2] and PerconaDB [3], but only 7 for FFmpeg [4]
and 8 for Libav [5] in the same time.

Best regards,
Andreas


1: https://security-tracker.debian.org/tracker/source-package/mysql-5.5
2: https://security-tracker.debian.org/tracker/source-package/mariadb-5.5
3:
https://security-tracker.debian.org/tracker/source-package/percona-xtradb-cluster-5.5
4: https://security-tracker.debian.org/tracker/source-package/ffmpeg
5: https://security-tracker.debian.org/tracker/source-package/libav

[Moritz Mühlenhoff]

Post by Andreas Cadhalpun
Hi Thomas,

Post by Thomas Goirand
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once.

Why is it a security problem to have FFmpeg and Libav, but apparently no
problem to have MySQL, MariaDB and PerconaDB?

Raphael Geissert already wrote that mysql/mariadb/percona will be
addressed as well; we haven't come around to since since we need to
deal with a lot of stuf and being dragged into endless discussions
on -devel is certainly not helpful.

Cheers,
Moritz

[Andreas Cadhalpun]

Hi Moritz,

Post by Moritz Mühlenhoff

Post by Andreas Cadhalpun

Post by Thomas Goirand
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once.

Why is it a security problem to have FFmpeg and Libav, but apparently no
problem to have MySQL, MariaDB and PerconaDB?

Raphael Geissert already wrote that mysql/mariadb/percona will be
addressed as well; we haven't come around to since since we need to
deal with a lot of stuf and being dragged into endless discussions
on -devel is certainly not helpful.

I don't remember Raphael Geissert writing anything about security
concerns with having MySQL, MariaDB and PerconaDB, only that you wrote
half a year ago, that the security team will "be working with the
release team to sort this out for jessie" [1].

As I haven't seen any further discussion about this and the recent mail
about MySQL, MariaDB and PerconaDB on debian-devel [2] indicated that
the plan was to have all of them as alternatives, I assumed this was
resolved.

There wouldn't be any discussion about the security of FFmpeg and Libav
as well, if you hadn't started it [3].

Why is FFmpeg treated differently than MariaDB/PerconaDB?

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#435
2: https://lists.debian.org/debian-devel/2014/08/msg00016.html
3: https://lists.debian.org/debian-devel/2014/02/msg00668.html

[Jean-Yves Avenard]

On 18 August 2014 23:15, Andreas Cadhalpun

Post by Andreas Cadhalpun
Why is FFmpeg treated differently than MariaDB/PerconaDB?

That's a very good question really.

But reading some of the comments in regards to having a nay for
including project that duplicate code, my guess is that it's a totally
irrational decision ; and one that has very little technical basis at
that.

Also gotta love when the security breach are actually unique to Debian
because some package maintainer has decided he knew better and happily
broke things. SSL anyone?

[Ivan Kalvachev]

Post by Moritz Mühlenhoff

Post by Andreas Cadhalpun
Hi Thomas,

Post by Thomas Goirand
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once.

Why is it a security problem to have FFmpeg and Libav, but apparently no
problem to have MySQL, MariaDB and PerconaDB?

Raphael Geissert already wrote that mysql/mariadb/percona will be
addressed as well; we haven't come around to since since we need to
deal with a lot of stuf and being dragged into endless discussions
on -devel is certainly not helpful.
Cheers,
Moritz

Excuse my interruption, but I intend to be a little blunt.

I think there might be a little bit of miscommunication.

You have said that security team cannot handle both FFmpeg and Libav.
Since Libav is already in Debian, this statement is assumed to mean
that you do not want to deal with FFmpeg. However this mail
http://lists.debian.org/debian-devel/2014/08/msg00060.html kind of
hints the opposite - Libav security handling is horrible and burden to
you, while FFmpeg so far is responsive and responsible.

So I would like to get a little bit more details on your priorities
and preferences. The options I could think of are:
1. Drop both Libav and FFmpeg.
2. Leave Libav in stable, keep FFmpeg out.
3. Get FFmpeg in stable, drop Libav.
4. Get both Libav and FFmpeg, under the condition that Michael is
helping with FFmpeg patching.
5. Get both Libav and FFmpeg, under the condition that Michael is
helping with FFmpeg AND Libav patching (only for jessie).
6. Something else...

Other people have said that FFmpeg should provide help and resources
to the security team. Please elaborate what more can FFmpeg do to
please you.

Best Regards
Ivan Kalvachev
iive


P.S.
I hope ftp masters are not deliberately prolonging the FFmpeg
inclusion, thinking they are doing favor to their peers from other
teams.

[Nicolas George]

Post by Thomas Goirand
The problem was enforcing patch review policies.

No, it never was.

Post by Thomas Goirand
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things

That the reason for keeping only one; other have discussed the validity of
the reason.

The reason for switching from FFmpeg to libav in the first place just after
the fork is much simpler than that.

Post by Thomas Goirand
Yeah. If both were fully compatible, there would be no issue using one
or the other.

Are there known current cases where FFmpeg can not emulate libav?

Regards,

[Attila Kinali]

On Mon, 18 Aug 2014 13:42:36 +0200

Post by Nicolas George
The reason for switching from FFmpeg to libav in the first place just after
the fork is much simpler than that.

Yes, the reason was that Reinhard, who was the maintainer of the
ffmpeg package back then, was on the libav side after the split.

BTW: for those who do not know. Michael raised the issue of
the ffmpeg -> libav switch at ubuntu back then [1]. The technical board
decided to go with the decision of the package maintainer [2,3,4].
I think most people will find [3] the most interesting, as it explains
why Reinhard thought (and still thinks) that libav was the better choice.


Attila Kinali


[1] https://lists.ubuntu.com/archives/technical-board/2011-April/000794.html
[2] http://irclogs.ubuntu.com/2011/05/19/%23ubuntu-meeting.html#t19:10
[3] https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html
[4] http://irclogs.ubuntu.com/2011/06/02/%23ubuntu-meeting.html#t19:01

[Attila Kinali]

On Sat, 16 Aug 2014 17:11:29 +0200

Post by Nicolas George
The most galling in this issue is that there is no clear decision behind
this orientation. The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the commit rights are few and of a common mind, they can just give the cold
shoulder to proposed changes that do not suit their personal view of the
project.

Err... If i counted correctly, there are currently 21 people who have
commit rights to the libav repo. If you call that "few" i would like
to know what you would consider as "many"? Also, i can asure you,
that they are not of one mind. There are many fights on how to do things
and whether a patch should go in or not. Heck, they are visible even
to someone like me, who sits at the sidelines (i'm not a developer
and have not written one line of code for libav. i dont even read
the mailinglists).

Post by Nicolas George
Considering these differences in policy, I do not believe the fork can be
merged. Speaking as someone who proposed a few of these "unnecessary"
features, because they were fun or immediately useful, I would not like to
work on a project that would reject them by principle.

"Though a program be but three lines long,
someday it will have to be maintained."
-- The Tao of Programming


Attila Kinali

[Nicolas George]

Post by Thomas Goirand
If you guys could find a solution to try to work together
again, and merge back both projects, that'd be best for everyone.

When people suggest that, I always wonder how they see that happening with
regard to the code.

In more than three years since the fork, development has continued on both
branches. Changes are continuously ported from libav to FFmpeg, but code was
also written for FFmpeg and never merged by libav. Some of this code, the
libav people have made very clear they specifically did not want it.

So what about the code? Shall the FFmpeg developers discard three years of
work and start working on libav? Or shall the libav developers accept to
work with the code from FFmpeg that they do not like?

I see neither as an option.

The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.

Regards,

[Pau Garcia i Quiles]

Post by Nicolas George
The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.

Can we get back on topic?

With or without libav in Debian, there are solid technical reasons to have
ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although
they parted ways in a civilized way: different library names), and we
certainly have a ton of librarys which provide very similar features.

Since before the fork, the libav developers have been sabotaging ffmpeg as
much as possible, in every "combat field": library names, library versions,
taking distributions hostage (ffmpeg package that installs libav!?), etc.
This is not the way to fork anything. This is a fact. I don't care whether
Michael Nidermayer was a dictator or not. I don't care whether the
code-review rules in libav are better or worse. I don't care what the Linux
kernel does. The only thing I care about is Debian is shipping a
less-capable (i. e. less multimedia formats supported) distribution due to
this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will most
certainly cause binary problems.

If libav and ffmpeg maintainers cannot reach an agreement regarding library
names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian. E.
g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done
in the past.

And before someone mentions it: I don't think it's too late. It's getting
too late because nobody with the right to act is doing anything. In the
end, our users are the ones being harmed and we are left wondering why they
are increasingly moving to other distributions or Mac OS X.

[Ivan Kalvachev]

Post by Pau Garcia i Quiles

Post by Nicolas George
The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.

Can we get back on topic?
With or without libav in Debian, there are solid technical reasons to have
ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although
they parted ways in a civilized way: different library names), and we
certainly have a ton of librarys which provide very similar features.
Since before the fork, the libav developers have been sabotaging ffmpeg as
much as possible, in every "combat field": library names, library versions,
taking distributions hostage (ffmpeg package that installs libav!?), etc.
This is not the way to fork anything. This is a fact. I don't care whether
Michael Nidermayer was a dictator or not. I don't care whether the
code-review rules in libav are better or worse. I don't care what the Linux
kernel does. The only thing I care about is Debian is shipping a
less-capable (i. e. less multimedia formats supported) distribution due to
this conflict.
This has to stop.
ffmpeg is not yet in Debian due to the filename clashing, which will most
certainly cause binary problems.
If libav and ffmpeg maintainers cannot reach an agreement regarding library
names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian. E.
g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done
in the past.

AFAIK, Andreas' package uses libavcodec-ffmpeg.so .

FFmpeg configure does have option --build-suffix="_ffmpeg" that would
append that suffix to library names and pkg-config files. Since
applications might have problem finding the ffmpeg libraries, the
pkg-config files should be with the old "common" names and this
creates a conflict in the -dev packages.

Libav and FFmpeg can coexist side by side.
There are no conflicts or overlap for binary users.


The current goal of FFmpeg is not replacing Libav.
The current goal is establishing a native presence in the most popular
distribution(s).


I'm quite sure the Security team is full of capable people who can
handle one more package.
FFmpeg takes security seriously.


The best scenario for everybody is:
1. Libav stays and all QA tested programs are not touched.
2. FFmpeg is included in a way that does not obstruct the rest of the ecosystem.
3. Optionally, programs that use _only_ FFmpeg could be included back
in Debian. Optionally.

The inclusion would allow for a real-life estimate to be done of the
FFmpeg performance, security, bug and feature wise.

Only after assessing real-life data, a final decision could be
reached, if there is still demand for such thing.

Best Regards
Ivan Kalvachev

[Russ Allbery]

Post by Ivan Kalvachev
I'm quite sure the Security team is full of capable people who can
handle one more package.

One, no, this statement is not correct. Not because the security team is
not capable -- they are very capable -- but because they are not *full*.
You imply that the security team has tons of resources and time to spare.
Let me assure you that this is far from the case. This isn't even the
case for security teams consisting of full-time staff paid by commercial
Linux distributions, let alone volunteers for the Debian project.

Two, the security team has already said that FFmpeg is not just "one more
package," and that no, they can't handle the substantial incremental load
from adding FFmpeg without removing libav. You may not think that should
be the case, but I'm afraid your opinion on the topic doesn't matter
unless you're finding a way to either reduce that work or add more
resources.

Post by Ivan Kalvachev
FFmpeg takes security seriously.

I'm sure that it does.

The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient. I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.

This isn't about anyone's good intentions. It's about the reality of
past, very negative experience with FFmpeg's security track record.

It's clear that efforts are underway to improve that, such as through the
fuzz testing work that Google (among others) has been doing. That's
great, but I'm sure you can also understand that the past track record has
been sufficiently bad that everyone will continue to be leery for a while.
To change that impression, FFmpeg is going to have to substantially
improve on its past security track record and then *maintain* that new
level of security for some period of time.

Note that all of the above statements also apply to libav. As near as I
can tell, this is not a distinguishing characteristic between the two
projects.

[compn]

On Sat, 16 Aug 2014 11:59:20 -0700

Post by Russ Allbery
Two, the security team has already said that FFmpeg is not just "one
more package," and that no, they can't handle the substantial
incremental load from adding FFmpeg without removing libav. You may
be leery for a while. To change that impression, FFmpeg is going to
have to substantially improve on its past security track record and
then *maintain* that new level of security for some period of time.
Note that all of the above statements also apply to libav. As near
as I can tell, this is not a distinguishing characteristic between
the two projects.

ah, you dusted off the classic debian mplayer rejection reason!

from 2003 even!
http://comments.gmane.org/gmane.linux.debian.devel.legal/9519

nice to see debian hasnt changed.

-compn

[wm4]

On Sat, 16 Aug 2014 11:59:20 -0700

Post by Russ Allbery
The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient. I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.

That is very valuable advice. We'll get to work right away.

Post by Russ Allbery
Note that all of the above statements also apply to libav. As near as I
can tell, this is not a distinguishing characteristic between the two
projects.

And that's an argument against switching to FFmpeg exactly how?

[Derek Buitenhuis]

Post by wm4
That is very valuable advice. We'll get to work right away.

I've added it to my TODO:

* Don't write bugs.

- Derek

[Russ Allbery]

Post by Derek Buitenhuis

Post by wm4
That is very valuable advice. We'll get to work right away.

* Don't write bugs.

That's a really bad way of avoiding security bugs.

I'm sure you know that and are just being flippant, but I have to say
that, as an outsider to the project who would like to use the software but
who cares a lot about not introducing security weaknesses, it's hard to
shake the feeling that this dismissive attitude is part of the problem.
There were earlier responses in the thread along the same lines, arguing
that the nature of FFmpeg means it will just inevitably have a bunch of
security bugs. This sort of learned helplessness is really off-putting.

Thankfully, I get the impression from other research that I was doing
that it's *not* typical of FFmpeg as a whole, and that you all are, in
fact, doing exactly the sorts of things that I would recommend. So this
is probably just one of those pointless Internet arguments where everyone
says things more aggressively than they actually mean them, and much heat
is created with little light.

But, for the record, what I was actually getting at is that the way to
avoid a bunch of security bugs is not to stop writing bugs, because no one
is going to achieve that. It's to put in place supporting infrastructure
that makes it easier to write secure code and harder to write code where
bugs create security problems. Trying to be closer to perfect in the code
you write is a horrible way to achieve security. It doesn't work. Adding
surrounding protective structure to the code so that the bugs do not
compromise security, and putting systems in place that let the computer do
lots more security sanity checking for you, are how other projects with
similar challenges have achieved considerable improvements in security bug
rates.

In case there's anyone reading this who doesn't have a feel for what this
looks like, the process the LibreSSL project is going through (regardless
of one's opinion on the desirability of an OpenSSL fork) is very
interesting. I've personally learned quite a bit from it, have now
introduced reallocarray in my own code, and am planning on introducing
strtonum.

[Russ Allbery]

Post by wm4

Post by Russ Allbery
Note that all of the above statements also apply to libav. As near as I
can tell, this is not a distinguishing characteristic between the two
projects.

And that's an argument against switching to FFmpeg exactly how?

It's not. Nor was I trying to make one. This part of the thread was
discussing introducing FFmpeg into Debian alongside libav.

As I believe I mentioned previously, although the code base underlying
both projects has a bad past security track record, currently FFmpeg
appears to be doing somewhat better than libav. I believe a member of the
security team made a similar observation. So, when picking one, the
security argument seems to be at least partly in FFmpeg's favor. That was
not my point; my point was that picking both of them is something that had
already been discussed and rejected for what to me feel like sound
reasons.

Security of course isn't the only consideration when picking one of the
two, and regardless I'm not the person who would be deciding anything.
Mostly I'm speaking up because it felt like people were going down blind
alleys arguing about things that aren't really at issue.

Note that experimental doesn't receive security support. I may be missing
something (and here it's ftp-master that is the relevant decision-making
party), but I haven't seen any obvious reason why one shouldn't introduce
FFmpeg packages into experimental, particularly if people feel like
there's anything to be gained by seeing concrete packaging work, letting
people more easily experiment with the packages, and so forth. Of course,
that by itself doesn't imply anything about the broader question of
replacing libav with FFmpeg or not.

[Ondřej Surý]

Post by Russ Allbery
The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient. I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.

JFTR the Coverity Scan results for ffmpeg looks promising:
https://scan.coverity.com/projects/54

I am not saying that we should base our decisions on Coverity Scan[1]
results, but this is one more metric that could help to weight the
decision to one or other direction. (Also this is not an advice what
should ffmpeg do...)

Post by Russ Allbery
From the security viewpoint, I would be also interested if ffmpeg

has tests and what is current code coverage. That could help avoiding
regressions when doing security updates.

1. There are also other tools: llvm/clang scan_build, OCLint, cppcheck
(and other metrics like Cyclomatic complexity)

Cheers,
Ondrej

P.S.: libav doesn't seem to be using Coverity Scan actively:
https://scan.coverity.com/projects/106
(last scan was 4 months ago)

[Clément Bœsch]

Hi,

On Tue, Aug 19, 2014 at 10:50:31AM +0200, Ondřej SurÃœ wrote:
[...]

Post by Russ Allbery
From the security viewpoint, I would be also interested if ffmpeg
has tests and what is current code coverage. That could help avoiding
regressions when doing security updates.
1. There are also other tools: llvm/clang scan_build, OCLint, cppcheck
(and other metrics like Cyclomatic complexity)

See:
http://fate.ffmpeg.org/
http://coverage.ffmpeg.org/

[...]

Best Regards,

[Peter B.]

Post by Clément Bœsch
http://fate.ffmpeg.org/
http://coverage.ffmpeg.org/

The 2nd link to "coverage" (which should show the LCOV output, I guess)
seems to be broken:
I get a "404 Not Found" :(

Regards,
Pb

[Clément Bœsch]

Post by Peter B.

Post by Clément Bœsch
http://fate.ffmpeg.org/
http://coverage.ffmpeg.org/

The 2nd link to "coverage" (which should show the LCOV output, I guess)
I get a "404 Not Found" :(

Sorry about that, should be fixed.

[...]

[Andreas Cadhalpun]

Hi,

Post by Nicolas George
The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.
Can we get back on topic?

Yes. I have now sent the pkg-config patches to the BTS [1].

Post by Nicolas George
With or without libav in Debian, there are solid technical reasons to
have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick
(although they parted ways in a civilized way: different library names),
and we certainly have a ton of librarys which provide very similar features.

This is also my point of view.

Post by Nicolas George
Since before the fork, the libav developers have been sabotaging ffmpeg
as much as possible, in every "combat field": library names, library
versions, taking distributions hostage (ffmpeg package that installs
libav!?), etc. This is not the way to fork anything. This is a fact.

It would be nice, if everyone, including you, would refrain from posting
such flamebaits on debian-devel.
Please try to follow Debian's code of conduct [2].

Post by Nicolas George
I don't care whether Michael Nidermayer was a dictator or not. I don't
care whether the code-review rules in libav are better or worse. I don't
care what the Linux kernel does. The only thing I care about is Debian
is shipping a less-capable (i. e. less multimedia formats supported)
distribution due to this conflict.
This has to stop.
ffmpeg is not yet in Debian due to the filename clashing, which will
most certainly cause binary problems.

This is wrong, because the FFmpeg Debian packaging avoids filename
conflicts.

Post by Nicolas George
If libav and ffmpeg maintainers cannot reach an agreement regarding
library names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian.
E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc.

This is already done in the FFmpeg Debian packages.

Post by Nicolas George
Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been
done in the past.

This is not necessary, because the Libav binaries already have different
names, avconv, avplay and so on.

Post by Nicolas George
And before someone mentions it: I don't think it's too late. It's
getting too late because nobody with the right to act is doing anything.
In the end, our users are the ones being harmed and we are left
wondering why they are increasingly moving to other distributions or Mac
OS X.

Indeed it's getting late, because the FFmpeg package has been waiting in
the NEW queue for more than 3 months.

Best regards,
Andreas


1:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=***@googlemail.com
2: https://www.debian.org/code_of_conduct

[Andreas Cadhalpun]

Hi Russ,

All the renaming and cordial co-existence in the world won't change this.
The things that would change this is for one or both projects to develop a
better security track record and a history of higher-quality code releases
that require less ongoing work in stable,

Let's just have a look at FFmpeg's security track record.
The easiest way I found to do this quantitatively, is to count the CVEs
on FFmpegs security page [1] per year.

2011: 39
2012: 55
2013: 66

This indeed looks bad and even getting worse. But don't forget that e.g.
in 2012 the systematic fuzzing by Jurczyk and Coldwind began.

By now, more than half of 2014 is over and so far only 5 CVEs [3] have
been fixed in FFmpeg this year.
I must admit that I'm no security expert, but I think this shows that
FFmpeg's security has improved a lot.

or for the people who care
deeply about this to somehow find a way to relieve the impact on those
teams in some way acceptable to those teams.

Michael Niedermayer already volunteered to help with all security
related problems of FFmpeg in Debian.
So what should he do to relieve the impact on the security and release
teams?

Short of that, there's clearly a need for software of this type in Debian,
and at the same time it's clearly a ton of work. The teams involved have
indicated that they're willing (if not necessarily happy) to deal with one
version of the source base, but not two.

This still confuses me, because apparently nobody has a problem with
having three binary compatible MySQL variants in Debian:
MySQL, MariaDB and PerconaDB [4]

Best regards,
Andreas


1: https://ffmpeg.org/security.html
2: http://j00ru.vexillium.org/?p=2211
3: The security page shows 6 CVEs, but CVE-2014-4609 and CVE-2014-4610
are the same, once reported for Libav and once for FFmpeg.
4: https://lists.debian.org/debian-devel/2014/08/msg00016.html

[Thomas Goirand]

Post by Andreas Cadhalpun
Michael Niedermayer already volunteered to help with all security
related problems of FFmpeg in Debian.
So what should he do to relieve the impact on the security and release
teams?

Let's say he would take the role of patching stuff in Stable, there
would still be double work for the release team and security team for at
least:
- Checking the packages before upload of security fixes (that's security
team work), or upload of bugfixes to proposed-updates (that's the
release team)
- Making security announces

There's nothing Michael could do to reduce that work. However, as stated
before, uploading to Sid or Experimental could be done (if the SONAME
clash gets fixed), and I don't think anyone would oppose for more
contribution in Debian, especially with correct security support!

Thomas Goirand (zigo)

[Thomas Goirand]

Post by Nicolas George
So what about the code? Shall the FFmpeg developers discard three years of
work and start working on libav? Or shall the libav developers accept to
work with the code from FFmpeg that they do not like?

FFmpeg folks should rework the code to make it acceptable for the libav
people, and libav people should relax their policy. With *both* sides
trying to work on this, it may happen. If even *only one* of the teams
find excuses to not do a step forward, it wont.

Thomas

[Attila Kinali]

On Wed, 13 Aug 2014 00:30:05 +0200

Post by Michael Niedermayer
I never understood why people who once where friends
became mutually so hostile

You should know that better than anyone else!

You still claim to be my friend, yet you said and did things
that i have not seen from my enemies, let alone from my friends.
To this day, after 3 years, i still get accused by random people
of thing i supposedly have done against FFmpeg and the spirit
of open source. After 3 years i still have to defend myself against
these baseless attacks!

If you trully want to mend ways, then you and your fellow FFmpeg
developers should stop this constant spreading of lies, this
defamation campaing against libav and its developers that has
been going on for the last 3 and a half years and show at least
the minimum respect you would show to a stranger you meet on the
street. Until you do this, i see very little chance for a healthy
cooperation.

That said, i invite all FFmpeg developers to come to VDD next month
and sit together with everyone. So that we can have a healthy discussion
once again. Drink beer, hot chocolate and have fun together.


Attila Kinali

[Stefano Sabatini]

Post by Attila Kinali
On Wed, 13 Aug 2014 00:30:05 +0200

Post by Michael Niedermayer
I never understood why people who once where friends
became mutually so hostile

You should know that better than anyone else!
You still claim to be my friend, yet you said and did things
that i have not seen from my enemies, let alone from my friends.
To this day, after 3 years, i still get accused by random people
of thing i supposedly have done against FFmpeg and the spirit
of open source. After 3 years i still have to defend myself against
these baseless attacks!
If you trully want to mend ways, then you and your fellow FFmpeg
developers should stop this constant spreading of lies, this
defamation campaing against libav and its developers that has
been going on for the last 3 and a half years and show at least
the minimum respect you would show to a stranger you meet on the
street. Until you do this, i see very little chance for a healthy
cooperation.

Please refrain from claiming other people are spreading lies,
especially with no specific references (and this is not the place
where to discuss such things).

As for me, I don't consider Libav developers neither friends nor
enemies. We reached a point when we got two different projects with
different policies, culture, and guidelines. Then you should be aware
that the way the Libav fork was created was hostile towards FFmpeg, so
you shouldn't be surprised that there was (and still there is) a
perceived hostility between the two projects. If you or other Libav or
FFmpeg developers want the two projects to collaborate more, this can
be discussed, possibly with *specific* proposals, but again,
debian-devel is not the right place where to discuss such things.

[Bálint Réczey]

Post by Stefano Sabatini

Post by Attila Kinali
On Wed, 13 Aug 2014 00:30:05 +0200

Post by Michael Niedermayer
I never understood why people who once where friends
became mutually so hostile

You should know that better than anyone else!
You still claim to be my friend, yet you said and did things
that i have not seen from my enemies, let alone from my friends.
To this day, after 3 years, i still get accused by random people
of thing i supposedly have done against FFmpeg and the spirit
of open source. After 3 years i still have to defend myself against
these baseless attacks!
If you trully want to mend ways, then you and your fellow FFmpeg
developers should stop this constant spreading of lies, this
defamation campaing against libav and its developers that has
been going on for the last 3 and a half years and show at least
the minimum respect you would show to a stranger you meet on the
street. Until you do this, i see very little chance for a healthy
cooperation.

Please refrain from claiming other people are spreading lies,
especially with no specific references (and this is not the place
where to discuss such things).
As for me, I don't consider Libav developers neither friends nor
enemies. We reached a point when we got two different projects with
different policies, culture, and guidelines. Then you should be aware
that the way the Libav fork was created was hostile towards FFmpeg, so
you shouldn't be surprised that there was (and still there is) a
perceived hostility between the two projects. If you or other Libav or
FFmpeg developers want the two projects to collaborate more, this can
be discussed, possibly with *specific* proposals, but again,
debian-devel is not the right place where to discuss such things.

I have no problem with FFmpeg and Libav developers discussing
collaboration on debian-devel especially if they finally sit together
and find a way in which they could join efforts after years of working
in separation.
This would be Legen... ...dary. :-)

Cheers,
Balint

[Attila Kinali]

On Thu, 14 Aug 2014 13:58:07 +0200

Post by Stefano Sabatini

Post by Attila Kinali
If you trully want to mend ways, then you and your fellow FFmpeg
developers should stop this constant spreading of lies, this
defamation campaing against libav and its developers that has
been going on for the last 3 and a half years and show at least
the minimum respect you would show to a stranger you meet on the
street. Until you do this, i see very little chance for a healthy
cooperation.

Please refrain from claiming other people are spreading lies,
especially with no specific references (and this is not the place
where to discuss such things).

Carl Eugen just recently (2014-06-22) wrote on ffmpeg-devel:
"Sean supports the thieves [...]"
(http://article.gmane.org/gmane.comp.video.ffmpeg.devel/179271)

Do i need to say more?

I guess i speak in the name of everyone related to libav, that
we would not mind if you kept saying that ffmpeg is better, faster,
has more features, etc. That could be at least discussed on a
technical, neutral level. What we mind are comments like that above,
targeted solely at insulting and slander individuals.
And as we can see from what Joe Neal wrote, the often repeated lie
becomes truth soon enough.

Post by Stefano Sabatini
Then you should be aware
that the way the Libav fork was created was hostile towards FFmpeg

Actually, no. The whole thing started as getting Michael off his throne
and to stop him screwing the whole project. It was not ment to be
a fork.


Attila Kinali

[Michael Niedermayer]

[...]

The list is quite long and debunking each of the statements could take a
lot of time.
# The change of management
Michael Niedermayer managed to get demoted from his leader position by
the topmost 18[1] people involved in FFmpeg by the time due his tendency
of not following the rules. that after weeks from being voted to stay as
leader by 15, 5 explicitly stating their vote was conditioned by his
behaviour and 1 definitely against him.[2]

There was a vote on the ffmpeg-devel list, everyone can recount the
votes although its probably a bit work to do given its a large thread
with lots of other discussions (the links below point to that thread)
I dont remember the exact numbers but there was a majority in
support of me in all possible variants in which one could count the
votes

That said, i dont mind if people like to see me as dictator

His demotion is due to acts in full disregard of the policies in place,

Ive asked [1][2] back then what "policy in place" was broken
IIRC noone pointed at anything thats part of the written policy[3]
Some good suggestions where made in the discussion though.
And the policy was somewhat amended toward them [4].

In retrospect, bigger changes should have been made to the policy
if that had avoided the takeover attempt and fork, but the takeover
attempt came a bit out of the blue, at least for me and it definitely
left the feeling that there was more interrest in seizing the
opertunity for a takeover instead of discussing and amending the
policy.
Also i remember alot more discussions about whitespaces than patch
review policy from that time.

even those enforced automatically by the svn hooks.

yes, we wanted to check in some files that would be shared between
mplayer and ffmpeg, and for ease of syncing changes between them
either tabs&trailing whitespace had to be removed from mplayers side
or the svn hook in ffmpeg would have needed an exception
They where removed from mplayer in SVN rev 32789 and 32790

The commit message of 32789
"Convert some tabs to whitespace to allow using MPlayer filter sourcecode in FFmpeg."


[...]

Post by Stefano Sabatini
you shouldn't be surprised that there was (and still there is) a
perceived hostility between the two projects. If you or other Libav or
FFmpeg developers want the two projects to collaborate more, this can
be discussed, possibly with *specific* proposals, but again,
debian-devel is not the right place where to discuss such things.

Personally I have no problems in collaborating with anybody.

Then i think we should reunite the projects with some common
development policy most are happy with.

PS: please spare the world of these defamation attempts
and i also think we should look forward and solve the issues we have
now and not fight over what happenend 3-4 years ago or who made more
mistakes ...


[...]

[1] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/118606
[2] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/118652
[3] http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/developer.texi;hb=f2c44ad51160da4c0c27429e874265c0dff3d117#l122
[4] http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7c0460496b5eeb1713f00c00e2e61b420bb928e7