Динамически загружать vaapi/vdpau ?

Функции dlopen, dlsym, dlclose - твои друзья в этом деле. Я так cuda подгружал в свой проект, чтобы избежать жёсткой зависимости от её библиотеки.

Это создает проблемы для appimage

А какие там проблемы могут быть? Сами библиотеки libvdpau и libva это такие прослойки совместимости. Приложения могут линковаться к ним явно, а конкретные драйвера загружаются этими прослойками.

Динамическая загрузка прослоек libvdpau и libva нужна только если хочется сделать приложение, которое может работать на системах без установленных libvdpau и libva, но использовать их, если они вдруг есть. Мне кажется, что при упаковке в AppImage достаточно эти библиотеки с собой притащить и не париться.

нужен враппер типа как в Хромуме?

Этот код похож сращивание сишного по своей структуре API libva и основного кода Chromium, который на C++.

Динамическая загрузка прослоек libvdpau и libva нужна только если хочется сделать приложение, которое может работать на системах без установленных libvdpau и libva,

ну как-то так. Все таки как я понимаю ни в каких LSB эти библиотеки не прописаны …

А то у нас уже не один юзер напоролся …. https://lists.cinelerra-gg.org/pipermail/cin/2022-November/005746.html

Возможно, дело в том, что в образе AppImage нет драйверов VDPAU и VA-API, и пользователь должен сам их в основную систему поставить? Теоретически, драйвера для VA-API можно таскать с собой, но вот с драйвером VDPAU от NVIDIA будут проблемы, потому что он, как мне кажется, связан с остальной юзерспейсной частью драйверов NVIDIA. Возможно, он завязан на специфические для конкретных версий интерфейсы ядерной части. Так что там наверняка будет проблема, и таскать с собой драйвер не выйдет.

Если не таскать с собой VA-API драйвера, а надеяться на системные, есть ещё проблема с разными путями в разных дистрибутивах. В Debain они лежат в /usr/lib/x86_64-linux-gnu/dri, рядом с dri драйверами Mesa. В 32-битной версии путь будет /usr/lib/i386-linux-gnu/dri, что простоты не добавляет. В Fedora, кажется, будет /usr/lib64/dri. В общем, особенности.

По идее, можно попробовать пропатчить libvdpau и libva, чтобы они искали драйвера в нескольких местах, и таскать эти пропатченные версии в образе AppImage. Не сказать, чтобы это было концептуально сложно. Но работа по сбору всех возможных путей и проверке на разных дистрибутивах и разном наборе железа будет очень муторной.

По идее, можно попробовать пропатчить libvdpau и libva, чтобы они искали драйвера в нескольких местах, и таскать эти пропатченные версии в образе AppImage

А с учетом того что как минимум libva постоянно допиливают - то нежданчики могут появиться и с совместимостью между двайвером и «независимой» библиотекой..

Интересно, а файерфокс как делает? Линкуется к libva при сборке?

Напишите чуть подробнее как с кудой сделали?

Напишите чуть подробнее как с кудой сделали?

Создал указатели на функции для нужных мне методов куды. Через dlsym по имени функции получил значения указателей. Ну и всё.

typedef CUresult CUDAAPI cuDeviceGet_t(CUdevice *device, int ordinal);

cuDeviceGet_t *cuDeviceGet_ptr {nullptr}; // Значение указателя берём из dlsym

// Теперь в своём коде пользуюсь этой функцией
CUresult cuDeviceGet(CUdevice *device, int ordinal) {
    return cuDeviceGet_ptr(device, ordinal);
}

И так для каждой функции.

нежданчики могут появиться и с совместимостью между двайвером и «независимой» библиотекой

Есть такой момент, да. У драйверов VA-API много раз менялось ABI, а в libva довольно агрессивно отключают старые версии, так что совместимость может внезапно сломаться года через три.

а файерфокс как делает? Линкуется к libva при сборке?

Они сделали библиотеку-прослойку, которая предоставляет те же символы, что и libva. Собственно libva загружается во время работы. Если она есть, то mozva проксирует вызовы в libva, один к одному. Если нет, то mozva вызывает заглушки, которые возвращают коды ошибок.

Поначалу там прямое связывание с libva было, но на сборочных серверах в их стандартных окружениях не было нужной версии libva, поэтому сборка фейлилась. Чтобы хоть как-то собирать, сделали прокладку. И это к лучшему, иначе бинарные сборки Firefox требовали бы установленной libva, причём нужной версии, а такое не везде. Кажется, на Ubuntu 12 была первая версия, а не нужная вторая.

значит надо посмотреть как там сделано, спасибо!