Bug#729203: ffmpeg alongside libav

[Timothy Gu]

On Feb 11, 2014 4:09 PM, "Antoine Beaupré" @
debian.org > wrote:
>
> On 2014-02-11 19:00:45, Timothy Gu wrote:
> > On Feb 11, 2014 10:27 AM, "Antoine Beaupré" 
@ debian.org > wrote:
> >>
> >> On 2014-02-11 13:04:53, Timothy Gu wrote:

> >> > I have also tried to build http:// 
> >> > mpv.io/ with
ffmpeg instead of
> >> > libav, and I received success in doing tthat as well. Build script is
> >> > in the gist as well.
> >>
> >> Thanks for sharing! That will certainly be useful for others.
> >
> > It should work for all applications wishing to support FFmpeg, including
> > VLC. But the PKG_CONFIG_PATH is really not optimal.
>

> That, and -rpath is designed for private libraries, so I don't think
> that could end up in the archive legitimately.

To add ffmpeg to Debian, we have four options:

1. Make both programs and libraries available as a replacement for Libav.
This would require full ABI, API, and behavior compatibility. This is the
best if compatibilities are satisfied.

2. Use RPATH to make shared build libraries and programs and static
libraries available. This is my solution for incompatible libraries. This
way, ffmpeg programs can share libraries, and users who wish to use ffmpeg
for other programs can compile the apps *themselves*, either dynamically or
statically. The inconvenience of this method is mainly that a user must
compile apps themselves.

3. Make only static libraries and programs available. This is your
solution. This has several bad consequences comparing to #2:
  - ffmpeg programs would be too big.
  - a user cannot run two copies of a program that use either Libav/FFmpeg
alongside each other.

4. Make FFmpeg the default in Debian. This is way too controversial, and if
people still want Libav to be in Debian, #2 or #3 must be used because
Libav is not trying to maintain compatibility with FFmpeg at all.

>
> A static link, on the other hand, may have a legitimate purpose.

I don't see *any* advantages over RPATH except for silencing a few lintian
warnings. People who wants to use FFmpeg libs still need to compile the app
on their own. And if the static libs are installed to std locations it
would cause more confusion as the static and shared libs in one directories
are different.

Timothy

Bug#729203: ffmpeg alongside libav

[Antoine Beaupré]

On 2014-02-11 19:25:57, Anssi Hannula wrote:
> Well, statically linking all the four ff* executables of ffmpeg would
> quadruple the total size due to duplication, and the libraries already
> take over 10MB even without that...

Point taken, patches / pull requests / git send-email welcome. :P

Note that at this point, I have lost interest in this a little since my
peculiar bug is fixed in libav 10, available in experimental. :)

A.

-- 
Pour marcher au pas d'une musique militaire, il n'y a pas besoin de
cerveau, une moelle épinière suffit.
- Albert Enstein


pgpBpQh5upoQ0.pgp
Description: PGP signature

Bug#729203: ffmpeg alongside libav

[Anssi Hannula]

