Comments 6
Какие-то сомнительные результаты. Навскидку, битрейт зависит от количества I-, P-, B- кадров. А об этом я что-то не вижу инфу. Т.е. для получения сравнимого результата как минимум нужно выровняться по параметрам полученного битстрима.
Насколько я понимаю - Вы просто сравнили дефолтные настройки для сферической задачи в вакууме. У того же QSV (он же MediaSDK, он же oneVPL) есть вагон разных крутилок и тот же lookahead, например.
Да и почему статья называется «…транскодирование», а речь про энкод? С транскодированием все гораздо интереснее, когда нагружаются и аппаратные декодеры и нужно правильный мультитрединговый пайплайн строить для получения максимального результата.
Навскидку, битрейт зависит от количества I-, P-, B- кадров
Вы правы. Такая зависимость есть. Но я бы детализировал. Например, при наличии возможности использовать B-frame'ы можно снизить битрейт с фиксированным качеством.
В RKMPP нет реализации B-frame'ов - и сравнивать его с libx264 или NVENC с настройками, которые их используют бессмысленно. Очевидно, что выигрыш у последних будет 50%-70% по битрейту. Т.е. исследование здесь про LL режим, стриминг. Возможно, я не акцентировал на этом внимание.
В приведённых параметрах кодирования как раз можно увидеть что было сделано, чтобы можно было сравнить результаты кодирования. По наличию I и P: I каждые 50 кадров, всё остальное - P.
есть вагон разных крутилок и тот же lookahead
Крутилки-то есть, но предсказуемо работать они напрочь отказывались. Поделитесь рецептом какие параметры QSV на диапазоне целевых битрейтов будут оптимальными - я пересоберу данные.
lookahead неприменим по озвученной выше причине, он не для стриминга.
Про транскодирование. Оценка качества кодирования - это всегда часть с кодированием. Декод не влияет на качество. Для этого даже специально проверена корректная работа декодеров для всех реализаций. И статья названа так, потому что она затрагивает и декод в этой части тоже.
Согласен, что строить правильные пайплайны важно. Но до постройки необходимо знать, что будет получено в плане качества на выходе.
Поясню сразу и по второму комментарию
таблица поддержки энкодеров неполная
Верно. Задачи полного перечисления всего, что поддерживается не было. Это пример во вводной части про стандарты и их реализации.
Базой были сэмплы: sample_encode в Вашем случае. А там уж и настроить все остальное можно. Кстати, а куда пропала интеграция в ффмпег? Раньше была 100%. Но я бы не рекомендовал :)
В сэмпле можно порулить, например, разными контролами битрейта, на любой вкус: -vbr, -icq, -qvbr, -avbr… дока в помощь: https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/readme-encode_linux.md А вообще главное не забыть включить lowpower, который про аппаратное ускорение, тк были в тч софтовые реализации алгоритмов.
Кстати в командлайнах у Вас такое ощущение, что для одних - vbr, для других - cbr
Далее полученные стримы надо чем-то открыть и убедиться, что всё одинаково в плане фреймов. Рекомендую VQ Analyzer для целей анализа стрима. Я бы не сильно доверял «пожеланиям» настроек тк они могут быть перезаписаны.
И после подтверждения, что результаты совпадают - уже сравнивать качество. И кмк лучше сравнивать одинаковые фреймы, ессно. Ну те на таком-то видео I-фреймы заняли Х кбайт и дали такую-то RD-curve, P-фреймы…
Отметать lookahead «из-за стриминга», при этом не рассматривая транскодирование - крайне странно, тк на плохой синхронизации или неожиданном копировании памяти можно потерять куда больше. Да и вообще - это какому такому стримингу, не считая стриминга игр по локальной сети, есть дело до задержки даже в секунду?.. Ну опять же, тогда надо добавить в сравнение latency на фрейм. Я, конечно, дико извиняюсь, но если энкодер работает, например, в два раза дольше, и при этом результат всего на 10% лучше - вопрос ещё что важнее и корректность соавнения.
А, кстати, о каком фпс вообще идёт речь? Между, например, 25 и 60 фпс - пропасть…
Не знаю что они там в недостаток записали у qsv, но ffmpeg в docker через vaapi и qsv нативно в jellifyn поддерживается. Ещё стоит упомянуть что nvidia ограничена в потоках на декодирование в игровых картах. Рк вообще прекрасный вариант для замены смарт тв без ютуба на тв с приставкой и рабочим ютубом без реклам и шпионажа от самого тв.
И кстати таблица поддержки энкодеров неполная, вот из описания Intel VPL (он же…):
Supported video encoders: HEVC, AVC, MPEG-2, JPEG, VP9, AV1
И в репозитории libVA (линуксовый интерфейс) заголовки для соответствующих энкодеров имеются: https://github.com/intel/libva/tree/master/va
Сравнение технологий аппаратного транскодирования