купить, скачать, да дрочить

Гугл же и сделал свой линукс с шлюхами и со всем этим. Ну там только Intel

ЛОЛ, что?!

Что, ты даже не знаешь, что гугловский линукс со шлюхами на Gentoo базируется?

А твой парень наверняка знает.

Android - на Gentoo? И Штеуд исключительно? Нет пути.

А твой парень наверняка знает.

он уже давно мне не парень

Речь у миловидной миниатюрной единорожки шла про Chrome OS.

но она тоже умеет несколько платформ

Уже запилено в хромиуме с патчем ваапи. В федоре он уже в апстриме по дефолту судя по новостям. Единственно, что в флагах скорее всего надо это включать ручками, плюс на вейланде не работает, также в нвидии нет нативного ваапи и все это через костыли будет, а в амд нет вп9 ускорения. У меня работает ускорение h264 под федорой, т.е видео жрет процентов 10 процессора, вместо 30-50, на амдгпу, в сборке хромиума от рпмфюжн, федоровскую дефолтную сборку не пробовал, без возни с флагами был зелёный экран в видео, пришлось включить много казалось бы ненужного в флагах, вроде viz композитора.

Уже запилено в хромиуме с патчем ваапи. В федоре он уже в апстриме по дефолту судя по новостям.

Во. решил я в Ubuntu попробовать. Ситуация плохая, ибо Nvidia у меня

sudo apt install vdpau-va-driver
sudo snap install --channel=candidate/vaapi chromium

Video Acceleration Information
Log Messages
[14755:14755:0131/224731.982157:ERROR:vaapi_wrapper.cc(324)] : vaInitialize failed: unknown libva error
[14755:14755:0131/224738.973645:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[14755:14755:0131/224748.721011:WARNING:x11_util.cc(1394)] : X error received: serial 1962, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[14755:14851:0131/224748.740655:WARNING:x11_util.cc(1394)] : X error received: serial 1004, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[14755:14755:0131/224857.437146:WARNING:x11_util.cc(1394)] : X error received: serial 4776, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[14755:14851:0131/224857.917674:WARNING:x11_util.cc(1394)] : X error received: serial 2447, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)

Примерно этого я ожидал.

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

Ну так выше же

sudo apt install vdpau-va-driver

Другого не бывает. Я его раньше использовал (точнее пытался) с VLC до версии 2.1, когда у них не было VDPAU.

Результат был такой, что проще было забить...

the general lack of quality of drivers (in particular on Linux)

Фигня. Я вот ковырял дрова на Linux-е, ничего особенного, кроме падения производительности на 15% на некоторых задачах по сравнению с виндой в них нет.

Думается, проблема где-то в архитектуре браузеров закопана.

Опции управления качеством/субтитрами/языковыми дорожками, недоступные в mpv

Там всё доступно, но через жопу.

У тебя ширина канала меняется посреди воспроизведения? Эта штука и в онлайн-плеере работает глючно: либо играется дальше из кэша в уже загруженном качестве некоторое время, либо воспроизведение замораживается, чтобы подгрузить в новом. Нафиг такое.

У меня да, правда канал гигабитный и я этого не замечаю. Но у меня дома канал разбивается на 11 устройств, которые вполне могут его использовать одновременно и автоматически, цепляясь к разным серверам. Да, трафика в день жрется 14 гигов в среднем, это без всяких торрентов и прочих файлокачалок. Только видосиками и обновами (все устройства разные, обновы тоже разные).

А можно было бы просто ffmpeg использовать для этого на всех платформах и всё бы просто работало.

Нужно было, но не захотели.

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

Там всё доступно, но через жопу.

То есть я могу открыть свой любимый сериальчик Пердящие Домохозяйки через youtube-dl и переключить звуковые дорожки нативно?

Немного побродил по коду, но так и не осилил найти, где используется GPU_FEATURE_TYPE_ACCELERATED_2D_CANVAS. Он встречается в чёрных списках, ещё в одном месте проверяется. Но в той ветке тоже тупик.

я на досуге ковыряю vaapi для фаерфокса. для меня основной проблемой является многопроцессорность фаерфокса (декодирование видео и рендеринг находятся в разных процессах) и то что в opengl нету способа расшаривать opengl текстуру между процессами. подробности для !Ъ https://gamedev.ru/code/forum/?id=240911 теоритически весь нужный мне функционал есть в вулкане, но его поддержка только в очень далеких планах..

