libvdpau-va-gl

Правильно ли понял, что эта штука позволяет частично использовать vdpau не только с картами nvidia?

Да, это частичная реализация VDPAU с использованием VA-API и OpenGL. Искоробочный mplayer уже некоторые H.264 видео кажет, и flashplayer на youtube'е меньше тормозит. Я тестирую на intel ironlake, но с проприетарным драйвером на amd тоже должно работать.

Почему только с проприетарным?

Потому, что открытый драйвер — швабодка кококо.

Почему только с проприетарным?

Потому что доступ к аппаратному декодеру есть только в проприетарном. Там используется API XvBA, для которой есть VAAPI драйвер. Масштабирование видео будет работать и на открытом, наверное. Я просто не проверял. А ещё в моём чипе нет поддержки VC1, так что его поддержку вряд ли сделаю.

доступ к аппаратному декодеру есть только в проприетарном

Все так. Но есть начальная реализация в mesa, но она не поддерживает H264 -> практически бесполезна. Спасибо.

например: http://ru.twitch.tv/

Попробуй собрать https://github.com/i-rinat/libvdpau-va-gl/archive/point3.tar.gz

Там ещё собирается крошечная библиотека libxinitthreads.so, её надобно подгружать через LD_PRELOAD=./libxinitthreads.so <browser-name>. Я долго пытался понять, почему flash падает, а тесты нет. Выяснилось, что flash падает и без моей библиотеки, сам по себе. Начинается это, если принудить его декодировать видео через настройки в /etc/adobe/mms.cfg: работа идёт в несколько потоков, а XInitThreads() никто не вызвает. Трюком с загрузкой библиотеки XInitThreads вызывается до того, как будет вызвано что-то ещё.

Рекламу показывает

XInitThreads()
[VS] Software VDPAU backend library initialized
libva: VA-API version 0.32.0
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva: va_openDriver() returns 0

Зелень пропала. При попытке изменить качество или остановить паузой, падает флеш При сборке в дебаге последние записи:

[VS] {WIP} VdpDecoderRender decoder=2, target=5, picture_info=0x7f08ea6d5d38, bitstream_buffer_count=1
[VS] {part} VdpVideoSurfaceGetBitsYCbCr surface=9, destination_ycbcr_format=VDP_YCBCR_FORMAT_NV12
[VS] {full} VdpDeviceDestroy device=1
[VS] {full} VdpDecoderDestroy decoder=2

При попытке изменить качество или остановить паузой, падает флеш

У меня изредка тоже падает, причём вообще сам по себе, даже когда я свой драйвер отключаю. И preload не помогает. Не представляю, где он там глючит. И тест не могу написать; в общем, с падениями глухо.

Кстати, какой у тебя браузер?

Firefox 19.0.2,

флеш 11.2 r202

Флеш при переключении качества видео падает всегда сейчас.

Без export VDPAU_DRIVER=va_gl не падает вообще. в mms.cfg сейчас только EnableLinuxHWVideoDecode=1

Кст, это потоковое видео без акселерации походу идёт (загрузка процессора такая же как и без VDPAU_DRIVER). Это в принципе не плохо, если бы не падал флеш

Firefox 19.0.2,

Поставлю iceweasel 19.0.2, он не должен вроде отличаться от firefox.

флеш 11.2 r202

Флеш я обновил до 11.2.202.275 (до этого было 11.2.202.270 или .273). Это самая свежая доступная. Поставь такую же, так проще будет баги отслеживать. Сейчас буду тестить.

Кст, это потоковое видео без акселерации походу идёт

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

Флеш при переключении качества видео падает всегда сейчас.

Разобрался, дело действительно было в неправильной последовательности освобождения ресурсов. Добавил подсчёт ссылок (в ветке master), у меня перестало падать.

Круто. Затестил на старом флеше, работает с LD_PRELOAD библиотекой. В 720p 40-60% CPU, в основном на 800 MHz.

