On Wed, 27 Jul 2022 at 20:51, Emil Velikov <emil.l.veli...@gmail.com> wrote: > > On Thu, 21 Jul 2022 at 21:47, Mark Thompson <s...@jkqxz.net> wrote: > > > > On 20/07/2022 17:41, Emil Velikov wrote: > > > On Tue, 19 Jul 2022 at 19:16, Nicolas George <geo...@nsup.org> wrote: > > >> > > >> Emil Velikov (12022-07-19): > > >>> As you may know the libva* set of libraries share an internal ABI > > >>> between them. In a resent libva commit, the va_fool API was removed. > > >>> > > >>> Thus if one is to mix different versions of libva.so and libva-x11.so > > >>> they will get an error, leading to a crash of the whole stack. > > >>> > > >>> The simple solution is > > >> > > >> ... a configure check. > > >> > > >> If the person who installs replaces a library with another, it is their > > >> responsibility to check they are compatible. > > >> > > > > > > While I wholeheartedly agree, it's not so easy to enforce compile time > > > decisions at runtime. In the past, I have debugged and reported issues > > > where Linux distributions do not enforce the above. > > > > > > We do have the typical Linux distribution model (where we have dozens > > > upon distros) and other distribution models. IMHO checking each > > > instance and combination doesn't scale. We could bring awareness to > > > the issue in say distribution/workflow X, which sadly may come as > > > finger-pointing and thus alienating. > > > > > > Hope that makes sense and the team is willing to consider the extra 90 > > > lines worth of code. > > > > The argument "libfoo can be broken in some particular configuration, so > > lets use dlopen() to make errors happen later" seems like it applies to > > every library. Why is this case so special? Who are the users running > > into this specific problem and who are stuck with broken versions they > > can't update? > > > It's a long story, hope I don't bore you to death :-P > > Even though I've been itching to hack on ffmpeg for a while, the bug > that allowed me to do that is > https://github.com/ValveSoftware/steam-for-linux/issues/8673 > > As a background, steam as well as some of the programs/games shipped > use libraries provided by ffmpeg. In addition, steam ships with a > steam runtime, which is effectively a partial chroot of an old Ubuntu. > For various compatibility reasons, one cannot simply update it, so the > startup scripting will try and promote a set of the host libraries (if > newer) so that they're used instead of the bundled Ubuntu ones. > > What happens in the libva case is that distributions can provide only > libva.so and omit libva-x11.so. Which due to the internal ABI break > (removal of the va_fool API), means that steam and likely some games > will simply crash out. > > Now let me try and draw an analogy to another set of libraries which > also share internal ABI - libdrm.so, libdrm_nouveau.so, > libdrm_amdgpu.so libdrm_intel.so, etc. To the best of my knowledge > there was no breakage in there be that internal or public ABI. > > In addition, while distribution may allow you to install only some > (say libdrm.so without libdrm_intel.so), a pair of those is pulled by > the respective GL and Vulkan drivers. For example: the amdgpu GL > driver (amdgpu_dri.so) and radv Vulkand driver (libvulkan_radeon.so) > depend on libdrm_amdgpu.so and libdrm.so. Hence, in practical terms > users cannot hit a similar issue... unless they very very deliberately > try to do so. > > So while one solution is to go around telling users and distributions > that they're "doing it wrong", IMHO a more pragmatic solution is to > include this brief workaround in ffmpeg. At least in the short to mid > term. > As mentioned in the cover letter (sorry again for sending the series > multiple times), I have some plans for a proper long term, which would > reside in libva. Alas as you have experienced yourself, the libva > maintainers can be rather busy, so we're looking at least a couple of > months until a new libva release is out and further X months, until it > ripples down to end-users. >
Mark, humble ping? Can you kindly let me know if the above argument seems reasonable and more importantly if it even makes sense. I am more than happy to provide more details and elaborate, if anything is unclear. Thanks Emil _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
