FreshPlayerPlugin — PepperFlash в Firefox

VAAPI с nouveau все равно использует VDPAU-backend

Неа, там недавно добавили vaapi стейт трекер.

И чё-т не въезжаю. Накатил я browser-plugin-freshplayer-pepperflash:i386 из бэкпортов. Скачал 32-разрядный хромог и распаковал (руками, ибо дебиановский скрипт требует 32-разрядный binutils, который конфликтует с 64-разрядным) пепперфлеш в /usr/lib/PepperFlash/libpepflashplayer.so. Однако фрешплеер по-прежнему кажет жёлтый крестик и не желает его видеть. Хотя путь этот в списке проверенных есть. Что характерно, среди путей присутствует lib64. Хардкод? криво собрали и лучше таки самому? или что ещё?

не желает его видеть

В ldd libpepflashppayer.so все зависимости есть?

Хардкод?

Конечно. А как иначе?

В ldd libpepflashppayer.so все зависимости есть?

Вроде да.

bodqhrohro@localhost:~$ ldd /usr/lib/PepperFlash/libpepflashplayer.so 
	linux-gate.so.1 (0xf77b2000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf68b5000)
	librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf68ac000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf673b000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf66ef000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf66d2000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf66b6000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf6539000)
	/lib/ld-linux.so.2 (0x56638000)

А как иначе?

Условия. PepperFlash же только под x86/amd64 есть? Впрочем, и без того, у меня есть /usr/lib32 и /usr/libx32...

Вроде да.

Могут ещё быть проблемы с версиями. Попробуй ldd /usr/lib/PepperFlash/libpepflashplayer.so

Ещё имеет смысл попробовать слинковаться с ней. Создаёшь простейший

int main(){}

gcc file.c -L/usr/lib/PepperFlash/ -lpepflashplayer

Условия. PepperFlash же только под x86/amd64 есть?

Там целая куча разных путей в зависимости от дистрибутива. Проще пробегаться по всем путям, чем детектировать дистрибутивы.

Вопрос по зависимостям. В генте ебилд плагина требует ffmpeg собранный с libx264, они упоролись? Что теряется, если отключить libv4l? Можно ли сделать libva необязательной при сборке с vdpau?

В генте ебилд плагина требует ffmpeg собранный с libx264, они упоролись?

Кодирования нет, так что libx264 не нужен.

Что теряется, если отключить libv4l?

libv4l прозрачно для приложения преобразует формат цвета кадров. Если её отключить, то freshwrapper не будет работать с вебкамерами, которые не поддерживают V4L2_PIX_FMT_YUV420.

Можно ли сделать libva необязательной при сборке с vdpau?

Теоретически возможно, но мне лень. Libva же маленькая и собирается быстро.

Обновил Firefox до с 41.0 до 43.0 из репозиториев Убунты. Флеш перестал подавать признаки жизни. Не работает вообще и если запускать из терминала firefox, то нет никаких сообщений о запуске freshplayer или об ошибках с ним возникших. Как можно починить?

Файл pluginreg.dat надо удалить. Похоже, Firefox решил, что плагин неработоспособен и закешировал эту информацию в pluginreg.dat.

удалил. перезапустил. не помогло. печалька в общем.

С чистым профилем та же ситуация?

С пустым будет работать. Зацени что нашел только что: https://www.reddit.com/r/firefox/comments/3xkqrb/no_flash_streaming_players_w... . Виноваты мои аддоны Focus Regainer, либо Focus Regainer Lite. Mozilla сломала функционал моих аддонов. Спасибо мозилле в общем. Называется чинил своими аддонами изестную багу флэша https://bugzilla.mozilla.org/show_bug.cgi?id=78414 , а добрая компания mozilla сломала функционал моего аддона.

в общем я исправил (в версиях 0.11.0) Focus Regainer и Focus Regainer Lite для совместимости с Firefox 43. Жду ревью от мозиллы. Там все просто правится, вместо одной строчки две в chrome.manifest:

content	focusregainer	chrome/content/
content	focusregainer	chrome/content/	contentaccessible=yes

Прошу прощения за оффтоп. Просто друг кто наткнется на такую же проблему. А причина проблемы в том, что Mozilla никого не предупреждая (в очередной раз) усилила политику безопасности аддонов.

После предыдущего усиления политики безопасности пришлось делать такое: <binding id=«flash» bindToUntrustedContent=«true»> .

Приветствую

Спасибо за труд.
Попробовал сие решение на Slackware 14.1 x86_64, и такой вот интересный баг - изображение верх ногами. Причем только изображение, если водить мышей по изображению, то там с координатами всё отлично(на ютубе кнопки управления которые снизу рисуются сверху, но нажимать на них надо снизу там где положено). Воспроизводится и на ютубе и на различного рода играх.