12.02.2014 02:09, Antoine Beaupré kirjoitti:
> On 2014-02-11 19:00:45, Timothy Gu wrote:
>> On Feb 11, 2014 10:27 AM, "Antoine Beaupré"  wrote:
>>>
>>> Besides, -rpath is actually a lintian warning:
>>>
>>> http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html
>>
>> The page states that:
>>
>> The only time a binary or shared library in a Debian package should set
>> RPATH is if it is linked to private shared libraries in the same package.
>> In that case, place those private shared libraries in /usr/lib/*package*.
>>
>> That's exactly what's happening here if we'd like to add the ffmpeg
>> programs but not use the libraries for other packages. Still, shared
>> libraries are better than statically linking the ffmpeg programs.
> 
> Ah, right, I see what you mean. I guess it would be better, but I think
> it's only a marginal gain over a statically linked binary: it would
> bring some confusion over the purpose of those libraries... Would other
> packages be allowed to link against them?

Well, statically linking all the four ff* executables of ffmpeg would
quadruple the total size due to duplication, and the libraries already
take over 10MB even without that...

-- 
Anssi Hannula


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fabf95.9010...@xbmc.org

Bug#729203: ffmpeg alongside libav

[Antoine Beaupré]

On 2014-02-11 19:00:45, Timothy Gu wrote:
> On Feb 11, 2014 10:27 AM, "Antoine Beaupré"  wrote:
>>
>> On 2014-02-11 13:04:53, Timothy Gu wrote:
>> > I have experimented with the new --enable-rpath configure option of
>> > FFmpeg, and found that it is even possible to install shared libraries
>> > alongside Libav, without interrupting Libav headers, programs, or
>> > libraries. See my gist: https://gist.github.com/TimothyGu/8533059
>>
>
>> Hum... isn't that because you install in /usr/local more than -rpath?
>
> I used /usr/local because if I mess up I can delete the installation
> completely. But it should work with /usr.

Understood.

>> Besides, -rpath is actually a lintian warning:
>>
>> http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html
>
> The page states that:
>
> The only time a binary or shared library in a Debian package should set
> RPATH is if it is linked to private shared libraries in the same package.
> In that case, place those private shared libraries in /usr/lib/*package*.
>
> That's exactly what's happening here if we'd like to add the ffmpeg
> programs but not use the libraries for other packages. Still, shared
> libraries are better than statically linking the ffmpeg programs.

Ah, right, I see what you mean. I guess it would be better, but I think
it's only a marginal gain over a statically linked binary: it would
bring some confusion over the purpose of those libraries... Would other
packages be allowed to link against them?

>> ... so we shouldn't use that, generally. I would rather try to check to
>> see if we could sync the packages to make them ABI-compatible.
>
> I'd be interested in the results.

Yeah, I'm not sure I'll get into that now, but I would welcome other
brave souls stepping into this.

I was merely scratching an itch to watch that silly video after all. :)

>> > I have also tried to build http://mpv.io/ with ffmpeg instead of
>> > libav, and I received success in doing tthat as well. Build script is
>> > in the gist as well.
>>
>> Thanks for sharing! That will certainly be useful for others.
>
> It should work for all applications wishing to support FFmpeg, including
> VLC. But the PKG_CONFIG_PATH is really not optimal.

That, and -rpath is designed for private libraries, so I don't think
that could end up in the archive legitimately.

A static link, on the other hand, may have a legitimate purpose.

A.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker


pgpzopn_xQkS4.pgp
Description: PGP signature

Bug#729203: ffmpeg alongside libav

[Timothy Gu]

On Feb 11, 2014 10:27 AM, "Antoine Beaupré"  wrote:
>
> On 2014-02-11 13:04:53, Timothy Gu wrote:
> > I have experimented with the new --enable-rpath configure option of
> > FFmpeg, and found that it is even possible to install shared libraries
> > alongside Libav, without interrupting Libav headers, programs, or
> > libraries. See my gist: https://gist.github.com/TimothyGu/8533059
>

> Hum... isn't that because you install in /usr/local more than -rpath?

I used /usr/local because if I mess up I can delete the installation
completely. But it should work with /usr.

>
> Besides, -rpath is actually a lintian warning:
>
> http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html

The page states that:

The only time a binary or shared library in a Debian package should set
RPATH is if it is linked to private shared libraries in the same package.
In that case, place those private shared libraries in /usr/lib/*package*.

That's exactly what's happening here if we'd like to add the ffmpeg
programs but not use the libraries for other packages. Still, shared
libraries are better than statically linking the ffmpeg programs.

>
> ... so we shouldn't use that, generally. I would rather try to check to
> see if we could sync the packages to make them ABI-compatible.

I'd be interested in the results.

>
> > I have also tried to build http://mpv.io/ with ffmpeg instead of
> > libav, and I received success in doing tthat as well. Build script is
> > in the gist as well.
>
> Thanks for sharing! That will certainly be useful for others.

It should work for all applications wishing to support FFmpeg, including
VLC. But the PKG_CONFIG_PATH is really not optimal.

Timothy

Bug#729203: ffmpeg alongside libav

[Antoine Beaupré]

On 2014-02-11 13:04:53, Timothy Gu wrote:
> I have experimented with the new --enable-rpath configure option of
> FFmpeg, and found that it is even possible to install shared libraries
> alongside Libav, without interrupting Libav headers, programs, or
> libraries. See my gist: https://gist.github.com/TimothyGu/8533059

Hum... isn't that because you install in /usr/local more than -rpath?

Besides, -rpath is actually a lintian warning:

http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html

... so we shouldn't use that, generally. I would rather try to check to
see if we could sync the packages to make them ABI-compatible.

> I have also tried to build http://mpv.io/ with ffmpeg instead of
> libav, and I received success in doing tthat as well. Build script is
> in the gist as well.

Thanks for sharing! That will certainly be useful for others.

A.

-- 
I'm sorry if any of you are catholic. I'm not sorry if you're
offended, I'm actually just sorry by the fact that you're catholic
 - Bill Hicks


pgp0aVZ_09n9i.pgp
Description: PGP signature