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

[Reinhard Tartler]

On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun

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

In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing. In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the
question above.

I think it would be best if ftp-master left the ffmpeg package in NEW
until an answer to this problem has been found.

[1] https://lists.debian.org/debian-devel/2014/02/msg00668.html

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

I am curious why this is your first email about this matter to
pkg-multimedia, and why do you write this email only now?

Moreover, I am curious why I haven't seen you working on libavcodec
bugs in Debian before, and why do you believe you can do a better job
with the ffmpeg package currently on NEW?

[Marco d'Itri]

Post by Reinhard Tartler
Moreover, I am curious why I haven't seen you working on libavcodec
bugs in Debian before, and why do you believe you can do a better job
with the ffmpeg package currently on NEW?

Why should he work on libavcodec when he (along with many other people)
wants ffmpeg instead?

[Norbert Preining]

Hi,

Post by Reinhard Tartler
In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing. In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the

"More than uncomfortable" does not mean "will not be included"

Post by Reinhard Tartler
I think it would be best if ftp-master left the ffmpeg package in NEW
until an answer to this problem has been found.

Why, only because libav gets a more powerful and efficient
competition?

Post by Reinhard Tartler
I am curious why this is your first email about this matter to
pkg-multimedia, and why do you write this email only now?
Moreover, I am curious why I haven't seen you working on libavcodec
bugs in Debian before, and why do you believe you can do a better job
with the ffmpeg package currently on NEW?

As Marco said, why should he fix bugs in av which have been fixed since
ages in ffmeg in many (most?) cases?

I am all for having a good ffmpeg set of cmd line progs and libs in
Debian. It is too long that this sad and useless split was made.

Norbert

------------------------------------------------------------------------
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
------------------------------------------------------------------------

[Niv Sardi]

The change in Debian-specific symbol versioning and sonames being done to
ffmpeg so that it is co-installable with libav *is* a problem.
It has to be done in coordination with the Canonical guys, so that both
Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol
versioning. Otherwise, the ffmpeg packages will be of very limited use
(useless to run third-party binary-only games ;-p).

Not really, ffmpeg is packaged as a secondary multimedia library, the
default one still being libav. If these packages get traction, we can think
of moving ffmpeg to be the default (and ship if we wish libav with the
soname change).

The package will be of use for the ffmpeg command line tools, and for the
maintainers that decide to make the switch.

For now, your binary third party games will have to link against libav.

I understand perfectly that the soname and symbol versioning clash with
libav is not ffmpeg's fault, but that's water (well, sewage) under the
bridge. We have to deal with it. Here's an alternative proposal that
You need one of the two upstreams to do a *large* major soname bump (at
least one order of magnitude higher than what they're currently using), so
that both projects can keep evolving with little chance of soname clashes.
Symbol versioning will take care of the rest, since both libs carry over
their major soname into the symbol version. As it was done upstream,
cross-distro/third-party compatibility problems are not increased.
Debian will have to package this new "bumped" upstream release, and get

rid

of anything built against the old one. It will be easier for Debian if it
is ffmpeg upstream that does the soname bump, otherwise we're talking

about

a huge number of binNMUs.

That's been discussed and ruled out in favour of not overstepping libav's
namespace.

But this is all academic if the security team is not prepared to deal with
both libav and ffmpeg at the same time. That effectively forces a choice

of

either libav, or ffmpeg, and not both.

That is premature, let's deal with this issue when we have more data.

[Andreas Cadhalpun]

Post by Norbert Preining

Post by Reinhard Tartler
In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing. In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the

"More than uncomfortable" does not mean "will not be included"

Yes, it does.
Someone will have to convince the security team somehow, likely by offering
to do the work themselves _and_ convincing them that these new members will
be around for long enough.

Michael Niedermayer from FFmpeg upstream volunteered "to help with any
future security issues in FFmpeg packages in debian" [1].

The change in Debian-specific symbol versioning and sonames being done to
ffmpeg so that it is co-installable with libav *is* a problem.
It has to be done in coordination with the Canonical guys, so that both
Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol
versioning. Otherwise, the ffmpeg packages will be of very limited use
(useless to run third-party binary-only games ;-p).

I don't think coordination with Ubuntu will be a problem.
In comment #7 in the corresponding bug at launchpad [2] Dimitri John
Ledkov wrote that Ubuntu won't introduce FFmpeg on it's on, but instead:
"If you wish to see a supported ffmpeg stack in both Debian and Ubuntu,
please become a developer and start maintaining it in Debian."

Best regards,
Andreas


1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#528
2: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263278

[Michael Niedermayer]

Post by Andreas Cadhalpun

Post by Norbert Preining

Post by Reinhard Tartler
In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing. In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the

"More than uncomfortable" does not mean "will not be included"

Yes, it does.
Someone will have to convince the security team somehow, likely by offering
to do the work themselves _and_ convincing them that these new members will
be around for long enough.

Michael Niedermayer from FFmpeg upstream volunteered "to help with
any future security issues in FFmpeg packages in debian" [1].

Yes, i do!

[...]

[Dimitri John Ledkov]

On 28 July 2014 15:05, Andreas Cadhalpun

Post by Andreas Cadhalpun

Post by Norbert Preining

Post by Reinhard Tartler
In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing. In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the

"More than uncomfortable" does not mean "will not be included"

Yes, it does.
Someone will have to convince the security team somehow, likely by offering
to do the work themselves _and_ convincing them that these new members will
be around for long enough.

Michael Niedermayer from FFmpeg upstream volunteered "to help with any
future security issues in FFmpeg packages in debian" [1].

The change in Debian-specific symbol versioning and sonames being done to
ffmpeg so that it is co-installable with libav *is* a problem.
It has to be done in coordination with the Canonical guys, so that both
Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol
versioning. Otherwise, the ffmpeg packages will be of very limited use
(useless to run third-party binary-only games ;-p).

I don't think coordination with Ubuntu will be a problem.
In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov
"If you wish to see a supported ffmpeg stack in both Debian and Ubuntu,
please become a developer and start maintaining it in Debian."

I don't have an opinion about ffmpeg vs libav, apart from how hard the
soname transitions are, especially in ubuntu where we somehow ended up
with ex-multimedia packages around that either never were in debian,
or have been long removed from testing and/or unstable. Thankfully, we
have worked to make sure libav is in universe only and thus is not a
security maintenance burden. Nonetheless, libav10 transition is still
not complete in utopic today. I haven't checked, but now abi
compatible/incompatible the two stacks are? cause it would be a pain
if they are not drop in replacements, and it would also be a pain if
higher up packages link-in both ffmpeg & libav and some clashing
symbols are present... and people start requesting to have build
variants against both. Has a rebuild of all deps been done? How many
build failures there are? (On both debian & ubuntu, ideally) Is
hardening flags / toolchain enabled in both, or either of the two?

[Andreas Cadhalpun]

Hi Dimitri,

Post by Dimitri John Ledkov
I don't have an opinion about ffmpeg vs libav, apart from how hard the
soname transitions are, especially in ubuntu where we somehow ended up
with ex-multimedia packages around that either never were in debian,
or have been long removed from testing and/or unstable.

There are only 6 additional reverse-build-dependencies of src:libav in
utopic. Two build against lib*-ffmpeg-dev without further changes, one
needs a simple patch to use pkg-config, one needs a patch to adapt to
newer API (also needed for Libav 10), one is BD-uninstallable and one
fails for unrelated reasons, but its build-dependencies on libav*-dev
seem to be unnecessary anyway.

Per package list:

alsa-plugins-extra: OK
bombono-dvd: PATCH CodecID
dvdstyler: Unmet build dependencies: libwxsvg-dev (>= 2:1.0.9)
gstreamer-vaapi: error: unsupported GStreamer API version 1.4
kffmpegthumbnailer: OK
libdlna: PATCH pkg-config

The patches are attached to this mail.

Post by Dimitri John Ledkov
Thankfully, we
have worked to make sure libav is in universe only and thus is not a
security maintenance burden. Nonetheless, libav10 transition is still
not complete in utopic today.

Is bombono-dvd the last blocker?

Post by Dimitri John Ledkov
I haven't checked, but now abi
compatible/incompatible the two stacks are? cause it would be a pain
if they are not drop in replacements, and it would also be a pain if
higher up packages link-in both ffmpeg & libav and some clashing
symbols are present...

As Marco already wrote, FFmpeg is packaged to be ABI incompatible with
Libav, having different sonames and different symbol versions.

Post by Dimitri John Ledkov
and people start requesting to have build
variants against both.

This could theoretically be done, but I don't think anyone wants to
maintain such a thing, especially because it would need two different
source packages, as the development packages of FFmpeg and Libav have to
conflict.

Post by Dimitri John Ledkov
Has a rebuild of all deps been done? How many
build failures there are? (On both debian & ubuntu, ideally) Is
hardening flags / toolchain enabled in both, or either of the two?

I did a rebuild of all the reverse-build-dependencies in sid and the
results can be found in my original mail.
For Ubuntu, see the beginning of this mail.

I'm not sure what you want to know about hardening.
The packages are otherwise unchanged, so use hardening flags if they
already do.
If that question was about FFmpeg/Libav, then yes, FFmpeg uses
--toolchain=hardened and Libav hardening flags.

Best regards,
Andreas

[Pau Garcia i Quiles]

On Tue, Jul 29, 2014 at 6:10 PM, Andreas Cadhalpun <

Post by Dimitri John Ledkov
I don't have an opinion about ffmpeg vs libav, apart from how hard the

Post by Dimitri John Ledkov
soname transitions are, especially in ubuntu where we somehow ended up
with ex-multimedia packages around that either never were in debian,
or have been long removed from testing and/or unstable.

There are only 6 additional reverse-build-dependencies of src:libav in
utopic. Two build against lib*-ffmpeg-dev without further changes, one
needs a simple patch to use pkg-config, one needs a patch to adapt to newer
API (also needed for Libav 10), one is BD-uninstallable and one fails for
unrelated reasons, but its build-dependencies on libav*-dev seem to be
unnecessary anyway.
alsa-plugins-extra: OK
bombono-dvd: PATCH CodecID
dvdstyler: Unmet build dependencies: libwxsvg-dev (>= 2:1.0.9)
gstreamer-vaapi: error: unsupported GStreamer API version 1.4
kffmpegthumbnailer: OK
libdlna: PATCH pkg-config

In addition to this, I would like to note there is a lot of closed-source
software which uses ffmpeg instead of libav.

Not saying it doesn't exist but I don't know a single piece of
closed-source software which has moved from ffmpeg to libav.

I know, I know "non DFSG-free software, we don't care". Well, I do. E. g.
I'm having trouble with Qt right now because I'm using the commercial SDK
which indirectly uses ffmpeg to provide some codecs on Linux.

[Andreas Cadhalpun]

Hi Reinhard,

Post by Reinhard Tartler
On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun

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

In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing.

I discussed this with Moritz in the ITP bug. Moritz ended this
discussion [a], and as I wasn't convinced by his arguments, I continued
my work. If in the end really only one copy is allowed in the next
stable release, I think it should be FFmpeg.

Post by Reinhard Tartler
In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the
question above.

It remains to be seen, what the release team prefers: frustrated users
and developers or both forks in jessie.

Post by Reinhard Tartler
I think it would be best if ftp-master left the ffmpeg package in NEW
until an answer to this problem has been found.

I fail to see how this would help anyone, it only makes testing the
package more difficult. Whether or not the package is acceptable for the
next stable release is not to be decided by the ftp-masters, but rather
by the release team.

Post by Reinhard Tartler
[1] https://lists.debian.org/debian-devel/2014/02/msg00668.html

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

I am curious why this is your first email about this matter to
pkg-multimedia, and why do you write this email only now?

In the last discussion on debian-devel it was suggested to get the
FFmpeg packages into experimental first [b], before further discussion,
so I tried to achieve that.

As the package has been in NEW for a rather long time and the freeze is
getting closer, sending this mail now seemed appropriate.

Post by Reinhard Tartler
Moreover, I am curious why I haven't seen you working on libavcodec
bugs in Debian before,

It would be great if I could fix every bug in Debian, but unfortunately
my time is limited. Therefore, when I encounter a problem that cannot
immediately be fixed, I try to work around it. The workaround for
practically all problems I had with the Libav packages in Debian could
be solved by installing FFmpeg binaries from third parties. Therefore I
finally decided to work on a more sustainable solution, i.e. a FFmpeg
package in Debian.

Post by Reinhard Tartler
and why do you believe you can do a better job
with the ffmpeg package currently on NEW?

It is a lot more likely that I work on fixing a bug that affects me, if
there is no easy workaround.

Best regards,
Andreas


a: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#568
b: https://lists.debian.org/debian-devel/2014/02/msg00714.html

[Julien Cristau]

Post by Andreas Cadhalpun
Hi Reinhard,

Post by Reinhard Tartler
On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun

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

In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing.

I discussed this with Moritz in the ITP bug. Moritz ended this discussion
[a], and as I wasn't convinced by his arguments, I continued my work. If in
the end really only one copy is allowed in the next stable release, I think
it should be FFmpeg.

Post by Reinhard Tartler
In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the
question above.

It remains to be seen, what the release team prefers: frustrated users and
developers or both forks in jessie.

The release team is likely to let the people involved in multimedia foo
fight it out among themselves and pick a winner. We're not going to
ship both and hand that mess over to the security team.

Cheers,
Julien

[Marco d'Itri]

Personally I don't feel like dropping libav in favor of ffmpeg now at
this stage. It's too late for Jessie.

Except that, for a lot of the depending packages, there would be an
immediate benefit in the number of bugs fixed.

Personally I feel that we have inflicted libav on our users for way more
time than it was sensible to do.

[Alessio Treglia]

On Mon, Jul 28, 2014 at 12:12 PM, "IOhannes m zmölnig (Debian/GNU)"

Post by Marco d'Itri
Except that, for a lot of the depending packages, there would be an
immediate benefit in the number of bugs fixed.

at least in theory.

Plus I would definitely appreciate to see some bug stats supporting
such a theory.

Cheers.

(IOhannes et Multimedia guys, please let's keep debian-devel in the
loop, I feel this is much more of general interest than a thing that
needs to be addressed internally in pkg-multimedia)
--
Alessio Treglia | www.alessiotreglia.com
Debian Developer | ***@debian.org
Ubuntu Core Developer | ***@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A

[IOhannes m zmölnig (Debian/GNU)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

(resending, to keep debian-devel and the bug-report in the loop)

personally i would welcome if both libav and ffmpeg could co-exist
within Debian¹.
as i see it, libav and ffmpeg have diverged, and as such i would like
to have the choice which one to use.

Post by Marco d'Itri

Personally I don't feel like dropping libav in favor of ffmpeg
now at this stage.

+ 1
i don't think that dropping libav is appropriate at all.

Post by Marco d'Itri
Except that, for a lot of the depending packages, there would be
an immediate benefit in the number of bugs fixed.

at least in theory.

Post by Marco d'Itri
Personally I feel that we have inflicted libav on our users for
way more time than it was sensible to do.

i would appreciate it, if you (and anybody else) used a less flammable
&| touchy language.


fgmadr
IOhannes



¹ but then i'm not a member of the security team :-)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJT1jRXAAoJELZQGcR/ejb45GYP/2a06m3B6PRGyjV6oGS1xwDg
0if/Lssn500F8yjrYFKnexKGZg6xncKVKJ+NJncX3pIWMKu/fOXKJusC5Z5eMdvg
Ecruo7sXBojUnUxtaibGExkjdCWHv4wC/xwx/gQVUg3ijQGr5CQgZKXRPzf6dAG5
Sc4KS7w1SBtgLWaKvsOVhljSB39lye1cUk8vgkPkvSytJPiFMo1QSCDlbNz5JGbf
4c8viga5W9KCH5zMLzZTRQOkiPQpZMPsd/l220YX6ADwlBhnG/yRFBx7SBOnVDYb
BIWb4MFrsCikzC5gJrJZdVAkB96AWOWR6J8N0s8LI2Y1ZwOIM4nJB1FNeQvFRaJI
xe5p3dTI5DS7Kvc6i4LjKcO5m1EdZXeS1vV/OMDrLtgpfDC7pfhn3lImaYMPGCpA
60GNGo/PnbUMWGT3Z5JCeX/Q59X53d8DrW7gTcrQoSr6y0DN8AFEpcuDCYbd2ubt
/A+0MeocRPNKGiNB7lEfvpSD3x3e4pGlSFB1AMgnwCGmpXzHeA51LzbDJGtfdWon
x8L7OD5QD/LwRqQtAncRpf9jB56oJvktmznluSuCcJeY9ADSYH2YDPC1g3CCnuKG
SOJpSClZrPjlc2511emDcnOaMJhkyjeQ8R+I67+I05r0jBdk2FDnFASsNVVcRV5o
lzO+UTdVUs0nWsiDa+CX
=PGZV
-----END PGP SIGNATURE-----

[Alessio Treglia]

Ciao,

Post by Julien Cristau
The release team is likely to let the people involved in multimedia foo
fight it out among themselves and pick a winner. We're not going to
ship both and hand that mess over to the security team.

Personally I don't feel like dropping libav in favor of ffmpeg now at
this stage. It's too late for Jessie.
Rather I'd suggest to start reconsidering such switch for Jessie+1.

Cheers.
--
Alessio Treglia | www.alessiotreglia.com
Debian Developer | ***@debian.org
Ubuntu Core Developer | ***@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A

[Andreas Cadhalpun]

Hi Julien,

Post by Julien Cristau

Post by Andreas Cadhalpun
It remains to be seen, what the release team prefers: frustrated users and
developers or both forks in jessie.

The release team is likely to let the people involved in multimedia foo
fight it out among themselves and pick a winner.

I am not interested in a "fight" and would prefer it very much if this
discussion remained purely technical.
Having a fresh memory of the last fight that took place on debian-devel,
I do not think that repeating a similar disaster is a good idea.

Post by Julien Cristau
We're not going to ship both and hand that mess over to the security team.

Could you please explain what "mess" you are talking about?

According to the changelog[1], there have been 8 security updates for
ffmpeg in squeeze. Two of them (4:0.5.6-2 and 4:0.5.6-3) do not contain
security related fixes, but rather fix build failures of the previous
security upload, so they do not really count.
That makes about 6 security fix uploads in about 3 years for squeeze,
i.e. 1 upload per 6 month.

If there were both forks in Jessie, this might double the number of
uploads to 12 in 3 years, but probably some of them could also go
through stable-updates instead of stable-security.

Is that an unbearable burden?

A lot of other software in Debian has already alternatives, like desktop
environments, web browsers, text editors and even init systems.

Why should this not be the case for a multimedia framework?

There is also one particularly similar case, as in the packages are
forks and require many security updates:
MySQL and MariaDB are currently in Debian testing.

Just for comparison, MySQL in squeeze had 3 uploads to stable-security
and 3 to oldstable(-security) [2].

As I mentioned this particular example in my discussion with Moritz, he
said that the security team will "be working with the release
team to sort this out for jessie"[3].

Now, 5 months later, he seems to have changed his mind, as I am not
aware of any such attempt, but instead Moritz seems to support both [4][5].

Thanks in advance for taking the time to answer these questions.

Best regards,
Andreas


1:
http://metadata.ftp-master.debian.org/changelogs//main/f/ffmpeg/ffmpeg_0.5.10-1_changelog

2:
http://metadata.ftp-master.debian.org/changelogs//main/m/mysql-5.1/mysql-5.1_5.1.73-1_changelog
3: https://bugs.debian.org/729203#435
4: https://bugs.debian.org/754940
5: https://bugs.debian.org/754941

[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.

[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,​

[Andreas Cadhalpun]

user debian-***@lists.debian.org
usertags 729203 copyright-review-requested
thanks

Hi Charles,

A few years ago, I made a proposal for peer-reviewing copyright files in the
NEW queue.
https://wiki.debian.org/CopyrightReview
The goal is not to substitute for the inspection by the FTP Master team, but to
correct defects before their review, therefore saving their time.

This looks like a good idea, but unfortunately it seems not to be an
often used process.

I have done a few dozens of these reviews and share Thorsten's impression in
general (althouth in my opinion 80 % is quite an upper-range estimate…).

I have no accurate numbers, but I just reviewed three packages [1-3] and
found problems in all of them. It's a rather small sample size, but still...

I encourage everybody who uploads to the NEW queue to review some packages in
exchange. To help people reviewing your package, please make sure that a
copy is accessible (source packages in the NEW queue are not accessible outside
the FTP Master team).

Now, could anyone review the debian/copyright file of ffmpeg?
The sources are available in this repository:
https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git

Best regards,
Andreas

1: https://bugs.debian.org/686447
2: https://bugs.debian.org/735884
3: https://bugs.debian.org/683746

[Charles Plessy]

user debian-***@lists.debian.org
usertags 729203 one-copyright-review
thanks

Post by Andreas Cadhalpun
Now, could anyone review the debian/copyright file of ffmpeg?
https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git

Hi Andreas,

I searched for license information missing from your debian/copyright and could
find only one case, libavutil/x86/x86inc.asm, which is under the ISC license.

The debian/copyright file of your package looks comprehensive to me.

Have a nice week-end,

[Andreas Cadhalpun]

Hi Charles,

Post by Charles Plessy
I searched for license information missing from your debian/copyright and could
find only one case, libavutil/x86/x86inc.asm, which is under the ISC license.
The debian/copyright file of your package looks comprehensive to me.

Many thanks for the copyright review. (I know it is a lot of work.)

I added the missing information you found (and also uppercased some
license names to match the copyright format specification) [1].

It's probably not necessary to make a new upload to the NEW queue for
this change. In the repository is a new upstream version anyway and it
will be uploaded, once the current version gets accepted.

Best regards,
Andreas


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

[Jonas Smedegaard]

Quoting Andreas Cadhalpun (2014-08-09 13:34:04)

Post by Andreas Cadhalpun

Post by Charles Plessy
I searched for license information missing from your debian/copyright
and could find only one case, libavutil/x86/x86inc.asm, which is
under the ISC license.
The debian/copyright file of your package looks comprehensive to me.

Many thanks for the copyright review. (I know it is a lot of work.)
I added the missing information you found (and also uppercased some
license names to match the copyright format specification) [1].
It's probably not necessary to make a new upload to the NEW queue for
this change. In the repository is a new upstream version anyway and it
will be uploaded, once the current version gets accepted.

In my experience you need not wait for ftpmaster approval to issue
subsequent releases: When approving, they will simply approve the
subsequent releases as well.

If you don't release updates, you may risk that when ftpmaster finds
time to inspect your package they find flaws (which you knew about and
had prepared fixes for but did not in fact formally provide) - and you
get the package rejected and need to wait for _next_ window that they
find time to inspect it anew.


- Jonas

[Andreas Cadhalpun]

Hi Jonas,

Post by Jonas Smedegaard
Quoting Andreas Cadhalpun (2014-08-09 13:34:04)

Post by Andreas Cadhalpun

Post by Charles Plessy
I searched for license information missing from your debian/copyright
and could find only one case, libavutil/x86/x86inc.asm, which is
under the ISC license.
The debian/copyright file of your package looks comprehensive to me.

Many thanks for the copyright review. (I know it is a lot of work.)
I added the missing information you found (and also uppercased some
license names to match the copyright format specification) [1].
It's probably not necessary to make a new upload to the NEW queue for
this change. In the repository is a new upstream version anyway and it
will be uploaded, once the current version gets accepted.

In my experience you need not wait for ftpmaster approval to issue
subsequent releases: When approving, they will simply approve the
subsequent releases as well.
If you don't release updates, you may risk that when ftpmaster finds
time to inspect your package they find flaws (which you knew about and
had prepared fixes for but did not in fact formally provide) - and you
get the package rejected and need to wait for _next_ window that they
find time to inspect it anew.

Thanks for warning me, as that would indeed be unfortunate, so I'm going
to ask my sponsor to make a new upload.

Best regards,
Andreas

[Cyborg Ethly Alpha {My Research Desk}]

Hi Everyone,

Just wanted to let you know, I'm still working on my ppa (I'm still
trying to fund the test bench). As well, there is a discussion on Ubuntu
forums;
http://ubuntuforums.org/showthread.php?t=2149564&p=13100237#post13100237 .

From My Research Desk :)

Post by Andreas Cadhalpun
Hi Jonas,

Post by Jonas Smedegaard
Quoting Andreas Cadhalpun (2014-08-09 13:34:04)

Post by Andreas Cadhalpun

Post by Charles Plessy
I searched for license information missing from your debian/copyright
and could find only one case, libavutil/x86/x86inc.asm, which is
under the ISC license.
The debian/copyright file of your package looks comprehensive to me.

Many thanks for the copyright review. (I know it is a lot of work.)
I added the missing information you found (and also uppercased some
license names to match the copyright format specification) [1].
It's probably not necessary to make a new upload to the NEW queue for
this change. In the repository is a new upstream version anyway and it
will be uploaded, once the current version gets accepted.

In my experience you need not wait for ftpmaster approval to issue
subsequent releases: When approving, they will simply approve the
subsequent releases as well.
If you don't release updates, you may risk that when ftpmaster finds
time to inspect your package they find flaws (which you knew about and
had prepared fixes for but did not in fact formally provide) - and you
get the package rejected and need to wait for _next_ window that they
find time to inspect it anew.

Thanks for warning me, as that would indeed be unfortunate, so I'm
going to ask my sponsor to make a new upload.
Best regards,
Andreas