linking with system ffmpeg

[Paweł Hajdan, Jr.]

Currently when building with use_system_ffmpeg=1 the Linux distro still has to symlink the ffmpeg libraries to the chrome directory.

I thought it would be cleaner if we just linked to system ffmpeg in that case. Should I expect any problems with that? What parts of code would need to be changed?

[Paweł Hajdan, Jr.]

What do you think about actually linking to system ffmpeg when we use it? Adding some people who probably know the answer. Please see below for full context.

[Andrew Scherkus]

+ajwong

Hrmm I wasn't aware we still had to symlink as we use dlopen() which should find the correct libavcodec/format/util libraries.

I'm not a library loading pro so let me know if I didn't answer your question!

Andrew

[Mark Mentovai]

Paweł Hajdan, Jr. wrote:
> What do you think about actually linking to system ffmpeg when we use it?
> Adding some people who probably know the answer. Please see below for full
> context.

Don’t link against it, just change the path that’s passed to dlopen.
See media::InitializeMediaLibrary(const FilePath&) in
media/base/media_posix.cc. When building with use_system_ffmpeg, put
the path to the system’s ffmpeg library into the map, instead of a
path that refers to module_dir.

Mark

[Evan Martin]

Unfortunately the mapping from file name to path is rather complicated
(consider it depends on ld.so.conf among other things). But on the
bright side I think that requesting the bare filename without a path
will do the right thing in terms of searching the library path.

I think Paweł didn't have enough context to ask the more important
question, which is why there is this strange dlopening etc. business
in the first place, or why the library has a different name than
ffmpeg. In the latter case I can at least imagine it's due to us
adding API, but I am just guessing, as I don't know much about this...

[Mark Mentovai]

Evan Martin wrote:
> Unfortunately the mapping from file name to path is rather complicated
> (consider it depends on ld.so.conf among other things).

According to Paweł, people are just using symbolic links now, which
are far more “static” than you can get with code.

> But on the
> bright side I think that requesting the bare filename without a path
> will do the right thing in terms of searching the library path.

That’s true.

> I think Paweł didn't have enough context to ask the more important
> question, which is why there is this strange dlopening etc. business
> in the first place,

Once upon a time, the ffmpeg components were checked in as binary bits
(as they still are for Windows). In order to not incur a load-time
penalty, the libraries were loaded as needed instead of being linked
against directly.

I never liked checked-in binary components, and apparently Albert
didn’t either, because he improved matters by transitioning Mac and
Linux to building ffmpeg from source.

Personally, I’d prefer if it were just linked right in statically, but
I suspect that there’s a license-type concern based on someone’s [ed.:
FSF’s flawed] interpretation of the GPL and understanding of linking.

> or why the library has a different name than
> ffmpeg.

Originally, in the checked-in binary world, there were three
libraries: libavcodec, libavformat, and libavutil. Now that they’re
built from source, the independent pieces are built into a single
library. It’s an amalgamation of these three components smushed
together, so it’s big. That makes it a “sumo.”

http://codereview.chromium.org/300013 is where most of the magic
happened. It was a wild ride.

Mark

[Paweł Hajdan, Jr.]

On Tue, Jul 20, 2010 at 18:44, Andrew Scherkus <sche...@chromium.org> wrote:

+ajwong

Hrmm I wasn't aware we still had to symlink as we use dlopen() which should find the correct libavcodec/format/util libraries.

I just checked again and on Gentoo the symlinks are still necessary. After removing them HTML5 video stops to work. 

[Paweł Hajdan, Jr.]

Okay, that's quite easy to do. Like below:

paths[module].push_back(FilePath("/usr/lib").Append(GetDSOName(module)).value());

But then in GetDSOName the version number of ffmpeg is hardcoded at compile time. If we link dynamically to the ffmpeg libraries, this is going to break very early, and we'll know that the package needs to be rebuilt. Gentoo has a tool to do that automatically, it's called revdep-rebuild.

On the other hand, when we use dlopen, and ffmpeg version number changes, it's going to break silently.

Is there some other solution, like using dlopen but without hardcoded version number?

[Albert J. Wong (王重傑)]

We use a hard-coded version number because ffmpeg has a tendency to break binary compatibility whenever that changes.  Indeed..sometimes they break binary compatibility within a version, but it's less often.

I don't think it'd be correct to work against any version of the dso.  Even if we were linking directly, we would probably want to specify the major version number there as well.

-Albert

[Paweł Hajdan, Jr.]

Right, this means using dlopen without hardcoded version number is not an option.

However, why not link directly (only when use_system_ffmpeg=1, which AFAIK is only used by Linux distros, and not our test infrastructure)? This way automated tools in Gentoo will catch the breakage very quickly, instead of the user noticing that his audio/video has stopped working. Please remember that Gentoo is a from-source distro, which means that breaking binary compatibility is not an issue there, as long as we can catch the breakage early.

[Albert J. Wong (王重傑)]

Talked with Pawel off-thread about various options.  The summary is that there doesn't seem to be a way in portange to force a rebuild of Chromium based on an new emerge of ffmpeg other than getting the ffmpeg libraries into the ldd output for chromium.  So, barring adding/finding this functionality in portage somehow, we're left with trying to get a the libraries directly into the link line.

The issue with switching everything over to direct linking wholesale is that on a Google Chrome distribution, we'd have problems packing our own ffmpeg w/o using either -rpath or LD_LIBRARY_PATH.  So, we still need/want to preserve the dlopen logic.

Given these constraints, Pawel is going to try to patch the gyp and source so that when using_system_ffmpeg is enabled, we disable the dlopen code-path and get libavcodec, libavutil, and libavformat into the link line directly.  Assuming this can be kept fairly self contained, it seems like the best compromise.

If anyone's got a cleaner suggestion, please speak up!

-Albert

[Evan Martin]

We have a precedent for this in how we use libgnome-keyring. For
Google Chrome we don't want to depend on the library so we do a bunch
of dlopen magic; for normal builds you can just detect if it's
available and use it directly.

See #ifdefs in
chrome/browser/password_manager/native_backend_gnome_x.cc
We basically simulate the world as if we had linked to it directly in
the dlopen case, so the majority of the code is written the same.

On Mon, Jul 26, 2010 at 11:25 AM, Albert J. Wong (王重傑)

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>