Да. клавиша # в помощь. (Shift+3)

Да. клавиша # в помощь. (Shift+3)

Не-не, то, что mpv сам по себе это умеет, я знаю. А в youtube-dl? Он дейсвительно скачивает все дорожки и субтитры?

«Огроменный оверхед» это сколько?

но так и не осилил найти, где используется GPU_FEATURE_TYPE_ACCELERATED_2D_CANVAS. Он встречается в чёрных списках

Какой вердикт? Canvas ускоряется аппаратно или нет?

Собранных данных недостаточно для вынесения вердикта.

Я очень много работал с Canvas на Android. Там он действительно аппаратно ускорен (при соответсвующий настройках и применении).

Вроде Android это Linux.

А в youtube-dl

Я им не пользуюсь, он мне без надобности.

Фигня

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

И деньги MS с Apple платят, чтобы под линуксы похуже софт писали 🙂

Всё же ясно... тебе.

ещё в одном месте проверяется

https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/graphics/gpu/graphics_context_3d_utils.cc?l=90

Ты про это место?

Я вот ковырял дрова на Linux-е, ничего особенного, кроме падения производительности на 15%

Что ты ковырял? Пробежал про проложенной кем-то с приличными затратами дорожке. Молодец.

Ты не понимаешь, что качество (без глючность) и скорость — это как-то не напрямую связанные вещи?

Не течёт вода под камень. В программировании не бывает, что склеил легко разные куски - и всё заработало.

И браузерописатели этого не делают ни потому что им кто-то заплатил не делать, а потому что никто не заплатил это делать.

Выгода / Трудоёмкость = целесообразность выполнения задачи

Ты про это место?

Ага.

ибо она обновляется быстрее

Я знал что в десяточке всё не очень, но чтобы настолько? Оо

Согласен.

Сам во многих проектах был напрямую связан с визуализацией в приложениях. Интерфейсы приходилось разрабатывать. Это адов труд чтобы увзять отображение для пользователя с актуальным внутренним состоянием ядра и базы данных. Так чтобы само переформатировалось, ничего не «полезло», вовремя появилось или исчезло. К тому же чтобы не оторвало глаза пользователю.

Брузеры в этом плане ахренедь сложная штуковина с сотнями параметров на каждый визуальный элемент, которые влияют на сотни элемнтов вокруг с их же сотнями параметров.

Визуализация всегда было самым сложным в разработке программного обеспечения. Ну после СУБД конечно. Хотя ХЗ...

Наверное поэтому большинство красноглазиков на ЛОРе предпочитают программировать только консольные приложения с выводом результата только в тектовый файл. И любят только ascii и koi8-r :)

Не потому что это кульно, а потому что не могут потянуть разработать нормальный визуальный интерфейс.

Выше уже отписали в чем причина - композитор (тот который в браузере) нормальный написать не могут, т.к. мозгов и человекочасов не хватает.

Там когда-то было написано «Video Decode: Hardware accelerated» и «Video Encode: Hardware accelerated», что на тот момент было абсолютное враньё.

У меня и сейчас написано. Последний хром, только что прилетел.

Отдельным окном сейчас можно сделать используя mpv+youtube-dl

Такое отдельное окно мне ненужно.

нагрузку цпу мерил топом одно и то же видео на ютубе 1080p60fps в софтваре процесс декодера: 80%, процесс рендера: 20% vaapi прототип процесс декодера: 45%, процесс рендера 35%

процесс декодера стал меньше кушать цпу, но все равно много ибо здесь я лишь отсылаю кадры на декодирование в vaapi драйвер, создаю внутрение объекты для коммуникации между процессами и отсылаю инфу о декодированных кадрах на рендер процесс. причем это все каждый кадр. процесс рендера стал кушать только больше, т.к. там каждый кадр создается и уничтожается опенгл текстура.

первостепенной моей целью является уменьшение энергопотребления при посмотре видео за счет аппаратного декодирования. мой прототип хоть и выигрвает у софтвара, но очень не много (mpv в этом плане работает куда лучше). к слову в хроме аппаратное декодирование сделано очень топорно и если цпу он поедает и меньше, то общее энергопотребление точно не уменьшилось (тестил на своем ноуте).

