Bug#790446: mpv: Warning about mismatch between build and run-time ffmpeg libraries

[Andreas Cadhalpun]

Hi Guillem,

On 30.06.2015 21:40, Guillem Jover wrote:
> On Mon, 2015-06-29 at 21:45:26 +0200, Andreas Cadhalpun wrote:
>> (We plan to transition all packages from Libav to FFmpeg soon, see [1].)
> 
> Yeah, I'm aware, eagerly waiting it!

:)

>> On 29.06.2015 18:01, Guillem Jover wrote:
>> I guess this warning is meant as sanity check for those compiling mpv themselves.
>> (The ffmpeg binary also checks for matching compile-time and run-time libraries.)
>> These warnings aren't very useful in a distribution, where package dependencies
>> ensure ABI compatibility.
> 
> Perhaps, but the comment at
> <http://sources.debian.net/src/mpv/0.9.2-1%2Bffmpeg/common/av_log.c/#L229>
> was not very soothing, so that was one additional reason for the bug. :)

Hmm, this comment is indeed a bit worrisome.
But I'm not sure I understand the reasoning given there. As far as I know
the accessor functions are only necessary for API that is not present
in Libav (in order to be ABI compatible after Libav merges, as the comment
says). So whether or not one uses the accessors shouldn't make a difference
for compatibility with Libav.

>>> Which, to me points out there's a problem somewhere. Either:
>>>
>>>  * the warning is bogus, and
>>>    - mpv should be silenced in common/av_log.c:print_libav_versions, or
>>
>> If the warning bothers you, this would be the way to go.
> 
> It's not so much that it bothers me; as I've mentioned, either the
> warning is valid and there's a potential ABI problem, or it is not
> and then emitting an alarming message that the user can hardly fix
> on each invocation might be slightly taxing, it is at least a sure
> way to train users to ignore valid ones. :)

Indeed. In this case clarifying with upstream what this warning means,
i.e. which accessors are not used, would be good.

>>>    - ffmpeg should not be exposing the minor versions in its macros
>>>      and *_version() functions, so that such warnings do not trigger, or
>>
>> The minor versions are used to e.g. indicate new features, so that programs
>> can do exact compile-time checks. Not exposing them would break that.
> 
> How does the libav project handle this?

Identically.

> I don't remember seeing such warning with an mpv compiled against that.

The Libav project has only made new releases about once a year, usually
with a SONAME bump, so that mpv got recompiled.
A binNMU would make the warning go away.

>>>  * the warning is valid, and
>>>    - mpv needs a strict versioned dependency, or
>>
>> The dependencies are calculated by the symbols mechanism.
> 
> Sure.
> 
>> No stricter dependencies should be necessary.
> 
> In principle, but I was going by the comment on that source file. Sorry,
> I should have provided a direct link initially.

Yes, that comment is important.

>>>    - mpv very unfortunately needs to statically link against ffmpeg, or
>>
>> Not that, please!
> 
> Well, I abhor such kind of solutions with a passion, but if there's no
> better option…

The better solution would be to use the API as documented, i.e. with the
accessor functions.
In particular because I don't see a reason not to do that.

Best regards,
Andreas