Есть ещё одна проблема: Картинка рассыпается на видеостримах (тот же http://ru.twitch.tv). Т.е. если быстро сцена меняется, то видео всё в квадратных артефактах + происходит заливка целых областей неправильными цветами (розовые пятна).

Отображение нормальное, если не использовать vaapi с флешом.

Если пользоваться mplayer -vo vdpau с библиотекой или на youtube, то такой проблемы нет.

но в оконном режиме всё хорошо.

флеш жрет всегда. просто если разрешение 320х240 (или скока там), то не так заметно. и разные флеши по-разному, но все жрут.

Картинка рассыпается на видеостримах

Да, я в курсе, но не знаю, в чём именно проблема, надо проверять.

Если пользоваться mplayer -vo vdpau с библиотекой или на youtube, то такой проблемы нет.

У меня есть пара видео, на которых и в mplayer'е картинка рассыпается. Так что тест вроде как есть, надо копать вглубь.

В 720p 40-60% CPU, в основном на 800 MHz.

Есть ещё трюк с wmode. Ставишь greasemonkey, добавляешь новый скрипт (я взял за основу Scroll Over Flash Contents с userscripts.org), меняешь его код на

// ==UserScript==
// @name           Scroll Over Flash Contents
// @namespace      http://userscripts.org/topics/3090#posts-11620
// @description    Sets embed's and object's wmode parameter to transparent, so the mouse can scroll over flash contents
// @include        *
// ==/UserScript==

(function ()
{
	nodeInserted();
})();

document.addEventListener("DOMNodeInserted", nodeInserted, false);

function nodeInserted()
{
	for (var objs = document.getElementsByTagName("object"), i = 0, obj; obj = objs[i]; i++)
	{
		if (obj.type == 'application/x-shockwave-flash')
		{
			var skip = false;
			for (var params = obj.getElementsByTagName("param"), j = 0, param; param = params[j]; j++)
			{
				if (param.getAttribute("name") == "wmode")
				{
    				param.setAttribute("value", "direct");
					skip = true;
					break;
				}
			}
			if(skip) continue;
			var param = document.createElement("param");
			param.setAttribute("name", "wmode");
			param.setAttribute("value", "direct");
			obj.appendChild(param);
		}
	}
	
	if (typeof document.embeds != 'undefined')
	{
		for (var ems = document.embeds, i = 0, em; em = ems[i]; i++)
		{
			if ((em.getAttribute('wmode') && em.getAttribute('wmode') == 'direct')) continue;
			em.setAttribute('wmode', 'direct');
			var nx = em.nextSibling, pn = em.parentNode;
			pn.removeChild(em);
			document.removeEventListener('DOMNodeInserted', nodeInserted, false);
			pn.insertBefore(em, nx);
			document.addEventListener("DOMNodeInserted", nodeInserted, false);
		}
	}
}

Этот скрипт добавляет или меняет параметр wmode, делая его равным direct. После этого включается масштабирование через VDPAU, нагрузка должна снизиться.

Добавил открытие собственного соединения с X сервером, теперь preload-ить библиотеку libxinitthreads.so не надо.

Что-то не выходит собрать, ругается на

package 'libva-glx' not found

Но оно стоит. Все что указанно в README стоит
Раньше ну та которая была point1, проверка проходила. Попробовал point3 и срез с git'а.

Но оно стоит. Все что указанно в README стоит

Надо поставить libva-dev, в нём есть заголовочные файлы, а в libva-glx1 только сама библиотека. Я обновил README, добавил упоминание о libva-dev.

point1, проверка проходила

В point1 не было ни использования VAAPI, ни OpenGL. Только софтовое масштабирование.

Да собралось конечно. Спасибо

point4-2-gb0235e2

Сама библиотека осталась, собирается: libxinitthreads.so

но не копируется по install

Просто игнорировать её?

Без прелоад вроде не падает.

Просто игнорировать её?

ага. Кстати, в master исправлены цветные артефакты, по крайней мере те, что видел я. Есть ещё один баг, связанный с числом слайсов в кадре; сейчас думаю, как чинить.

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

http://www.twitch.tv/whitera

1080p рассыпается квадратами На 720p тоже видно, но меньше реклама (360p-480p) - сильно рассыпается.

Всё ещё очень зависит от того насколько быстро сцена видео меняется

Я поправил те артефакты, которые видел у себя, но не уверен, что это не поломало long-term-reference кадры. (В master-ветке)

Заработало!

один раз правда подвесил GPU на i3-3210

Ненужно!!!!

кто дал ему компьютер???отобрать и на лесоповал!

Да, с зависаниями беда. Трудно воспроизвести. Как и падения флеша.

течёт eщё plugin-container когда включен vaapi. и Virt и Res постоянно растут

течёт eщё plugin-container когда включен vaapi

Примерно на 3-4 МБ на каждую смену видео. Это из-за неправильного порядка удаления объектов flash'ем. Буду думать, как обойти.

Попробуй ещё раз, должно перестать течь.

point4-23-gc316bf3, всё так же, на потоковом видео 1-2мб натекает за несколько секунд. Без vaapi держится на 107МБ rss.

В смысле течёт без переключения видео, только с одной вкладкой

А до каких значений растёт?

 VIRT  RES  SHR S %CPU %MEM    TIME+ 
1982m 483m  60m R   96 12.4  35:16.34

А потом дохнет на 32битной, когда кончается адресное пространство, или уходит в жёсткий своп на 64битной.

Ну, дубль два. Я нашёл ещё одну причину утечек. Отправил исправление в ветку master на github'е.

Согласно документации, va драйвер должен самостоятельно разбираться с обработанными буферами, но почему-то он с этим не справляется в данном случае. Хотя в mplayer-vaapi шаблон использования такой же, а утечек нет.

 VIRT  RES  SHR S %CPU %MEM    TIME+ 
 860m 196m  24m S   92  5.1  32:05.54

Медленней, но всё равно растёт

Глянь, растёт число drm объектов со временем или нет.

cat /proc/`pidof plugin-container`/maps | grep drm | wc -l

48 71 интервал в 5 минут

Если бы они утекали, за пять минут больше 7000 было. Может у флеша есть какой-то внутренний кэш, либо он хранит в памяти весь сжатый поток.

В общем, я пока не могу воспроизвести.

Убрал ещё одну причину тормозов.

Оказалось, если цеплять GL контекст к разным окнам, это приводит к серьёзным утечкам в dri2. Видимо, так никто никогда не делает, оттого и использована простая, но тормозная реализация. К счастью, нашёлся способ не цеплять контекст к разным окнам.

отпиши им баг, на всякий случай.

какой-то неясный парадокс получается с декодированием h264 1080p:

mplayer без vdpau/vaapi => 30-40% CPU, одно ядро практически всегда 800MHz

vlc с vaapi => 80-90% CPU, одно ядро всегда на 2.4MHz, иногда 2

vlc без акселерации декодирования видео => 50-60% CPU

flash + vaapi => 90% CPU

perf top показывает, что у mplayer взя загрузка от libavcodec.so.53.35.0

Если включено vaapi, вся нагрузка в i965_drv_video.so

отпиши им баг

Там нет бага, как такового. Ресурсы управляются подсчётом ссылок, поэтому при выключении приложения всё вычищается (но видео подвисает на несколько секунд). Хотя это не запрещено, так никто не делает.

В общем, мне лень. :)

