From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 8647D4390F for ; Wed, 3 Aug 2022 13:17:18 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4967168B7F0; Wed, 3 Aug 2022 16:17:16 +0300 (EEST) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 543C068B697 for ; Wed, 3 Aug 2022 16:17:09 +0300 (EEST) Received: by mail-qk1-f170.google.com with SMTP id m22so489492qkm.12 for ; Wed, 03 Aug 2022 06:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=FOaQ4mty7GA2GqDeMMDjr8YJM7Tb3h+0F/g7i51RjQA=; b=WkqSuzVjBgHvL9Kb5tpSkhIYsInXNc4el0BLXKTsoE01E3puKhMshEFuM6nNPOVuJL A4WejBJx8FOqeU4daCo6VG/o0yOHPsKRZ+Q4+ANRK0MXOuDwYb2er17L7kbNw9+XB2Ez J3iTEmvG7/TNq3YvB6MHhwpAeL30j7wyGhnZ5cAY6u1lr/s4IuK3kvrwCXamRubu2Yvk LJfNl215cIrLFW9j5yQMY/hjggFXYODc/UNlGhO6h1frOSkq7zi/97ly4XaJb2k4EhTC FbkA36W6c7tUtY+5dmdC+u2xckeZkCPMsgAbMyiRM3gvVp4hfhzN4laOPf54cLF1csYh enxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=FOaQ4mty7GA2GqDeMMDjr8YJM7Tb3h+0F/g7i51RjQA=; b=u0z21zCf1OsiakHeXQVLPIrjhwETytImYBRIS8iRCcUt2dqJvQgfWe3yI2tUHlez3w xcAsljLS2t/f1RVR1vu6lzuUUXJqTr+Sa3Oq7qOWJbfFd3J3yHHZ66BYX3yABtRsfXWw qhhSQ6EEmbCPQsOE1Dsd1LqC2Fd168LFKRb9a5NC1K3d6Sbaes8KN+90rPCvWk6N7kQJ DXjlxxyLvEgWjk8UQ/8dWclI9LMetH3ZGeKkI2jFwEpqmlKWnkE+1WHa5Ed4HdA9/qXU 8dNx7r2exJCm75HitU602CQ9MhiRkHx56X8t22Hcc8E2sW9at82dfN523xfoCNuqnVIx 5vXA== X-Gm-Message-State: AJIora/HbmqzgHM1O79cQSERQCCzA+MzZLCSuyUCdYto4tv7S80Ao639 nMfZbYprTKmuqmi6XRaS3k6fKwJ6CjBOUAyf9vIZkAxqX0iSDA== X-Google-Smtp-Source: AGRyM1vWIget8KLkCmwx6owx7ZdPUVoTtMVDgmWBMZIg6CJ5PrjrfRk8IaP6uRMDH6d3jgNo5E6IK2KxjCEXqWSKQ1U= X-Received: by 2002:a05:620a:2947:b0:6b6:5e7:d609 with SMTP id n7-20020a05620a294700b006b605e7d609mr17107815qkp.366.1659532627404; Wed, 03 Aug 2022 06:17:07 -0700 (PDT) MIME-Version: 1.0 References: <20220719175310.647621-1-emil.l.velikov@gmail.com> In-Reply-To: From: Emil Velikov Date: Wed, 3 Aug 2022 14:16:56 +0100 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v2 0/3] hwcontext_vaapi: dlopen libva-x11 and libva-drm X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Wed, 27 Jul 2022 at 20:51, Emil Velikov wrote: > > On Thu, 21 Jul 2022 at 21:47, Mark Thompson wrote: > > > > On 20/07/2022 17:41, Emil Velikov wrote: > > > On Tue, 19 Jul 2022 at 19:16, Nicolas George 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-request@ffmpeg.org with subject "unsubscribe".