Bug#790446: mpv: Warning about mismatch between build and run-time ffmpeg libraries
andreas.cadhalpun at googlemail.com
Tue Jul 7 20:19:18 UTC 2015
On 07.07.2015 17:26, Alessandro Ghedini wrote:
> On mer, lug 01, 2015 at 10:35:13 +0200, Andreas Cadhalpun wrote:
>> I've investigated this a bit more and it seems that the only potentially
>> problematic FFmpeg-only API used by mpv is AVFrame->metadata, which mpv
>> accesses via av_frame_get_metadata. 
>> Thus I think the comment is just wrong and the warning should be removed.
> If I understand the comment correctly, the problem isn't so much ffmpeg-only
> APIs like ->metadata, but the fact that mpv doesn't use accessor functions for
> struct fields provided by ffmpeg to maintain ABI compatibility because libav
> doesn't have those functions (but it still has the structs).
That wouldn't make much sense. If it is safe to access a struct member in Libav,
it is also safe to access it in FFmpeg. In that case there is no need for
accessor functions. These are either also necessary (and present) in Libav,
or it is an FFmpeg-only API like AVFrame->metadata.
> IMO the warning can be removed in the Debian packages because it's fairly
> annoying and mostly useless (it's not like Debian users can do anything about
> it besides recompiling the package), but maybe we should better investigate
> this alleged ABI compatibility problem in ffmpeg.
These changes in private ABI are well-known and caused by merges from Libav:
In FFmpeg some structs have more members than in Libav. If there is a new
member added at the end of the struct in Libav, it is inserted in the middle
of the struct in FFmpeg. Thus all FFmpeg-only struct members must never be
accessed directly. (This is documented very clearly.)
> For example the upstream-tracker thingy shows several ABI changes introduced in
> ffmpeg 2.5 (e.g. new fields in the middle of structs) without a SONAME bump:
Yes, e.g. the framerate and initial_padding members were added to the end
of AVCodecContext in Libav and merged into FFmpeg between 2.4 and 2.5.
> The mpv Debian package could also start using the accessors that ffmpeg
> provides but only when built with ffmpeg
It already does exactly that! ;)
> (which should hopefully become the
> default soonish), but tracking down where these accessors should be used is
> probably going to be a bit of a pain.
Since this only affects FFmpeg-only struct members and mpv is also compatible
with Libav, thus using ifdeffery for FFmpeg-only functionality, finding the
potentially problematic case(s) is not that hard.
There is only AVFrame->metadata, which is accessed correctly.
More information about the pkg-multimedia-maintainers