mplayer без vdpau/vaapi => 30-40% CPU

А если mplayer -vc ffh264vdpau VideoFileName.mkv ?

vlc с vaapi => 80-90% CPU

Не смотрел в код, но судя по всему, vlc забирает картинку обратно для применения видео-фильтров, и это тормозит.

flash + vaapi => 90% CPU

попробуй ради эксперимента на youtube.com. На twitch.tv флеш забирает картинку обратно и скейлит сам, выплёвывая результат снова в vdpau, что выливается в высокую нагрузку на cpu. На youtube.com с этим получше.

Если включено vaapi, вся нагрузка в i965_drv_video.so

У меня [drm] drm_clflush_pages пожирает основное время.

А если mplayer -vc ffh264vdpau

я для чистоты эксперимента rtmpdump использую, чтобы один и тот же поток смотреть. 11% в libc

vlc тупит на 92.47% vlc i965_drv_video.so [.] memcpy_pic

это в смысле не относится к libvdpau-va-gl, но забавный факт

я не знаю как им это описать. и если не баг ,то enhancement, хотя бы

vlc тупит на 92.47% vlc i965_drv_video.so [.] memcpy_pic

Ну да, точно. Они там вызывают vaGetImage, внутри которого делается цикл с memcpy. А потом всё равно выводят картинку на экран.

Оказалось, что такой баг уже открыт: https://bugs.freedesktop.org/show_bug.cgi?id=55675

Добавил я туда свой вариант кода для воспроизведения. Но что-то мне кажется, что он долго ещё открытым простоит, ибо такой код кривой и нарушает все рекомендации.

понял. спасибо!