[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Ivan Kalvachev]

On 8/16/14, Pau Garcia i Quiles <pgquiles at elpauer.org> wrote:
> On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George <george at nsup.org> wrote:
>
>
>> 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