| Summary: | Chromium GPU-accelerated video decoding and encoding on Intel, AMD and Nvidia | ||
|---|---|---|---|
| Product: | [ROSA-based products] ROSA Fresh | Reporter: | Mikhail Novosyolov <m.novosyolov> |
| Component: | Packages from Main | Assignee: | ROSA Linux Bugs <bugs> |
| Status: | VERIFIED FIXED | QA Contact: | ROSA Linux Bugs <bugs> |
| Severity: | normal | ||
| Priority: | Normal | CC: | alzim, andrey.bondrov, eugene.shatokhin, v.potapov, victorr2007 |
| Version: | unspecified | Flags: | v.potapov:
qa_verified+
andrey.bondrov: published+ |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Platform: | --- | ROSA Vulnerability identifier: | |
| RPM Package: | chromium-browser-stable | ISO-related: | |
| Bad POT generating: | Upstream: | ||
|
Description
Mikhail Novosyolov
2018-01-13 02:29:23 MSK
also update libva and livba-utils chrome://media-internals - to see if the GU decoder is used For reference, ALT's bug: https://bugzilla.altlinux.org/show_bug.cgi?id=34452 Собрал я Хромиум с поддержкой VA-API, но не проверял, ибо не на чем. Updated libva to 1.7.3 https://abf.io/build_lists/2917932 https://abf.io/build_lists/2917933 chromium-browser-stable 63.0.3239.132-2 https://abf.io/build_lists/2917938 https://abf.io/build_lists/2917939 Please, update libva to 1.8.3 Да. Работает. Может, попробовать в Chromium 64 включить chrome://flags/#enable-accelerated-video (VA-API) по умолчанию, а lib64va1 поставить в зависимость пакета chromium-browser-stable? И еще можно включить в стандартную поставку Chromium расширение h264ify, регрессов не должно дать, т.к. h264 у всех проигрывается, vp9 тоже, но во многих местах, например, у меня, vp9 не декодируется аппаратно. C h264ify предложение спорное. Для мощных процессоров эффект почти незаметен, т.к. программное декодирование там не вызывает проблем, на слабых, как мой Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz * 4 ядра разница заметна, без аппаратного декодирования FullHD видео на Youtube сложно смотреть, подвисания, пропуск кадров и пр. при периодически 100% загрузке процессора, а с ним нормально. (In reply to comment #6) > Да. Работает. Спасибо за проверку. (In reply to comment #6) > Может, попробовать в Chromium 64 включить > chrome://flags/#enable-accelerated-video (VA-API) по умолчанию, а lib64va1 > поставить в зависимость пакета chromium-browser-stable? Думаю, в этом нет серьёзной необходимости. Не у всех карточки intel и очень мало кто умеет всё это настраивать. А те, кто разбираются в этом и кому это нужно, сами легко добавят необходимую опцию. The upodate is sent to expanded testing **************************************** > Думаю, в этом нет серьёзной необходимости. Мне кажется, что есть. Потому что сейчас из-за курса рубля и доллара продается очень много дешевых ноутбуков с полутелефонным железом, т.е. с очень слабыми процессорами Intel 1.44-1.8 ГГц, видел ноутбук с 1.8 ГГц и 4 ядрами, там нормально приогрывается видео и без декодирования видеокартой, а вот на более слабых наверняка, как у меня, без аппаратного ускорения будут проблемы с просмотром видео. > и очень мало кто умеет всё это настраивать Поэтому это +1 аргумент в сторону включения по умолчанию, т.к. очень мало кто из тех, у кого будут проблемы, догадается до такого, а в интернете тема слабо освещена, не нагуглить просто так. Однако, если тестирование на ноутбуках с процессорами Интел 1.66 ГГц покажет, что там программно видео нормально декодируется, то тогда вы правы. Михаил, а Вы можете в подробностях описать как настроить, чтобы это работало? Народ не может разобраться. И я хочу собрать всю информацию и добавить в вики Росы. 0) заходим на Youtube, проигрываем видео, фиксируем нагрузку на процессор. Обратите внимание, что в начале проигрывания нагрузка обычно максимальна, затем "устаканивается". Также, если окно браузера свернуто или полностью перекрыто другим окном, Chromium прекращает рендеринг видео, декодируя только звук (chrome://flags/#disable-background-video-track), соответственно, не нужно разворачивать монитор процессов на весь экран. 1) # urpmi libva-utils $ vainfo В выводе должны быть H264 и/или VP9 2) если в выводе vainfo есть vp9, то переходим к п. 4, если есть H264, но нет VP9, то к пункту 3, иначе завершаем работу 3) ставим патченный Chromium 4) ставим расширение h264ify (https://github.com/erkserkserks/h264ify), чтобы на YouTube принудительно использовать H264 вместо VP9, если нет поддержки аппаратного декодирования VP9 5) в Chromium идем по адресу chrome://flags (в адресной строке), нажимаем Ctrl+F и находим: "Hardware-accelerated video Hardware-accelerated video where VA-API driver is installed on thesystem. – Linux #enable-accelerated-video" Для упрощения в дальнейшем к этот флаг будем называться как chrome://flags/#enable-accelerated-video 6) включаем chrome://flags/#enable-accelerated-video (Enable, кнопка справа от него должна стать синей). Соглашаемся на перезапуск браузера. 7) заходим на YouTube и запускаем проигрывание видео 8) заходим в chrome://media-internals/ и нажимаем на текущий плеер YouTube. Если в декодировании участвует видеокарта, то в строке Video Decoder должно быть написано GpuVideoDecoder, а средняя "устаканившаяся" нагрузка на процессор должна стать меньше. Обратите внимание, что сравнивать нужно на одном и том же видео в одном и том же разрешении (1920*1080, 720p и т.д.). Если декодируется процессором, то будет FFmpegVideoDecoder. Не путать с декодером аудио, там всегда FFmpeg. Также при аппаратном декодировании ps aux | grep chrom | grep gpu должно выдать соответствующий процесс, находящийся в топе по нагрузке на процессор (его можно легко увидеть глазами в htop). Работа над апстримизацией поддержки VA-API здесь: https://bugs.chromium.org/p/chromium/issues/detail?id=137247 https://chromium-review.googlesource.com/c/chromium/src/+/532294 По емейлам @intel.com видно, что это разрабатывается в первую очередь для Интела, в т.ч. для Хромбуков. Использование VA-API в Линуксе в целом неплохо описано здесь: https://wiki.ubuntu.com/IntelQuickSyncVideo На Wayland в Chromium, описанное, судя по всему, временно не работает: https://bugzilla.altlinux.org/show_bug.cgi?id=34452#c4 Другие API аппаратного ускорения проигрывания видео Chromium не поддерживает. Например, не поддерживает VDPAU, которое когда-то было разработано Nvidia для своих проприетарных драйверов, а сейчас поддерживается в т.ч. в Mesa для AMD Radeon. Однако Nvidia забросили его развитие и ведут работу по переводу FFmpeg, Gstreamer на NVENC. nvidia-304 и ниже не поддерживают VDPAU. ------------------- Что касается Nvidia (разумеется, речь о проприетарных драйверах). VA-API напрямую они не поддерживают, однако есть транслятор из VA-API в VDPAU, и в Росе он опакечен (https://abf.io/import/vaapi-driver-vdpau/blob/rosa2016.1/vaapi-driver-vdpau.spec), # urpmi vaapi-driver-vdpau В теории благодаря этой прослойке описанное аппаратное ускорение через VA-API должно работать в Chromium на Nvidia >=340. У меня нет Nvidia, чтобы разобраться. В Арче в AUR есть вот такой пакет: https://aur.archlinux.org/packages/libva-vdpau-driver-chromium/ В комментариях кто-то утверждает, что это работает. В чем отличие от libva-vdpau-driver, пока не понял. Спек здесь: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=libva-vdpau-driver-chromium Ffmpeg поддерживает VDPAU, не знаю, при обычном декодировании Хромиумом через FFmpeg, может ли оно быть задействовано. У меня AMD R3 amdgpu интеграшка, с ней думаю поковыряться, просто так GpuVideoDecoder не хочет работать, хотя vainfo рапортует о поддержке H264 (но там и программным декодированием нет проблем). mpv хорошо поддерживает vdpau, VA-API и прочие методы аппаратного ускорения, можно его запускать через консоль и смотреть на вывод в консоль, где он пишет об используемом методе декодирования. И таки да, libva надо обновить до 1.8.3 для чистоты экспериментов. Вот здесь вконтакте пытался вытрясти из людей обратную связь по этой теме: https://vk.com/rosa_linux?w=wall-33847957_232210 Если что, с недавнего времени по моей наводке hw-probe в базу собирает vainfo (пакет hw-probe пока не зависит от libva-utils и множества недавно добавленных утилит). Можно по пробам оборудования смотреть нужную информацию. (In reply to comment #14) > И таки да, libva надо обновить до 1.8.3 для чистоты экспериментов. Advisory: "Update libva to new version 1.8.3" https://abf.rosalinux.ru/build_lists/2918707 https://abf.rosalinux.ru/build_lists/2918708 Advisory: "Split libva-utils from libva package (since version 1.8.3)" https://abf.rosalinux.ru/build_lists/2918709 https://abf.rosalinux.ru/build_lists/2918710 Advisory: "Update vaapi-driver-intel to new version 1.8.3" https://abf.rosalinux.ru/build_lists/2918724 https://abf.rosalinux.ru/build_lists/2918725 $ chromium-browser [16816:16816:0923/011826.836128:ERROR:vaapi_wrapper.cc(1222)] This build of Chromium requires VA-API version 0.39, system version: 0.40 Отвалилось. Нужно перекомпилировать Хромиум с новыми заголовочными файлами. А как бы еще добиться того, чтобы в качестве зависимости собранного Хромиума автоматически жестко прописывалась версия libva1, в которой он собирался? (In reply to comment #20) > А как бы еще добиться того, чтобы в качестве зависимости собранного Хромиума > автоматически жестко прописывалась версия libva1, в которой он собирался? Жёсткая привязка не всегда нужна, т.к. не с каждой новой версией libva меняется значение VA-API. Теоретически, можно пойти по пути sip: https://abf.rosalinux.ru/import/python-sip/blob/rosa2016.1/python-sip.spec#lc-3 Получается, да, нужно следить за тем, какую версию va-api предоставляет каждая версия libva. Chromium пересоберете? Или, если я его к себе склонирую и сам пересоберу, те новые версии libva подхватятся? (In reply to comment #22) > Получается, да, нужно следить за тем, какую версию va-api предоставляет > каждая версия libva. > Chromium пересоберете? Или, если я его к себе склонирую и сам пересоберу, те > новые версии libva подхватятся? Чтоб новые версии подхватились, нужно при сборке добавить контейнеры с ними. Автоматом только репы подхватываются и то, только те, где галочка стоит. (In reply to comment #17) > (In reply to comment #14) > > И таки да, libva надо обновить до 1.8.3 для чистоты экспериментов. > > Advisory: "Update libva to new version 1.8.3" > > https://abf.rosalinux.ru/build_lists/2918707 > https://abf.rosalinux.ru/build_lists/2918708 > > Advisory: "Split libva-utils from libva package (since version 1.8.3)" > > https://abf.rosalinux.ru/build_lists/2918709 > https://abf.rosalinux.ru/build_lists/2918710 (In reply to comment #18) > Advisory: "Update vaapi-driver-intel to new version 1.8.3" > https://abf.rosalinux.ru/build_lists/2918724 > https://abf.rosalinux.ru/build_lists/2918725 Пересобрал Хромиум с новыми версиями https://abf.io/build_lists/2919117 https://abf.io/build_lists/2919118 Работает! (только уже Хромиум 64 вышел)) (In reply to comment #25) > Работает! > (только уже Хромиум 64 вышел)) Это будет через неделю)) (In reply to comment #12) > Что касается Nvidia (разумеется, речь о проприетарных драйверах). VA-API > напрямую они не поддерживают, однако есть транслятор из VA-API в VDPAU, и в > Росе он опакечен > (https://abf.io/import/vaapi-driver-vdpau/blob/rosa2016.1/vaapi-driver-vdpau. > spec), > # urpmi vaapi-driver-vdpau У меня даже на nouveau ускорение включилось, vaapi-driver-vdpau у нас в R10 входит в образ, только 1) Похоже, нужно бы его тоже пересобрать с новым vaapi, он старую версию API использует vainfo libva info: VA-API version 0.40.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_0_38 libva info: va_openDriver() returns 0 2) Он не находит либу, нужно добавить симлинк ln -s vdpau_drv_video.so nouveau_drv_video.so у (In reply to comment #27) > 2) Он не находит либу, нужно добавить симлинк > ln -s vdpau_drv_video.so nouveau_drv_video.so С этим надо осторожно. Может через alternatives делать, если для проприетарных драйверов тоже актуально (или ещё каких-то не-nouveau). (In reply to comment #29) > (In reply to comment #27) > > 2) Он не находит либу, нужно добавить симлинк > > ln -s vdpau_drv_video.so nouveau_drv_video.so > > С этим надо осторожно. Может через alternatives делать, если для > проприетарных драйверов тоже актуально (или ещё каких-то не-nouveau). ну, я проверил, поставив проприетарные драйвера нвидия - сработало нормально. (In reply to comment #29) > (In reply to comment #27) > > 2) Он не находит либу, нужно добавить симлинк > > ln -s vdpau_drv_video.so nouveau_drv_video.so > > С этим надо осторожно. Может через alternatives делать, если для > проприетарных драйверов тоже актуально (или ещё каких-то не-nouveau). Не-nouveau вряд ли будут содержать файл с "nouveau" в имени. (In reply to comment #27) > У меня даже на nouveau ускорение включилось В плеерах или именно в Chromium? (In reply to comment #31) > (In reply to comment #29) > > (In reply to comment #27) > > > 2) Он не находит либу, нужно добавить симлинк > > > ln -s vdpau_drv_video.so nouveau_drv_video.so > > > > С этим надо осторожно. Может через alternatives делать, если для > > проприетарных драйверов тоже актуально (или ещё каких-то не-nouveau). > > Не-nouveau вряд ли будут содержать файл с "nouveau" в имени. Точно. Yевнимательно посмотрел, из чего на что симлинк создаётся :-) Надо аккуратнее с этими симлинками. Посмотрел, в Ubuntu нет vdpau_drv_video.so, но nouveau_drv_video.so есть, не является симлинком и принадлежит пакету mesa-va-drivers. Чтобы не получилось так, что какое-нибудь приложение, например, плеер, будет пытаться вызвать nouveau_drv_video.so, а по факту вызывать vdpau_drv_video.so, получать неожиданный результат и падать. Не знаю, чем эти 2 библиотеки отличаются. Но ldd при убунтовской схеме пакетирования одинаковый, поэтому вероятность подобного неожиданного овтета, наверное, минимальная. root@pay2:/tmp# ldd /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so linux-vdso.so.1 => (0x00007ffff8fa1000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f037a13c000) libsensors.so.4 => /usr/lib/x86_64-linux-gnu/libsensors.so.4 (0x00007f0379f2d000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0379d0e000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0379b0a000) libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f0379905000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f0379703000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f03794dc000) libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f03792d9000) libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007f03790d1000) libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f0378ece000) libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f0378cc7000) libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f0378ac4000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f0378899000) libdrm_nouveau.so.2 => /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (0x00007f0378691000) libdrm_radeon.so.1 => /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1 (0x00007f0378485000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f0378274000) libdrm_amdgpu.so.1 => /usr/lib/x86_64-linux-gnu/libdrm_amdgpu.so.1 (0x00007f037806b000) libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f0377e51000) libLLVM-5.0.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1 (0x00007f0374849000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f03744c3000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f037416d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0373d8d000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0373b76000) /lib64/ld-linux-x86-64.so.2 (0x00007f037ab7c000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f0373972000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f037376c000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f0373564000) libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007f037332d000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f0373104000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f0372eef000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0372ce7000) root@pay2:/tmp# ls /usr/lib/x86_64-linux-gnu/dri/ -la итого 143264 drwxr-xr-x 1 root root 504 фев 7 13:05 . drwxr-xr-x 1 root root 232640 фев 8 14:39 .. -rw-r--r-- 5 root root 8600376 янв 17 18:34 i915_dri.so -rw-r--r-- 5 root root 8600376 янв 17 18:34 i965_dri.so -rw-r--r-- 1 root root 4247176 авг 2 2017 i965_drv_video.so -rw-r--r-- 8 root root 10713256 янв 17 18:34 kms_swrast_dri.so -rw-r--r-- 8 root root 10713256 янв 17 18:34 nouveau_dri.so -rw-r--r-- 3 root root 4573032 янв 17 18:34 nouveau_drv_video.so -rw-r--r-- 5 root root 8600376 янв 17 18:34 nouveau_vieux_dri.so -rw-r--r-- 5 root root 8600376 янв 17 18:34 r200_dri.so -rw-r--r-- 8 root root 10713256 янв 17 18:34 r300_dri.so -rw-r--r-- 8 root root 10713256 янв 17 18:34 r600_dri.so -rw-r--r-- 3 root root 4573032 янв 17 18:34 r600_drv_video.so -rw-r--r-- 5 root root 8600376 янв 17 18:34 radeon_dri.so -rw-r--r-- 8 root root 10713256 янв 17 18:34 radeonsi_dri.so -rw-r--r-- 3 root root 4573032 янв 17 18:34 radeonsi_drv_video.so -rw-r--r-- 8 root root 10713256 янв 17 18:34 swrast_dri.so -rw-r--r-- 8 root root 10713256 янв 17 18:34 virtio_gpu_dri.so -rw-r--r-- 8 root root 10713256 янв 17 18:34 vmwgfx_dri.so root@pay2:/tmp# ldd /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so linux-vdso.so.1 => (0x00007ffed90ce000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcea9d0d000) libsensors.so.4 => /usr/lib/x86_64-linux-gnu/libsensors.so.4 (0x00007fcea9afe000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcea98df000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcea96db000) libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007fcea94d6000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007fcea92d4000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fcea90ad000) libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007fcea8eaa000) libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007fcea8ca2000) libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007fcea8a9f000) libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007fcea8898000) libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007fcea8695000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fcea846a000) libdrm_nouveau.so.2 => /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (0x00007fcea8262000) libdrm_radeon.so.1 => /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1 (0x00007fcea8056000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007fcea7e45000) libdrm_amdgpu.so.1 => /usr/lib/x86_64-linux-gnu/libdrm_amdgpu.so.1 (0x00007fcea7c3c000) libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007fcea7a22000) libLLVM-5.0.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1 (0x00007fcea441a000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcea4094000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcea3d3e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcea395e000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcea3747000) /lib64/ld-linux-x86-64.so.2 (0x00007fceaa74d000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fcea3543000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fcea333d000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fcea3135000) libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007fcea2efe000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fcea2cd5000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fcea2ac0000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcea28b8000) Интересно (In reply to comment #27) > > 2) Он не находит либу, нужно добавить симлинк > ln -s vdpau_drv_video.so nouveau_drv_video.so Возможно, что нужно делать ln -s nvidia_drv_video.so nouveau_drv_video.so Во всяком случае, у нас такие файлы в пакете vaapi-driver-vdpau /usr/lib64/dri/nvidia_drv_video.so /usr/lib64/dri/s3g_drv_video.so /usr/lib64/dri/vdpau_drv_video.so (In reply to comment #33) > Надо аккуратнее с этими симлинками. Посмотрел, в Ubuntu нет > vdpau_drv_video.so, но nouveau_drv_video.so есть, не является симлинком и > принадлежит пакету mesa-va-drivers. Похоже, у нас mesa собирается без va. Во всяком случае, в этом спеке отключена https://abf.rosalinux.ru/import/mesa/blob/rosa2016.1/mesa.spec %bcond_with opencl %bcond_without osmesa %bcond_without osmesa_gallium %bcond_with va %bcond_without vdpau %bcond_without wayland Локально запустил сборку с включенным va. Если не будет проблем, пересоберу потом для x11_backports_personal. Точно. После включения получил ответ DEBUG: Обнаружен(ы) установленный(е) (но не упакованный(е)) файл(ы): DEBUG: /usr/lib64/dri/nouveau_drv_video.so DEBUG: /usr/lib64/dri/r600_drv_video.so DEBUG: /usr/lib64/dri/radeonsi_drv_video.so Добавил в спек изменения https://abf.rosalinux.ru/import/mesa/commit/85ea02f83fcede7c17fde781101e445c7b685819 Собирать не стал для x11_backports_personal, так как новые пакеты libva не опубликованы. Если нужно кому, можно собрать подключив контейнера. Давайте тогда уж сразу libva до 2.0 обновим и уже с 2.0 пересоберем зависимые пакеты Попробовал собрать libva 2.0.0: https://abf.rosalinux.ru/build_lists/2919382, https://abf.rosalinux.ru/mikhailnov/libva/commit/a39ac5cdaff906449fd142b94407b1c6f89c8f65 (In reply to comment #39) > Давайте тогда уж сразу libva до 2.0 обновим и уже с 2.0 пересоберем > зависимые пакеты А не слишком радикально? Или может собрать в x11_backports_personal. У Федоры собрана эта версия только для fc28 https://koji.fedoraproject.org/koji/packageinfo?packageID=11490 KaOS правда уже перелезли на эту версию. Но у них всегда всё самое новое. http://kaosx.tk/packages/index.php?act=search&subdir=&sortby=date&order=descending&searchpattern=libva Соберу и погоняю пока локально. Нужно закончить перевод hugin, но очень лень. Это причина отложить его и передохнуть.:) У libva 2.0.0 нет двух либ относительно версии 1.8.3. /usr/lib64/libva-egl.so.2* /usr/lib64/libva-tpi.so.2* Не знаю, насколько они необходимы. Да уже заметил. Но, если судить по Ubuntu, в artful 17.10, где был libva 1.8.3, этих либ уже не было, но они были в более старых версиях, и то принадлежал -dev пакету https://packages.ubuntu.com/search?searchon=contents&keywords=libva-egl.so&mode=&suite=artful&arch=any (1.8.3, нет) https://packages.ubuntu.com/search?searchon=contents&keywords=libva-egl.so&mode=&suite=zesty&arch=any (1.7.3 - есть, в Росе до последнего онбовления было именно 1.7.3) Непонятно, как могла собраться 1.8.3 У меня вроде почти получилось обновить https://abf.rosalinux.ru/mikhailnov/libva/tree/rosa2016.1? , https://abf.rosalinux.ru/build_lists/2919388 Но возникают странные ошибки сборки, gzip: /builddir/build/SOURCES/libva-2.0.0.tar.gz: not in gzip format /bin/tar: This does not look like a tar archive, и на http://file-store.rosalinux.ru/ файла с нужным хешем по итогу нет. Может, потому, что я врунчую забил хеш в .abf.yml ? Но wget по логу пытается качатьи сходники с гитхаба. > Или может собрать в x11_backports_personal.
Смена so-name libva потребует пересборки chromium, mpv, ..., ..., такое огромное кол-во пакетов нет смысла класть и поддерживать в x11_backports_personal
Как в Рсое обычно поступают в таких случаях? Естьа втоматизация вычисления пакетов, котоыре нужно пересобрать? Или наверняка оставят до 2018.1?
А в Росиной 1.8.3 https://abf.rosalinux.ru/build_lists/2918708 они были. tpi.so тодже была в 1.8.3 artful (-dev) https://github.com/intel/libva/issues/72 > We are planning to bump the VA-API major version from 0.40.0 to 1.0.0. In the new version, we will > deprecate some useless API/data structures, e.g. libva-tpi, libva-egl. То есть есть риск, что что-нибудь отвалится, но это маловероятно, т.к. все или почти все зависящие пакеты поддерживаются новых версий, а в других дистрибутивах libva.so.1 не носят с собой, а прсото обновили до libva.so.2 Собралась libva 2.0.0 ! https://abf.rosalinux.ru/build_lists/2919390 (In reply to comment #47) > Собралась libva 2.0.0 ! > https://abf.rosalinux.ru/build_lists/2919390 А там не нужен патч 0001-va_drm-dlopen-correct-version-of-libva-x11.patch И так MAJOR 2 везде выставляет. Я собрал libva и libva-utils локально. В последнем добавились два бинарника. Сейчас пересобирается mesa, на очереди ffmpeg-3.5-git, mpv и qmplay2, и ещё наверное ffmpeg 3.4.1 нужно пересобрать, чтобы ничего не отвалилось, и можно устанавливать для проверки. Наверное час или полтора уйдёт на сборку. Не хочется что-нибудь сломать на основной машине. Но мне nouveau всё равно не проверить. На ноутбуке карта intel с гибридной nvidia. (In reply to comment #39) > Давайте тогда уж сразу libva до 2.0 обновим и уже с 2.0 пересоберем > зависимые пакеты Похоже, что не стоит. ffmpeg собирается с ней, но вот mpv потом не видит libva, и qmplay2 не хочет собираться. Ещё немного повожусь с ними и забью. Для mpv 0.27.0, есть в Arch и Ubuntu (https://git.archlinux.org/svntogit/community.git/tree/trunk?h=packages/mpv) ------- From 2ecf240b1cd20875991a5b18efafbe799864ff7f Mon Sep 17 00:00:00 2001 From: Mark Thompson <sw@jkqxz.net> Date: Mon, 9 Oct 2017 20:10:26 +0100 Subject: [PATCH] vaapi: Use libva2 message callbacks They are no longer global, so they work vaguely sensibly. --- video/vaapi.c | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) --- a/video/vaapi.c +++ b/video/vaapi.c @@ -112,9 +112,27 @@ static void va_get_formats(struct mp_vaa ctx->image_formats = formats; } -// VA message callbacks are global and do not have a context parameter, so it's -// impossible to know from which VADisplay they originate. Try to route them -// to existing mpv/libmpv instances within this process. +#if VA_CHECK_VERSION(1, 0, 0) +static void va_message_callback(void *context, const char *msg, int mp_level) +{ + struct mp_vaapi_ctx *res = context; + mp_msg(res->log, mp_level, "libva: %s", msg); +} + +static void va_error_callback(void *context, const char *msg) +{ + va_message_callback(context, msg, MSGL_ERR); +} + +static void va_info_callback(void *context, const char *msg) +{ + va_message_callback(context, msg, MSGL_V); +} +#else +// Pre-libva2 VA message callbacks are global and do not have a context +// parameter, so it's impossible to know from which VADisplay they +// originate. Try to route them to existing mpv/libmpv instances within +// this process. static pthread_mutex_t va_log_mutex = PTHREAD_MUTEX_INITIALIZER; static struct mp_vaapi_ctx **va_mpv_clients; static int num_va_mpv_clients; @@ -149,6 +167,7 @@ static void va_info_callback(const char { va_message_callback(msg, MSGL_V); } +#endif static void open_lavu_vaapi_device(struct mp_vaapi_ctx *ctx) { @@ -181,6 +200,10 @@ struct mp_vaapi_ctx *va_initialize(VADis }, }; +#if VA_CHECK_VERSION(1, 0, 0) + vaSetErrorCallback(display, va_error_callback, res); + vaSetInfoCallback(display, va_info_callback, res); +#else pthread_mutex_lock(&va_log_mutex); MP_TARRAY_APPEND(NULL, va_mpv_clients, num_va_mpv_clients, res); pthread_mutex_unlock(&va_log_mutex); @@ -191,6 +214,7 @@ struct mp_vaapi_ctx *va_initialize(VADis vaSetErrorCallback(va_error_callback); vaSetInfoCallback(va_info_callback); #endif +#endif int major_version, minor_version; int status = vaInitialize(display, &major_version, &minor_version); @@ -231,6 +255,7 @@ void va_destroy(struct mp_vaapi_ctx *ctx if (ctx->destroy_native_ctx) ctx->destroy_native_ctx(ctx->native_ctx); +#if !VA_CHECK_VERSION(1, 0, 0) pthread_mutex_lock(&va_log_mutex); for (int n = 0; n < num_va_mpv_clients; n++) { if (va_mpv_clients[n] == ctx) { @@ -241,6 +266,7 @@ void va_destroy(struct mp_vaapi_ctx *ctx if (num_va_mpv_clients == 0) TA_FREEP(&va_mpv_clients); // avoid triggering leak detectors pthread_mutex_unlock(&va_log_mutex); +#endif talloc_free(ctx); } А можете выложить (например, на ABF) свои спеки для обновления libva-utils, не совсем понимаю, что я неправильно делаю, сравнить мои и ваши в образовательных целях. В чейнджлогах libva https://github.com/intel/libva/releases не видно каких-то важных нововведений, в т.ч. не заявлено поддержки нового оборудования, т.е. выгода сомнительная Я патчи видел. Но я собирал mpv 0.28.0 и mpv 0.28.0 из git. Мне нужен именно mpv 0.28.0. Ну и обязательно qmplay2 нужен. Он тоже валится с ошибкой при сборке. Пока подожду, или может на свежую голову потом ещё попробую собрать. Пакет libva http://rgho.st/7NvNF7krk Пакет libva-utils http://rgho.st/6fWzPWCCQ Но скорее всего не собирается, так как при сборке libva-utils устанавливается libva-1.8.3, у которого более высокий Epoch: 2. Вспомнил об еще одном флаге, который вводится этим патчем: Hardware-accelerated mjpeg decode for captured frame Enable hardware-accelerated mjpeg decode for captured frame where available. – Linux #enable-accelerated-mjpeg-decode P.S. На планшете с Intel обновил Ubuntu 17.10 --> 18.04 ради libva 1.8.3 --> 2.0.0, пока что VA-API в Хромиуме отвалилось. (In reply to comment #55) > P.S. На планшете с Intel обновил Ubuntu 17.10 --> 18.04 ради libva 1.8.3 --> > 2.0.0, пока что VA-API в Хромиуме отвалилось. В той версии Хромиума, которую я пересобрал для РОСЫ, работает? Мне сейчас интересен Хромиум для РОСЫ, чтобы он прошёл проверку и появился у пользователей. Chromium 63 + libva 1.8.3 — работают (комментарий #6). (In reply to comment #24) > (In reply to comment #17) > > (In reply to comment #14) > > > И таки да, libva надо обновить до 1.8.3 для чистоты экспериментов. > > > > Advisory: "Update libva to new version 1.8.3" > > > > https://abf.rosalinux.ru/build_lists/2918707 > > https://abf.rosalinux.ru/build_lists/2918708 > > > > Advisory: "Split libva-utils from libva package (since version 1.8.3)" > > > > https://abf.rosalinux.ru/build_lists/2918709 > > https://abf.rosalinux.ru/build_lists/2918710 > > (In reply to comment #18) > > Advisory: "Update vaapi-driver-intel to new version 1.8.3" > > https://abf.rosalinux.ru/build_lists/2918724 > > https://abf.rosalinux.ru/build_lists/2918725 > > Пересобрал Хромиум с новыми версиями > https://abf.io/build_lists/2919117 > https://abf.io/build_lists/2919118 Rebuild vaapi-driver-vdpau with new libva https://abf.io/build_lists/2919679 https://abf.io/build_lists/2919680 The update is sent to expanded testing *************************************** Добавьте в Хромиум примерно вот так: Recommends: pkgconfig(libva) Recommends: vaapi-driver-intel Recommends: vaapi-driver-vdpau Recommends: mesa (In reply to comment #60) > Добавьте в Хромиум примерно вот так: > Recommends: pkgconfig(libva) > Recommends: vaapi-driver-intel > Recommends: vaapi-driver-vdpau > Recommends: mesa Я, скорее, против. В r10 эти драйвера уже есть, а у кого-нибудь может отвалиться при обновлениях со старых версий. Новые фичи - в новых образах, такая у нас политика, а vaapi мы поддерживаем с r10. Хм, ну, если и в плеерах типа mpv из коробки нет VA-API, то тогда может быть, чтобы плееры не отвалились (что маловероятно)... К 2018.1 про это наверняка забудем. Хромиум 63 я больше пересобирать не планирую и ничего туда добавлять тоже. Пусть будет всё как есть и пусть опубликуется. После того, как браузер со всеми кодеками и драйверами отсюда опубликуется, займусь сборкой Хромиум 64. libva-1.8.3-1 https://abf.rosalinux.ru/build_lists/2918707 https://abf.rosalinux.ru/build_lists/2918708 libva-utils-1.8.3-1 https://abf.rosalinux.ru/build_lists/2918709 https://abf.rosalinux.ru/build_lists/2918710 vaapi-driver-intel-1.8.3-1 https://abf.rosalinux.ru/build_lists/2918724 https://abf.rosalinux.ru/build_lists/2918725 chromium-browser-stable-63.0.3239.132-3 https://abf.io/build_lists/2919117 https://abf.io/build_lists/2919118 vaapi-driver-vdpau-0.7.4-8 https://abf.io/build_lists/2919679 https://abf.io/build_lists/2919680 ******************************* Advisory *************************** Update libva to new version 1.8.3 Split libva-utils from libva package (since version 1.8.3) Update vaapi-driver-intel to new version 1.8.3 Chromium-browser and vaapi-driver-vdpau rebuild with new vdpau **************************************************************** QA Verified GpuVideoDecoder снова заработал с lbva2 в Chromium 66. Вот здесь человек утверждает, что на OpenMandriva с подключенными тестингами, в которых libva2, у него тоже работает: https://github.com/saiarcot895/chromium-ubuntu-build/issues/26#issuecomment-370995090 На всякий случай сюда запишу, чтобы не забыть. Steam:i386 (STEAM_RUNTIME=0) хочет libva.so.1, скорее всего, при обновлении до libva2 придется тащить libva1 для обратной совместимости; делать симлинки не пробовал. (In reply to comment #66) > На всякий случай сюда запишу, чтобы не забыть. Steam:i386 (STEAM_RUNTIME=0) > хочет libva.so.1, скорее всего, при обновлении до libva2 придется тащить > libva1 для обратной совместимости; делать симлинки не пробовал. Вполне возможно, что когда созреем для libva2, то уже и steam начнут собирать с libva2. Та версия steam 1.0.0.54, что сейчас у нас в репах, скомпилена 2016-11-23. Можно посмотреть внизу страницы http://repo.steampowered.com/steam/archive/precise/ В то время ещё не было libva2. Когда затеют скомпилить обновления, то могут собрать их и с libva2. Если убунта к тому времени на неё перейдёт. Это дата сборки пакета с лаунчером, а лаунчер скачивает сам Steam, вот прямо сейчас впервые в жизни запустил его, и в "Help --> About Steam" указана дата компиляции 19.03.2018 (In reply to comment #68) > Это дата сборки пакета с лаунчером, а лаунчер скачивает сам Steam, вот прямо > сейчас впервые в жизни запустил его, и в "Help --> About Steam" указана дата > компиляции 19.03.2018 Значит ещё не собирают с libva2. Да и не использует он системные либы. Наверное.:) Всё таки работает из каталога ~/.local/share/Steam Хотя вроде включали использование каких-то системных либ. Уже не помню, может это для pulse было. Тут ничего похожего не вижу https://abf.rosalinux.ru/import/steam |