Could the call to ffmpeg private avpriv_mpegaudio_decode_header symbol be replaced to avoid getting tight dependency

The place to discuss linux version of MakeMKV
Post Reply
Message
Author
prahal
Posts: 8
Joined: Wed Mar 13, 2024 12:42 am

Could the call to ffmpeg private avpriv_mpegaudio_decode_header symbol be replaced to avoid getting tight dependency

#1 Post by prahal » Mon Jun 03, 2024 12:15 am

As I reported in viewtopic.php?p=151247#p151247, the use of avpriv_mpegaudio_decode_header in libffabi/src/ffabi.c ffm_mpa_decode_header, make the deb to depends on the full ffmpeg version (ie exactly7:6.1.1-3 hen build against ffmpeg 7:6.1.1-3).
I did not investigate in detail if any of the current ffmpeg callers of this function could be called instead https://ffmpeg.org/doxygen/trunk/mpegau ... 58ca7ac7a9, maybe https://ffmpeg.org/doxygen/trunk/mpegau ... tml#l00120 ff_mpa_decode_header though I believe you did not use it on purpose?
For one ff_mpa_decode_header does not return the layer data, but it returns codec_id instead.

I can only grep calls to ffm_mpa_decode_header in makemkvcon (I cannot check the source to see if it could do with codec_id instead of the layer integer, and it is part of libmakemkv.

flojo
Posts: 109
Joined: Thu Jun 22, 2023 4:27 am
Location: El Paso

Re: Could the call to ffmpeg private avpriv_mpegaudio_decode_header symbol be replaced to avoid getting tight dependency

#2 Post by flojo » Mon Jun 03, 2024 11:57 am

EDIT: I miss understood the actual question so, unless the ffmpeg file is replaced before makemkvcon builds against it, it's pointless. I'm also not sure why it is assumed that only this header routine is what requires full ffmpeg.

avpriv_...() is a getter function while ff_mpa_...() is a (useless?) helper function. Notice that ff_mpa_...() _ALWAYS_ calls avpriv_...(). Also, since you'll already have a "MPADecodeHeader" struct, what's the point of using ff_mpa_...()? Regardless, I'm sure makemkv needs avpriv_...() for some reason, at the very least to test against header error.

You could try to copy the "MPADecodeHeader" struct and array function for your 1-off purpose and see if it works. https://ffmpeg.org/doxygen/trunk/mpegau ... tml#l00035 The array function is just: #define FF_ARRAY_ELEMS ( a ) (sizeof(a) / sizeof((a)[0]))

prahal
Posts: 8
Joined: Wed Mar 13, 2024 12:42 am

Re: Could the call to ffmpeg private avpriv_mpegaudio_decode_header symbol be replaced to avoid getting tight dependency

#3 Post by prahal » Mon Jun 03, 2024 3:25 pm

flojo wrote:
Mon Jun 03, 2024 11:57 am
EDIT: I miss understood the actual question so, unless the ffmpeg file is replaced before makemkvcon builds against it, it's pointless. I'm also not sure why it is assumed that only this header routine is what requires full ffmpeg.

avpriv_...() is a getter function while ff_mpa_...() is a (useless?) helper function. Notice that ff_mpa_...() _ALWAYS_ calls avpriv_...(). Also, since you'll already have a "MPADecodeHeader" struct, what's the point of using ff_mpa_...()? Regardless, I'm sure makemkv needs avpriv_...() for some reason, at the very least to test against header error.

You could try to copy the "MPADecodeHeader" struct and array function for your 1-off purpose and see if it works. https://ffmpeg.org/doxygen/trunk/mpegau ... tml#l00035 The array function is just: #define FF_ARRAY_ELEMS ( a ) (sizeof(a) / sizeof((a)[0]))
The issue I raised is that avpriv_mpegaudio_decode_header is an ffmpeg private symbol, ie not part of the API.
Having it in a ffmpeg header file or calling a function from ffmpeg that itself calls avpriv_mpegaudio_decode_header would not keep the problem as then we would call a public API symbol which is versioned and thus there will not be a tight versioned dependency anymore.

The issue is not that we call a symbol that is part of the full API. It is that this is a private symbol and thus cannot be versioned. So the libmakemkv1 build dependency always ends up being on the full version (major, minor, patch).

Only makemkvcon depends on the libmakemkv function ffm_mpa_decode_header that calls into this private ffmpeg function.
And avpriv_mpegaudio_decode_header is hte only private symbol called from any library in the makekv projet.



NB: note that there is no guarantee that private symbols will be kept even on the next ffmpeg release (though it is unlikely, maybe they could rename it but also unlikely). Thus the tight dependency.

Note the libavcodec60 versioned dependency in

debian/libmakemkv1/DEBIAN/control

with avpriv_mpegaudio_decode_header call removed from libmakemkv libffabi/src/ffabi.c (depends on libavcodec60 major version):

Code: Select all

Package: libmakemkv1
Source: makemkv-oss
Version: 1.17.6+ds-1.4
Architecture: amd64
Maintainer: Ben Westover <me@benthetechguy.net>
Installed-Size: 644
Depends: libavcodec60 (>= 7:6.0), libavutil58 (>= 7:6.0), libc6 (>= 2.33), libexpat1 (>= 2.0.1), libgcc-s1 (>= 3.0), libssl3t64 (>= 3.0.0), libstdc++6 (>= 5), zlib1g (>= 1:1.2.0)
Section: non-free/libs
Priority: optional
Multi-Arch: same
Homepage: https://makemkv.com/
Description: MKV multiplexer library
 MakeMKV's multiplexer library
with avpriv_mpegaudio_decode_header call kept in libmakemkv libffabi/src/ffabi.c (depends on libavcodec60 exact version, including distribution specific bits):

Code: Select all

Package: libmakemkv1
Source: makemkv-oss
Version: 1.17.6+ds-1.4
Architecture: amd64
Maintainer: Ben Westover <me@benthetechguy.net>
Installed-Size: 644
Depends: libavcodec60 (= 7:6.1.1-4+b2), libavutil58 (>= 7:6.0), libc6 (>= 2.33), libexpat1 (>= 2.0.1), libgcc-s1 (>= 3.0), libssl3t64 (>= 3.0.0), libstdc++6 (>= 5), zlib1g (>= 1:1.2.0)
Section: non-free/libs
Priority: optional
Multi-Arch: same
Homepage: https://makemkv.com/
Description: MKV multiplexer library
 MakeMKV's multiplexer library

apt:

Code: Select all

makemkvcon
  Dépend: debconf (>= 0.5)
  Dépend: libc6 (>= 2.4)
  Dépend: libdriveio0 (>= 2.6)
  Dépend: libmakemkv1 (>= 1.17.7)
  Recommande: ccextractor

makemkv
  Dépend: libc6 (>= 2.38)
  Dépend: libgcc-s1 (>= 3.0)
  Dépend: libqt5core5t64 (>= 5.15.1)
  Dépend: libqt5dbus5t64 (>= 5.14.1)
 |Dépend: libqt5gui5t64 (>= 5.2.0~alpha1)
  Dépend: libqt5gui5-gles (>= 5.2.0~alpha1)
  Dépend: libqt5widgets5t64 (>= 5.14.1)
  Dépend: libstdc++6 (>= 11)
  Dépend: zlib1g (>= 1:1.1.4)
  Dépend: makemkvcon

libmakemkv1
  Dépend: libavcodec60 (= 7:6.1.1-4+b1)
  Dépend: libavutil58 (>= 7:6.0)
  Dépend: libc6 (>= 2.33)
  Dépend: libexpat1 (>= 2.0.1)
  Dépend: libgcc-s1 (>= 3.0)
  Dépend: libssl3t64 (>= 3.0.0)
  Dépend: libstdc++6 (>= 5)
  Dépend: zlib1g (>= 1:1.2.0)
unless the ffmpeg file is replaced before makemkvcon builds against it, it's pointless. I'm also not sure why it is assumed that only this header routine is what requires full ffmpeg.
I am totaly lost. Why replace ffmpeg file?
libffabi/src/ffabi.c is the issue and is part of libmakemkv.
And as makemkvcon depends on libmakemkv ffm_mpa_decode_header function itself calling the ffmpeg private symbol avpriv_mpegaudio_decode_header, makemkv will fails to build and run if ffm_mpa_decode_header is removed.
There is no ffmpeg replacment to make. But we need to call only public function of its API to avoid exact version dependency against ffmpeg libraries.
Else if makemkv is to be uploaded to a distrubution it will requires a new upload for every ffmpeg libavcodec upload.

That is there is no "full ffmpeg" issue. ffmpeg private symbols are not part of a "full ffmpeg". They are for internal use inside ffmpeg code. makemkv code should not call them.

Post Reply