Какой производительности (частота*кол-во ядер) должен быть процессор для воспроизведения видео в 720p?

Просьба заметить, что html5 видео в браузере может быть куда тормознее того, что идёт через (флэш)плагин.

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

Никогда не мог понять, почему не использовать системный ffmpeg для декодирования(хотя бы в линуксах)

А так можно? Технически, как это делается?

Можно, но для этого нужно браузеры немного переписать.

Или ты хочешь кусок кода для работы с ffmpeg?

По теме:

Pentium-200 хватало в лучшем случае для VCD, а уже у софтовых DVD-проигрывателей системные требования - от Celeron 300. И это разрешение всего лишь 576р вроде бы и кодек мпег2, который сильно менее требовательный, чем мпег4, про hevc наверное можно и не упоминать, его на софте чтобы тянуть нужен очень не слабый проц.

Pentium-200 хватало в лучшем случае для VCD

divX 640x480 вполне можно было смотреть

Никогда не мог понять, почему не использовать системный ffmpeg для декодирования(хотя бы в линуксах),

Firefox ищет в системе ffmpeg или libav, пытаясь загрузить libavcodec-ffmpeg.so.57, libavcodec-ffmpeg.so.56, libavcodec.so.57, libavcodec.so.56, libavcodec.so.55, libavcodec.so.54 или libavcodec.so.53. Видео декодируется им. Chromium при сборке обычно линкуют с системным libavcodec. В Chrome раньше таскали за собой свою сборку ffmpeg только с LGPL кодом, сейчас не знаю.

Эти браузеры довольно давно используют FFmpeg. Причём Chromium начал это делать ооочень давно. Возможно, он с FFmpeg и начал.

А почему тогда тормозит то так? Ну точнее будет не тормозит, а процессор грузит, даже при хардварном декодировании. И также непонятна ситуация, где этот кодек поддерживаем, а этот нет, тогда ведь, если ffmpeg поддерживает, то и браузер должен.

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

Но даже так. У меня mpv при проигрывании 1080р с софтварным декодированием, жрёт 10-20% процессора, а в браузере до 60-8030-40%(проверил) доходит.

А почему тогда тормозит то так?

Потому что браузеры архитектурно на порядок сложнее плееров.

У видеоплеера одна задача — показывать видео. Всё рабочее пространство окна плеера занято видео. Например, MPlayer пользуется (пользовался) возможностями аппаратного оверлея, в который можно писать картинку в YUV, не тратя время на преобразование в RGB на процессоре. Одновременно блок поддержки оверлея на видеоадаптере ещё и картинку масштабирует.

В браузере всё сложно, потому что видео — равноправный HTML элемент страницы. Основной путь рисования — сложный и медленный.

В браузере всё сложно, потому что видео — равноправный HTML элемент страницы. Основной путь рисования — сложный и медленный.

Так что, профессор, всё безнадёжно, и ютупчик в онтопике на arm мы так и не сможем смотреть, кроме 480p?

В браузере всё сложно, потому что видео — равноправный HTML элемент страницы. Основной путь рисования — сложный и медленный.

А почему тогда во флеше всё то же самое работало быстро? Флеш как раз (приблизительно) со скоростью mplayer работал. Да и сейчас работает, если запустить. Проверил. В Хроме и сейчас html5 рабоатет со скоростью(загрузкой процессора) mpv. Это похоже криворукие программисты из мозиллы, что-то не так делают.

Например, MPlayer пользуется (пользовался) возможностями аппаратного оверлея, в который можно писать картинку в YUV, не тратя время на преобразование в RGB на процессоре. Одновременно блок поддержки оверлея на видеоадаптере ещё и картинку масштабирует.

а можно поподробнее, это иксами, опенжээлем или чем предоставляется?

Так что, профессор, всё безнадёжно, и ютупчик в онтопике на arm мы так и не сможем смотреть, кроме 480p?

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

а можно поподробнее, это иксами, опенжээлем или чем предоставляется?

Это же XVideo (xv). Раньше использовался специальный блок, который выводил непосредственно в видеосигнал, из-за чего на скриншотах вместо кино был зелёный или чёрный прямоугольник.

Так что, профессор, всё безнадёжно, и ютупчик в онтопике на arm мы так и не сможем смотреть, кроме 480p?

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

Да, но это с аппаратным ускорением. А если мы в условиях отсутствия оного? По условиям у нас планшет, дров нет.

В Хроме и сейчас html5 рабоатет со скоростью(загрузкой процессора) mpv. Это похоже криворукие программисты из мозиллы, что-то не так делают.

Ну не с той же, всё же чуть больше. Но намного лучше, чем в Firefox, да. У меня на видео 720x404 mpv ест 15-20%, Chrome ест 20-30%, а Firefox 50-60%. Это есть частоту процессора зафиксировать. Без этого при запущенном Chrome частота выше, чем только с mpv, и CPU% действительно примерно равные.

аа, понятно

а как его заюзать можно в двух словах? :)

А если мы в условиях отсутствия оного?

Спекулировать можно до скончания времён. В итоге всё равно всё решит эксперимент.

а как его заюзать можно в двух словах?

Набираешь в гугле xvideo, смотришь прон. Я не в курсе, использующий его код не писал. Смотрел когда-то на него ради перевода YV12 в RGB, но осознал, что это либо не сработает, либо будет медленнее libswscale, и забил. При надобности начал бы с https://linux.die.net/man/3/xv

Вчера сломался любимый сервис для вытаскивания прямых ссылок на трансляции, вспомнил данный пост, посмотрел в Хромиуме. За что весьма благодарен.