linux debian аппаратное ускорение видео

В плеере нужно выбрать vdpau в качестве устройства вывода. Firefox - не умеет аппаратно декодировать видео. Chromium - умеет (в chrome://flags нужно включить «Переопределение списка программного рендеринга»). В chrome://gpu должно отображаться «Video Decode: Hardware accelerated».

p.s. Естественно, проприетарный драйвер nvidia должен быть установлен.

Естественно это все было сделано, загрузка процессора при просмотре видео 300%, лагает ужасно fullhd

В посте следовало указать, что «это все» было сделано. Следовало также написать название браузера.

Прошу прощения, да браузер chromium, acceleratoin hardware включил.

Значит в chrome://gpu «Hardware accelerated» отображается? В строчке GL_RENDERER написано «GeForce GT 635M»? Если смотришь видео на YouTube, установи расширение h264ify для отключения vp8/vp9 кодеков.

Да написано, как должно расширение помочь моей проблеме?

Это отключит кодеки vp8/vp9, и включит вместо них h264. Я не уверен, что 635M может декодировать VPx, но точно может h264. Так что это может помочь.

В Firefox под Linux аппаратного декодирования нет вообще. В Chromium есть такой код, но он собирается только при компиляции для ChromeOS. В Arch'е народ поддерживает патчи, включающие этот код. Если пересобрать Chromium с ними, ускорение будет.

Но само по себе декодирование сейчас помогает очень мало, основная нагрузка идёт из масштабирования и смешивания слоёв, что Chromium уже делает хорошо. Тем более, VP9, который в Youtube передаётся, всё равно не декодируется аппаратно.

Имеет смысл поставить какой-нибудь аддон к браузеру, который форсирует использование H.264. Этот кодек требует гораздо меньше CPU при декодировании, поэтому переход на него может помочь.

Через cuvid декодируется, например в mpv. В кеби лейк тоже завезут vp9 декодер.

Только из-за этого можно нарваться с тормозами воспроизвведения. CDN ютубные часто всё кроме умолчательных форматов очень медленно отдают.

В хроме же отпилили 3d-ускорение под linux, не?

В кеби лейк тоже завезут vp9 декодер.

Мне вот интересно, почему его в более ранние чипы не завозят.

Для скайлейка пишут partial support. Аппаратно не завезли просто видимо.

Аппаратно не завезли просто видимо.

Интелы странные. Железо всё странное, но тут другое. У них, по всей видимости, нет определённого блока, который декодирует битовый поток. Вместо этого видеоядро среди прочих шейдерных команд ещё имеет дополнительные, с которыми декодер писать проще. Что-то типа SSE4.2, но не для строковых операций, а для видеокодеков. Значительная часть их VA-API драйвера — это вручную написанный код декодеров на ассемблере для видеоядра.

И так как выделенных блоков нет, на Intel VA-API можно хоть 65 тысяч декодеров создавать, пока идентификаторы не кончатся. Пока они ничего не делают, они ничего не потребляют. Тогда как на NVIDIA VDPAU пару тройку создал — и всё. Ресурсы кончились, больше не может.

И вот я подумал, а может они всё же могут значительную часть работы по декодированию VP9 или, скажем, HEVC снять с CPU? Просто инженерам лень этим заниматься, они заняты запиливанием фич для новых чипов. Или это политическое решение, для подталкивания спроса.

h264ify - Только из-за этого можно нарваться с тормозами воспроизвведения. CDN ютубные часто всё кроме умолчательных форматов очень медленно отдают.

Сомнительно.

Во первых, h264 является по умолчанию для всяких там мобильных, а так же для EDGE и Safari.

Во вторых, постоянно пользуюсь браузером без поддержки VP9 и что-то не замечал.

В третьих, сравнил прям сейчас скорость - тоже подобного не увидел.

Привет! Для аппаратного ускорения видео пользуйся mpc вместо mplayer. Настрой для него графическую оболочку SMplayer.

Для аппаратного ускорения видео в браузере (только Firefox) пользуйся Flash Player 11.2.202.644 (архивная версия), включи VDPAU по руководству (инструкция для Intel). Также установи дополнение Youtube HTLM5-Flash

Разумеется у всех будет отличаться из-за провайдера и места проживания. Вбей в поисковик что-то вроде youtube cdn problem.

Разумеется у всех будет отличаться из-за провайдера и места проживани

А речь не о том, что у среднего Васи в одном месте средняя итоговая скорость передачи отличаться от среднего Пети в совершенно в другом месте.

Речь была о том, что переключение кодека с VP9 на h264 вообщем понизит среднюю скорость передачи у среднего Сергея, причем понизит со словом «очень».

Первое утверждение логичное, второму подтверждений и логических обоснований нет.

PS: другое дело, что VP9 меньше по размеру при том же качестве (этак на 20% ?) и это может накинуть на возможные тормоза из-за интернетов, но это тоже не про саму скорость отдачи

Рад за тебя, что у тебя нет. Я описываю то, с чем регулярно сталкиваюсь. Если интересуют уточнения или тесты, задавай впоросы иначе иди проветривайся.

20%

Тормоза капитальные, просто до нуля скорость падает. Переключаеешь формат и моментально кэш заполняется во всю скорость канала.

Рад за тебя, что у тебя нет.

Есть, но у меня все по логичному.

Вот сейчас проверил - скорость упала в 4 (!) раза по сравнению с ранним утром. Последние две неделе вообще что попало творится. Но скорость от провайдера стабильная.

Берем youtube-dl на одном и том же файле:

h264-1080p - 131.29 Mb - 265 секунд

vp9-1080p - 113.81 Mb - 242 секунд

Как я и говорил, vp9 по размеру меньше немного, что может помочь, но скорость скачки примерно одинакова.

PS: полоска заполнения кэша браузера кстате естественно условная при автовыборе качества

пользуйся Flash Player 11.2.202.644

Если уж пользоваться Flash, то брать самую свежую версию. В ветке 11.2 больше обновлений безопасности не будет.

У меня не работает VDPAU на 24.xx. Если включить его в /etc/adobe, то плагин аварийно завершает работу.

плагин аварийно завершает работу

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f607e38f537 in vdp::VideoSurface::CreateImpl (device_id=300001, chroma_type=0, width=864, height=480, surface=0x80463f7c18e0)

...

(gdb) p surface
$1 = (VdpVideoSurface *) 0x80463f7c18e0
(gdb) p *surface
Cannot access memory at address 0x80463f7c18e0
(gdb) 

Весело у них там.

Спасибо господа за ответы, полезная инфа!

https://github.com/i-rinat/libvdpau-va-gl вот это твоё помогло убрать загрузку с процессора, так же я смог смотреть 4к видео без тормозов. Но после ребута ноута, всё пропало, устанавливал по новой, всё делал так же, но результат не появился.

но результат не появился

Там много звеньев в цепочке. Во-первых, приложение действительно должно использовать VDPAU. Во-вторых, драйвер должен лежать там, где libvdpau его сможет найти. Переменную среды VDPAU_DRIVER нужно установить, чтобы libvdpau знал, что вообще искать.

Имеет смысл запустить приложение с установленной переменной среды VDPAU_TRACE=1. Тогда libvdpau выдаст трассировку вызовов в консоль, если они вообще были.

В Firefox под Linux аппаратного декодирования нет вообще

Когда-то было. Потом оно стало по умолчанию выключено. Теперь его нет вообще. Еще одно доказательство того что лиса добровольно уступает место на рынке хрому. Ну в смысле за некие откаты ответственным лицам. Вот поэтому я хром принципиально не ставлю и не поставлю. Они и оригинальную оперу угробили, задушив грязными зелеными бумажками, положеными в нужные карманы, — заставили перейти на двигло хрома.

Я считаю, байкот хрома - дело совести каждого сторонника опендвижа, у кого она есть.

Когда-то было.

Не было. Когда-то использовался GStreamer, в котором было аппаратно-ускоренный кодек. Но из-за того, что декодированные кадры забирались обратно в память CPU, и на нём же масштабировались, толку от этого ускоренного варианта было ноль. Разве что некоторые пользователи этому плацебо радовались.

Потом оно стало по умолчанию выключено.

Это настройки GStreamer, они не имеют отношение к лисе вообще.

байкот хрома

Хейти, если нравится. Но хотя бы слово «бойкот» правильно пиши. В хроме, кстати, аппаратный декодер под линуксом тоже не работает.

Не было.

Было но надо было включать в aboug:config. Сейчас можно нагуглить много инструкций на эту тему, которые уже не работают.

Я не знаю технических деталей. Мне важна картина в панораме: браузер сознательно сливается своими создателями.

Было но надо было включать в aboug:config. Сейчас можно нагуглить много инструкций на эту тему, которые уже не работают.

Если ты не поленишься поискать эти инструкции, а потом почитать, что такое GStreamer, как он работает, и как Firefox его использовал, придёшь аккурат к тому самому, что я тебе уже написал.

Во, попалось тормозное видео, правда разница не такая, как в худших случаях бывает. Как видишь весит меньше, а грузится дольше:

137          mp4        1920x1080  1080p 4439k , avc1.640028, 30fps, video only, 143.86MiB
...
[download] 100% of 143.86MiB in 02:47

248          webm       1920x1080  1080p 3771k , vp9, 30fps, video only, 138.31MiB
...
[download] 100% of 138.31MiB in 03:16

Но ведь это противоречит твоему изначальному сообщению. Выходит mp4 cdn таки быстрее. Логика?

У меня не работает VDPAU на 24.xx. Если включить его в /etc/adobe, то плагин аварийно завершает работу.

Flash 24 версии на Linux не поддерживает (Adobe сознательно отключило участок кода из-за безопасности) аппаратное ускорение.

В новости об этом флеше было не про это. Там было про защищённое DRM-ом видео. Оно реализовывалось через HAL (libhal.so.1), который в 2010 объявили устаревшим.

А ты попробуй в конфиг прописать флажок аппаратного ускорения и увидишь не рабочий flash.

Да, я уже попробовал. Есть такой трюк: strings libflashplayer.so | grep lib. Он показывает все зависимости. Включая те, которые подключаются с помощью dlopen(), следовательно не видны обычным ldd. Так вот, VDPAU есть. Просто сломался. А libhal нет, хотя он есть во Flash 11.2.

Давай лечись от дислексии, у меня было про разные форматы, а не какие-то конкретные. Когда попадётся быстрый vp9 медленный mp4, тогда ткну тебя в него носом.

Какой глупый человек мне попался... А теперь напряги свой мозг и прояви хоть капельку разума. Перечитай своё изначальное сообщение столько раз, пока не поймёшь, где же ты ошибся. И хватит кидаться умными словечками из словаря, ума это вряд ли прибавит, впрочем, как и необоснованные оскорбления собеседника, которого ты совсем не знаешь.

Откуда и зачем вы лезете такие? Описываю проблему подробно: скорость канала и мощность компа заведомо избыточные. Отдача видео сервером ютуба тормозит, меняем кодек (неважно с какого на какой, просто разные) на другой и видео качается во всю скорость канала. Меняем формат обратно — опять не качается.

Изначально написано совсем другое:

Только из-за этого можно нарваться с тормозами воспроизвведения. CDN ютубные часто всё кроме умолчательных форматов очень медленно отдают.

И чё? Мне статистику собирать перед написанием каждого поста?

А firmware все установлены? Как бы 300 % нагрузка совсем ни к чёрту. У меня самый дохлый дачный лэптоп на Ivy Bridge Celeron'e 1500 MHz, с сымым дохлым HD Graphics в серии, в браузере на HD-видео больше 35 % не задействовал, а в mpv с vaapi так и вовсе 3...7 %. Ubuntu.

Есть такой трюк: strings libflashplayer.so | grep lib. Он показывает все зависимости. Включая те, которые подключаются с помощью dlopen(), следовательно не видны обычным ldd. Так вот, VDPAU есть.

Ты занимаешься какими-то бесполезными упражнениями.

https://imgur.com/I9r4YK7

Ну и как это сделать?

Понял - надо Fresh Player. Пробую скомпилировать 0.3.5 с компилятором GCC 4.9.3, посмотришь ошибку?

abuild@linux-11ai:~/freshplayerplugin-0.3.5/build> make
Scanning dependencies of target uri-parser-obj
[ 44%] Building C object src/uri_parser/CMakeFiles/uri-parser-obj.dir/uri_parser.c.o
In file included from /usr/lib64/glib-2.0/include/glibconfig.h:9:0,
                 from /usr/include/glib-2.0/glib/gtypes.h:34,
                 from /usr/include/glib-2.0/glib/galloca.h:34,
                 from /usr/include/glib-2.0/glib.h:32,
                 from /home/abuild/freshplayerplugin-0.3.5/src/uri_parser/uri_parser.h:29,
                 from /home/abuild/freshplayerplugin-0.3.5/src/uri_parser/uri_parser.c:25:
/usr/include/glib-2.0/glib/gthread.h: In function ‘g_once_init_enter’:
/usr/include/glib-2.0/glib/gmacros.h:151:53: warning: typedef ‘_GStaticAssertCompileTimeAssertion_0’ locally defined but not used [-Wunused-local-typedefs]
 #define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAs
                                                     ^
/usr/include/glib-2.0/glib/gmacros.h:286:25: note: in definition of macro ‘G_LIKELY’
 #define G_LIKELY(expr) (expr)
                         ^
/usr/include/glib-2.0/glib/gmacros.h:149:47: note: in expansion of macro ‘G_PASTE_ARGS’
 #define G_PASTE(identifier1,identifier2)      G_PASTE_ARGS (identifier1, identi
                                               ^
/usr/include/glib-2.0/glib/gmacros.h:151:44: note: in expansion of macro ‘G_PASTE’
 #define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAs
                                            ^
/usr/include/glib-2.0/glib/gatomic.h:133:5: note: in expansion of macro ‘G_STATIC_ASSERT’
     G_STATIC_ASSERT (sizeof *(atomic) == sizeof (gpointer));                 \
     ^
/usr/include/glib-2.0/glib/gthread.h:347:27: note: in expansion of macro ‘g_atomic_pointer_get’
   if G_LIKELY ((gpointer) g_atomic_pointer_get (value_location) != NULL)
                           ^
[ 44%] Built target uri-parser-obj

 zypper se -is glib2*
Loading repository data...
Reading installed packages...

S | Name        | Type    | Version      | Arch   | Repository
--+-------------+---------+--------------+--------+-----------
i | glib2-devel | package | 2.30.1-2.1.2 | x86_64 | cd        
i | glib2-tools | package | 2.30.1-2.1.2 | x86_64 | cd

Не вижу сообщений об ошибке, только предупреждения.