Мешает отсутствие универсального композитного менеджера для отрисовки видео поверх контекста страницы.

Когда-то давно (а может и сейчас можно, но хорошо спрятано) просто назначить плеер, например, mplayer или сейчас mpv для воспроизведения видео, даже не обязательно поверх контекста.

Суть в том, что страница отрисовывается одним движком, а обработка видео аппаратная сейчас производится другим.

Получается, что суть в том, что поломали unix-way. Воспроизводить контент на странице должен был бы просто плеер, тот же mpv и все. Координаты окна (чтобы менять в процессе прокрутки страницы) и номер X-экрана для вывода могли бы через сигналы передаваться. Чем плохо? Ах да, в этом случае уж слишком просто было бы сохранять видео со страниц, а тут копирастия потихоньку пролазит во все щели, даже в OpenSource.

В своё время, нетбуки ASUS EEE PC на линуксе поставлялись как с Windows, так и с Linux. Я уверен, что Microsoft занесла чемоданы денег кому надо, чтобы видео в браузере не ускорялось аппаратно. Ничем иначе не объяснишь то, что даже на Raspberry Pi это работает, но на десктопном линуксе - нет

А вообще, попробуй PPA с браузером ungoogled-chromium. Кстати, куда он делся?

даже на Raspberry Pi это работает

Что именно работает на Raspberry Pi? Аппаратное ускорение декодирования видео вообще или аппаратное ускорение декодирования видео в файрфоксе?

Какой-то бред...

https://www.raspberrypi.org/forums/viewtopic.php?t=176020

HW accelerated browsers (chromium-browser, epiphany, kweb3) can use HW decoding by the GPU, but the decoded video has to be copied back into the frame buffer to become part of the browser window. And this is not simply copying a huge amount of data, but includes a colour space conversion (some kind of YUV to RGB(A)) as well. This means, that HW accelerated video inside browsers is only possible within a limited screen area - a typical youtube 360p video, for example) and never full screen (or covering a large part of the screen).

Как уже несколько раз говорилось выше. Таскание туда-сюда и преобразования не нивелируют GPU декодирование почти в ноль.

А всё ни потому, что кто-то занёс чемоданы денег, чтобы не делали, а просто потому что не занесли чемоданы, чтобы делали.

Вот объясните же мне наконец, зачем _браузеру_ _декодировать_ _видео_? Для декодирования видео штатный плеер есть, который всегда делал, делает и будет это делать в 100500 раз лучше любого браузера. Дело браузера - лишь отдать сцылку плееру. В идеале - отдать системному плееру поток через stdin например, чтобы не нужны были эти бутерброды с ytdl. Вот зачем вся эта глупая детская возня с декодированием видео в браузере, если один хер ставишь какой-нибудь «Open in ...» и запускаешь видео через ytdl + mpv?

Мда. Как-то не особо обнадёживает. К тому же, как я понял, у тебя решение Wayland-only?

у тебя решение Wayland-only?

да, но мне нужен не столько вайланд сколько egl, а его для иксов не завезли.

* в иксовую реализацию фаерфокса

Ну так-то можно и прокинуть, всё равно ведь C++ код патчится. Другой вопрос — стабильность и адекватность EGL под иксами. В 2015 у меня от EGL интеловский драйвер систему залочил наглухо.

Chromium-71.0.3578.98

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Hardware accelerated
Rasterization: Software only. Hardware acceleration disabled
Skia Deferred Display List: Disabled
Skia Renderer: Disabled
Surface Control: Disabled
Surface Synchronization: Enabled
Video Decode: Hardware accelerated
Viz Service Display Compositor: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

Ты определился с Canvas? Или дальше будешь тулить, что якобы написано фигня, но ты типа самый умный и всё решаешь?

Ты определился с Canvas?

Хватит ныть. Открой код и посмотри сам.

Иди в попу. Ты нагнетаешь вокруг себя Мрак что ты типа гуру по всему. Обсераешься постоянно. Могу привести ссылки если захочешь.

Да! Canvas hardware accelerated.

Короче. Не выделывайся. И изучи матчасть. Школнег млять.

Могу привести ссылки

Свежо предание, а верится с трудом.