Слака ванильная + зависимости из SBo (libva-1.6.1, libvdpau-1.1.1 ragel-6.9)
Флеш стоит 19ый.
Звук нормально, изображение если честно рывками(оригинальный флеш плавно). Система крутится в виртуалке(VBox 4.3.28). Воспроизводится в обоих Опере(12.16) и Лисе(38.4)
Вроде бы не течет, но CPU жрет на всю(может полезно будет): Опера 85-90% - плагин, 8-10% - сама Опера, остальное(2,5-3% минимум) Х сервер, возможно на реальном железе будет другое чтото будет.

А если в VirtualBox отключить 3D ускорение, что-то меняется?

С точки зрения перевернутости изображения - ничего.
С точки зрения прожорливости ЦПУ - тоже(оригинальный плагин жрал не более 12%, Х - по минимуму).
Проверял на обоих Опера и Лиса.

ЗЫ: хост у меня с т.ч. графики не очень(HP ProBook 450/Intel HD 4000+оффтопик 8.1), так что ломочь с отловом проблем производительности не смогу.

Попробовал поставить Slackware 14.1 x86_64 в VirtualBox. (В процессе пришлось превратить слаку в слаку). И там действительно изображение оказалось перевёрнутым. Я думаю, дело в Mesa. В том варианте, что я поставил, рисование было программное. Возможно, там ошибка в обработке шейдеров или умолчания какие-то другие. Не важно, включено было 3d ускорение в VirtualBox'е или нет, софт внутри виртуалки не знает, как им воспользоваться, поэтому изменение этой настройки ни на что не влияло. Пробовал обновлять Mesa до 11.0.8 (из Slackware 64 current) вместе с установкой guest additions, это тоже не помого. Точнее, как бы помогло — 3d отвалилось совсем и freshwrapper перешёл на программный рендеринг, но это не совсем то, чего я ждал.

В общем, единственным внятным решением оказалось добавить строку enable_3d = 0 в файл ~/.config/freshwrapper.conf. Конечно, рисование с помощью CPU ест больше ресурсов, чем использование аппаратно ускоренного OpenGL, но рисование через программную реализацию OpenGL ест их в разы больше.

Есть ещё полезная опция, enable_xrender = 0. Она отключает использование XRender, который, как говорят, часто глючно реализован. От неё потребление CPU ещё больше возрастёт.

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

Вон там https://www.virtualbox.org/ticket/12941#comment:109 про

[     6.731] (II) AIGLX: Screen 0 is not DRI2 capable
[     6.731] (EE) AIGLX: reverting to software rendering
[     6.825] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[     6.825] (II) AIGLX: Loaded and initialized swrast
[     6.825] (II) GLX: Initialized DRISWRAST GL provider for screen 0

The server will always use software acceleration since we do all acceleration on the client side. So nothing wrong there.

Пробовал обновлять Mesa до 11.0.8 (из Slackware 64 current)

Сборкой пакета из исходников -current и последующей его установкой (судя по последствиям — вряд ли)?

enable_xrender = 0

Это в какой версии появилось? В конфиге этого нет. Или эта опция просто там незадокументирована была?

В последнем релизе было уже, но в примере конфига ещё не было описания. В master ветке уже добавил.

Есть версия, что когда VBox 5.0 активно создавался, ветку 4.3.x отдали поддерживать каким-то нубам. Что в винде, что в линуксе бывают мелкие глюки. На айтишных форумах советуют при глюках откатываться на VBox 4.3.12.

Модули ядра работают «из коробки» с Linux 3.16, с ≥ 3.17 нужен патчинг.

Сборкой пакета из исходников -current и последующей его установкой

Просто готовый пакет поставил. Сейчас вот думаю, что надо было ещё и X.org обновить, но виртуалку уже удалил. В виртуалках как-то всё плохо с 3d. В багрепортах и в VMware Player были глюки — там медленно рисовались кадры с почти отсутствующей загрузкой CPU.

Спасибо. Я правильно понял:

она отключит XRender, который часто глючный

но при этом

ворастет потребление CPU

?

Да, в целом верно. Дело в том, что для поддержки прозрачности надо уметь накладывать RGBA картинку (с альфа каналом) на уже существующую RGB картинку. С XRender я загружаю RGBA в видеоадаптер и даю команду на смешивание. Саму операцию выполняет видеоадаптер. Без XRender нужно сначала RGB картинку скачать в обычную память, произвести смешивание, а потом закачать полученную картинку опять в видеоадаптер. Код не особо сложнее, основную работу делает Cairo, но потенциально по ресурсам это более затратно.

Теперь яснее, благодарю!