[FFmpeg-devel] [PATCH] build: Allow libffmpeg to be built for Chromium-based browsers

[Reimar Döffinger]

On 29.07.2017, at 01:05, Ivan Kalvachev <ikalvachev at gmail.com> wrote:

> On 7/29/17, Dominik 'Rathann' Mierzejewski <dominik at greysector.net> wrote:
>> On Saturday, 29 July 2017 at 00:20, Hendrik Leppkes wrote:
>>> On Fri, Jul 28, 2017 at 12:07 PM, James Le Cuirot <chewi at gentoo.org>
>>> wrote:
>> [...]
>>>> This Makefile snippet allows libffmpeg to be created without the help
>>>> of Chromium's build system. It uses the CONFIG_SHARED variable to
>>>> decide whether to link the FFmpeg libraries statically or
>>>> dynamically. In the latter case, libffmpeg is just a wrapper with no
>>>> symbols of its own.
>> [...]
>>> I don't think ffmpeg is the right place to maintain special makefiles
>>> for Chromium.
>> 
>> I concur. Instead, Chromium should be fixed to link against individual
>> FFmpeg libraries properly.
> 
> To be honest, I do not find the combined library such a bad idea.

I think it is, or at least this approach is.
If nothing else, it does not allow using the same libraries as the system or other programs use.
It seems to me a better approach would be to make such a libffmpeg an actual wrapper that just passes all the function calls through.

> For example, if you have to dlopen ffmpeg libs, it takes a lot of care
> to load all the interlinked libraries in the correct order.

I don't see why? The order should not matter.

> And imagine the fun if you have multiple versions installed.

Unless you mean you need to know which major versions fit together?
That seems like a valid point, but would also be solved by such a "wrapper" without needing to duplicate all the code, which also risks causing a mess if a program loads libffmpeg but also a library that loads libavcodec in turn, you couldn't predict which one actually gets used.
Also a problem for a wrapper, wouldn't want to create an endless loop of the wrapper calling itself...