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

Читай спецификации.

Чисто в теории и на сотне мегагерцах должно тянуть при условии использования нежручего кодека и достаточной производительности диска.

Я на Athlon XP 2500 смотрел, хватало.

Для 720p хватает P4HT-2.4 Но с калкомом боюсь будет «ничего не поделаешь, это ненужноарм».

Т.е. ориентировочно, 2500 мегагерц, одно ядро? Гут. Получается, нынешние топовые квалкомы, тегра К1 и завтрашние медиатеки Х30 смогут тянуть 720p без проблем чисто на процессоре.

Для 720p хватает P4HT-2.4 Но с калкомом боюсь будет «ничего не поделаешь, это ненужноарм».

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

1800 емнип частота была у XP 2500+

1800 емнип частота была у XP 2500+

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

Сильно зависит от того, есть xv, или нет.

Не совсем без ускорения, но без ускорения декодирования.. К тому же 720p бывает разными кодеками пожато - от mpeg2 до hevc/vp9, и с разной частотой кадров.

https://www.youtube.com/watch?v=CNZZpdGK6aM

https://discourse.osmc.tv/t/pi-3-h265-playback-experience/14439/6

Просьба заметить, что html5 видео в браузере может быть куда тормознее того, что идёт через (флэш)плагин. К тому же, youtube сейчас на vp9 перешли - куда как более ресурсоёмкий для декодирования. Мой старый 1Ггц celeron в браузере только 144p (!) vp9 мог.

Дык, это ж будет полноценный онтопик. Можно будет и через (флэш)плагин запускать.

Где-то лежит ноут на Pentium M 2003 года выпуска. 1,6 ГГц, кажется. 720p тянул, 1080p - уже нет.

Я помню что 480p тянуло на pxa270 (arm начала нулевых). Вполне возможно что 720p вытянет та же малина

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

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

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

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

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

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

По теме:

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

Вполне возможно что 720p вытянет та же малина

RPi легко тянет, даже первая.

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. Это похоже криворукие программисты из мозиллы, что-то не так делают.

С аппаратным декодером хватит ARM11 и 324 МГц для 1080p

С аппаратным декодером хватит ARM11 и 324 МГц для 1080p

Речь как раз про программный

720p - даже крайние модели пентиум 4 в затык крутят с фреймдропом на сложных сценах. (смотря что за формат, что за кодек и т.д.)

в планшетах только аппаратный декодер и ничего больше.

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

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

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

720p - даже крайние модели пентиум 4 в затык крутят с фреймдропом в планшетах только аппаратный декодер и ничего больше.

Зато в планшетах до 4х ядер. Так что позвольте не разделить ваш пессимизм.

Так что, профессор, всё безнадёжно, и ютупчик в онтопике на 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

а плавучек/медиа блоков сколько? один на все потоки шареный?

видео в 720p

Нет такого видео. Это разрешение. Есть несколько популярных кодеков, у которых 100500 опций, которые очень сильно влияют на скорость декодирования.

Какой кодек?

Зато в планшетах до 4х ядер.

И все куцые.

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

на эппловском 4S тормозило 1080, но работало 720, в программном декодинге. Всё, что уровня топа 12-го года и новее должно тянуть.

Какой кодек?

Вот тут я послушал бы мнение зала. Мол, xvid - пойдёт, h.264 - нет.

а плавучек/медиа блоков сколько? один на все потоки шареный?

Хм, вы меня озадачили. Разве декодинг видео не является целочисленной операцией? Ну, если только с цветами баловаться...

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

Вот doom2, значит, вытягивают, а видео не смогут? А на батарейку пофиг, меня принципиальная возможность интересует.

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

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

(фантазирую)

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

Вопрос спорный. Ибо в Pentium-IV были 16-разрядные ALU, и ничего, при наличии достаточного количества этих ALU, получали длинный разряд.

Ибо в Pentium-IV были 16-разрядные ALU, и ничего, при наличии достаточного количества этих ALU

Там фишка была в том, что 16-разрадное ALU работало на удвоенной частоте, делая два сложения за такт не за счёт ширины, а тупо за счёт того, что его такты были в два раза короче. Синхронизация там не нужна.

Кстати, вы не помните, почему их было 2 штуки? Не смог найти в гугле.

почему их было 2 штуки?

Разве не 3? Два быстрых, на удвоенной частоте, для простых инструкций. И ещё один медленный, для сложных операций. Это не считая сумматоров там и тут для вычислений адреса, для счётчиков разных и тому подобного.

Pentium 4 — суперскалярный процессор, может запускать больше одной инструкции за такт одновременно.

Pentium 4 — суперскалярный процессор, может запускать больше одной инструкции за такт одновременно.

А, точно, вот для этого.

При чём тут дум? Вы сравниваете абсолютно разные сущности.

Вы не получите ответа на свой вопрос, ибо он задан не верно.