Comments 44
r5 1600 — 1094
i7 4770 — 690
i5 3570 — 510
e5 2650v2 — 966
=3260
Результат получился на уровне 12/24-поточного r9 3900x. Неплохо.
Думаю эта задача идеальна для 32 или 64-ядерного тредрипера.
rav1e и svt-av1 оптимизируются под AVX2, даже AVX-512 вроде пишут, всё остальное для них дело десятое, да и libaom скорее всего тоже нормально ускоряется за счёт AVX2.
Видеокарта — это тотже процессор. Он тоже гоняет биты туда-сюда, просто чуть иначе.
Но при этом у видяхи заметно больше ядер (CUDA/OpenCL).
Тоесть конечное качество видео зависит только от алгоритма.
если предположить что один SMX это «сервер» то можно и на 60 кусков разделить видео
В корне неверное утверждение, видимо у вас не так много опыта с кодированием на gpu. в отличие от cpu, видяха умеет перебирать гораздо больше вариантов за единицу времени и решать сложные математические вычисления на порядок быстрее. Я очень много времени потратил на изучение этого вопроса, и могу сказать что лучше результат по h264 получается на кодеке intel qsv. Причём если поставить там preset veryslow, то скорость он всё равно в разы обходит x264, а по качеству субъективно тоже получается лучше.
Что касается аппаратного кодирования av1, то на данный момент просто не существует такой реализации. Поэтому единственный вариант — cpu.
ffmpeg -preset medium -vcodec h264_qsv -global_quality 23 -look_ahead 1
против
ffmpeg -preset medium -vcodec libx264 -crf 23
QuickSync дает больший размер файла и чуть более мыльную картинку. К тому же не удалось запустить QuickSync c preset выше medium, в то время как там размер файла получается еще меньше для CPU.
Апаратные кодеки это не совсем GPU. Это отдельные модули, которые расположены рядом с GPU. Да Интеловский кодек как универасльный кодек неплох в соотношении качество/скорость. Но например AMD и Nvidia больше фокусируются на кодировании геймого стриминга, и как универсальные кодеки не очень. Также у железных кодеков значительно ниже возможности по тюнингу и генерации специфического битстрима. И некоторые возможности вообще остутвсуют.
Почему видео кодеки не ложатся на стандартные GPU, основная проблема это очень большое ветвление при принятии решений. Если же выносить принятие решений на CPU, то это требует транфер данных очень большого объема, который съедает все бенефиты GPU. Плюс у Интеловских процов есть маленький ньюанс они оперерируют энергопотреблением на уровне всего чипа, если GPU работает на полную катушку, то основной процессор замедляется, чтобы не превысить пределы энергопотребления.
Например тот же libaom рассчитывает векторы движения через весь кадр, плюс к этому использует по 6-8 референсных, плюс к этому вариантов деления блока в разы больше чем у h264 так же как и вариантов предсказания.
libaom на процессоре то очень плохо параллелится, даже на 4 потоках загрузка процессора в среднем 70-80%, на 16 потоках в 1080р вообще почти всё время будет загрузка не больше 50%, так о каких видеокартах тогда речь?
Видеокарты смогут быстро кодировать только если таким дроблением файла как в статье и то не факт, 100% будет использоваться половина или меньше вариантов блоков, так же векторы движения будут намного короче, а что с референсными я даже представить не могу.
Вы хоть раз открывали av1 поток в анализаторе? Видели какой там рандом в референсных кадрах творится? Да мне кажется тут легче будет сделать asic чем пытаться реализовать на cuda и openCL.
Да и много вы знаете кодеров на cuda/openCL которые не уступают x265-ому по качеству?
Пока что этот x265 бьёт по скорости/качеству кодеры av1.
Очень просто: в софтверном енкодере очень легко добавить новые алгоритмы и тп, это просто код. В железячном енкодере это не так просто сделать: при любых изменениях меняется весь модуль кодеков, это огромные затарты и время, поскольку все это должно пройти значительно болший путь (от верилога до чипа) нежели простое изменение кода в софтварном енкодере. Дальше, как обычно переносится в железо: берется софтварный енкодер в качестве референсного, упрощается до тех пор пока не дает расчетные результаты по качеству/нагрузке и тп. после этого портируется в железо. Достаточно часто полученный результат не влезает в чип (куча железячных ограничений по энергопотреблению, по количеству элементов и тп), тогда алгоритмы еще более упрощаются, и процедура повторяется. В результате софтварный енкодер может обеспечить лучшее качество/сжатие чем железячный.
ЗЫ. Железячный энкодер это все же не GPU, это модуль рядом с GPU.
К томуж некоторые умудряются через шейдеры выполнять произвольный код, а это какраз GPU.
CUDA и OpenCL (AMD) — это, строго говоря, тоже сама видеокарта.
И только энкодер x264 — отдельный микрочип. Который, впрочем, тоже активно пользует CUDA ядра.
Разве здесь не будет проблем на стыках кусочков? Кодеки ориентируются на ключевые кадры и декодируют следующие кадры на основе КК.
Порезав на куски без учёта КК вы не мешаете кодировщику оптимизировать видеопоток? Есть ли разница в размерах конечных файлов при кодировании здорового человека в один инстанс и кодировании курильщика в вашей распределённой системе?
А какой был оригинальный размер в h.264?
source.mkv — исходник
encoded.mkv — кодирован целым
encoded_join.mkv — кодирован по кускам
Разница 200к
Я делал подобную систему несколько лет назад: habr.com/ru/post/218063
HEVC давно устарел
Это когда он успел устареть? В промышленных масштабах он появился только в конце 2017 года в iOS 11 и iPhone 8/X. И через полгода на Galaxy S9.
То, что происходило ранее в 2014-2016 годах трудно считать широким распространением, потому что в быту с ним можно было скорее всего встретиться пожалуй что на 4k Blu-Ray
Сейчас же железо подтянулось
Оптимистично сказать «подтянулось» можно, пожалуй, для разрешения FullHD — там можно получить скорость кодирования выше real-time. Но для 4k скорость кодирования будет где-то в районе real-time (ну может на 2000-й серии GeForce пошустрее, но у меня такой карты нет). Так что железу ещё есть куда подтягиваться.
На десктопе AV1 будет интересно и целессобразно крутить (кодировать) не раньше появления аппаратной поддержки в CPU — то есть в конце этого года с появлением Intel Tiger Lake. С учетом скорости проникновения реально говорить о широком практическом использовании (то есть не только воспроизведении) AV1 можно будет года через 3.
По поводу будущего AV1 — тут еще много вопросов :) народ пишет стандарты во всю: VVC, EVC, LCEVC, скорее всего есть еще. Но мне кажется, что AV1 это больше продолжение VP8/VP9 в плане использования. Те он займет определенную нишу. Но сказать, что только за ним будущее… не уверен.
Для примера одна из проблем внедрения HEVC (лицензионные проблемы оставим в стороне) это значительно большие требования к аппаратным ресурсам. В среднем HEVC дает 30% в сжатии при том же качестве, но при этом требует в два-три раза более мощное железо. А это расходы которые не всегда окупаются снижением расходов на канал. C AV1 сейчас происходит тоже самое, что и в юности HEVC (и юности H264). Пока не появятся реальные софтварные енкодеры/декодеры, а потом и железячные с приемлемыми характеристиками это будут просто игры: поднятие хайпа, надувание щек и тп. Причем для AV1 и всех остальных кодеков ситуация усугубляется тем, что реальное улучшение сжатия будет меньше чем между HEVC и H264, а вычислительные ресурсы будут требоваться значительно большие.
Ну и еще один момент — H264 до сих пор не умер, и до сих пор развивается :) еще много клиентов которые приходят за H264-ым, которым нужен high-density. И енкодер это не только умение использовать стандарт кодирования, это умение избегать артифактов кодирования, коих очень много, и это головная боль любого енкодера.
ну так H265 и даёт 50% экономии по сравнению с H264, но он по вашему давно устарел.
а на моей практике просмотра мультиков и съёмки всевозможных видео на айфон разница между 264 и 265 как раз 2 раза по объёму при визуально одинаковом качестве изображения
сократив в 2 раза
я два комментария подряд это и говорю
У меня например redmi note 8 pro, у него h265 плохой и я это сразу вижу, по анализаторам тоже видно что он обрезан очень сильно, тогда как h264 обрезан не так сильно.
Но похоже это только я так вижу, много раз пытался доказать это другим, но без толку, люди где-то увидели что h265 на 30% лучше и всё и их не переубедишь и им ничего не докажешь, у них h265 априори не может быть хуже чем h264 и всё тут.
А прикол h265 кодера в redmi note 8 pro в том, что он использует только блоки 16х16 всегда, во всех кадрах, ну и трансформацию 8х8 местами.
А h264 использует блоки от 16х16 до 4х4, плюс в P кадрах использует ещё прямоугольные и трансформацию от 8х8 до 4х4, но для всех это пустой звук, один мне вообще сказал что в h264 блоки только 16х16 и никакие другие и это был разработчик хорошей камеры на андроиде mcpro24fps.
С av1 всё +- так же, все сравнения качества нетфликсов, фейсбуков и ещё кого сделаны при использовании libaom с
cpu-used 1 или вообще 0 и сравнивают с h264, который в лучшем случае закодирован через x264 с пресетом medium, с h265 так же.Ведь если взять топовый h264 и топовый h265 то всё не будет так радужно и однозначно, а когда сравниваешь топовый av1 с не топовыми другими, то конечно выйгрыш большой.
Хотелось бы увидеть сравнения качества.
У меня нету мощного железа, поэтому всё что я сравнивал это отрезки по 2-5 секунд закодированные с CRF или QP при одинаковом размере файла.
Так вот что получилось.
rav1e по качеству только чуть-чуть лучше чем libvpx-vp9 при скорости кодирования в 2-5 раз меньше.
svt-av1 вообще не даёт нормальное качество при таких же скоростях кодирования.
libaom пока что самый качественный, но он медленнее даже на самом быстром пресете, а та разница в 50% про которую везде говорят, она только с стандартным пресетом, который раз в 6-8 медленнее быстрого.
Мой вывод:
На данный момент x265 даёт сравнимое качество с rav1e и libvpx-vp9 при такой же или большей скорости кодирования, а libaom очень медленный.
Так же сам av1 хорошо подходит для мультиков, потом уже для фильмов и хуже всего для игр, в играх x264 пока что не обогнать.
Ну буду смотреть что покажет h266, он вроде должен работать с играми.
Проц у меня i5-2520m, поэтому на новых процах с AVX2 скорости могут быть совсем другие и тут svt-av1 может сыграть, да и rav1e ускорится сильно.
AMD процы лучше 3000 серии, в 1000, 2000, обрезаный AVX2 и это сразу видно. Интел же 6000 серии и новее.
С процами без AVX2 пока что x265 быстрее при том же качестве и это вряд-ли изменится, так-как кодеры оптимизируют под AVX2, а rav1e и svt-av1 вроде даже под avx512
А ностальгия :)))
2014-2016 годы: Первые "оптимизированные" кодеки HEVC дают от 4-х фпс и ниже на стандартных 4-х 3GHz Haswell корах. Референсный код давал меньше 0.1 фпс.
Пишем Multi-Nodes encoder (встраивается в транскодер), который разбивает входной стрим на чанки, и кодирует/транскодирует их на отдельных машинах(нодах). Причем может работать как в файл-ту-файл сценариях так и в реал-тайм стрим сценариях, естественно с учетом задержки (длинна чанка умножненная на количество нодов). С кучей доп возможностей: автодетект нодов, группирование нодов, приоритеты задач, авто перекодирование чанка если нод ушел в даун, использование разных транспортов, включая шаренныей файлы, двух проходное кодирование и куча еще всякой фигни. В 2016 году на NAB-е демонстрировали 4K кодиование на HP Moonshoot (сколько использовали нодов не помню уже), достигли 137 фпс в пике.
Наш фреймворк в тот момент поддерживал кучу платформ включая Android и iOS. И все время было желание показать возможности энкодера использовав весь железячный хлам который у нас был (планшеты, мобильные телефоны, старые компы и тп), но все как-то руки не дошли.
По поводу склейки частей: как оказалось для некоторых сценариев это вообще не проблема. для примера весь стриминг через Web крошит стрим на небольшие фрагменты/сегменты в 1-10 секунд. Плюс требование к рандом навигации в 1 секунду отодвигают проблему склейки на задний план.
Но время идет… кодек дооптимизировали, железо стало сильнее, мультинод енкодер стал неактуален. Теперь 8K@60 4:2:2 кодируем на одном AMD EPYC 7002 сокете :)
В общем через какое-то время AV1 будет лучше оптимизирован, и распрараллеливание по чанкам будет не нужно :)
а зачем вы копаете мертвеца если все проблемы решили в h266?
Эти level 6 в h264 появились поздно и вряд-ли теперь кто-то будет под них делать, а софтово декодируется не зависимо от левелов, в теории можно хоть 16к кодировать/декодировать софтово.
Есть еще вот такой проект: github.com/m-ab-s/media-autobuild_suite
Нужно просто запустить батник, выбрать нужные параметры и он скачает все необходимое для сборки и соберет под Windows. Потребует прилично места на диске (не ожидаешь, что 100кб скрипт потом скачает и набилдит на 25ГБ). Но у такого билда есть преимущества, можно включить в ffmpeg несвободные кодеки, вроде libfdk_aac, или включить тот же rav1e сразу в ffmpeg
Мощь множества ядер для укрощения кодека AV1