Hevc тормозит на компьютере
С приходом тяжеловесных видеоформатов, таких как 4K (Ultra HD), проблема эффективности декодирования видеопотока стала достаточно актуальной. На среднем компьютере приходится принимать специальные меры для того, чтобы можно было обработать такой видеопоток в реальном масштабе времени. В статье рассказывается о возможных способах увеличения скорости декодирования видеопотоков в решениях, основанных на FFmpeg, и приводятся результаты экспериментов по измерению скорости декодирования для 4K видеопотоков, закодированных в H264 и HEVC(H265).
Мы будем рассматривать три способа повышения скорости декодирования видеопотока.
- Подключение дополнительных рабочих потоков (threads) в стандартных декодерах.
- Подключение аппаратного ускорения (HW Acceleration) в стандартных декодерах.
- Использование специальных декодеров, реализующих декодирование на графических процессорах.
Первый из них использует исключительно возможности CPU, а два других задействуют возможности графических процессоров.
Доступные способы повышения скорости декодирования видеопотока достаточно сильно зависят от используемой операционной системы, аппаратной конфигурации компьютера и конфигурации FFmpeg. Все приведенные в статье результаты проверялись на следующей программно-аппаратной конфигурации: операционная система — Windows 10, ЦП — Intel i5 8400 2.80 ГГц (6 ядер без hyper-threading), встроенный графический процессор — Intel UHD Graphics 630, память — 16 ГБ, сборка FFmpeg 4.2.1, с zeranoe.
Для лучшего понимания архитектуры кодеков в FFmpeg можно посмотреть предыдущую статью автора, которая находится здесь.
1.3. Использование специальных декодеров, реализующих декодирование на графических процессорах
В состав FFmpeg входят два семейства кодеков, реализующих кодирование и декодирование на графических процессорах.
Одно семейство использует технологию Intel Quick Sync Video (QSV), реализованную на видеопроцессорах, интегрированных в процессоры Intel семейств i3, i5, i7, i9. Подробнее см. [1]. Эти кодеки имеют суффикс _qsv . В рассматриваемой сборке FFmpeg есть следующие декодеры: h264_qsv , hevc_qsv , vp8_qsv , mpeg2_qsv , vc1_qsv .
Другое семейство использует технологии NVDEC, NVENC реализованные на платах Nvidia. Декодеры имеют суффикс _cuvid . В рассматриваемой сборке FFmpeg есть следующие декодеры: h264_cuvid , hevc_cuvid , mpeg2_cuvid , vc1_cuvid , vp8_cuvid , vp9_cuvid , mjpeg_cuvid , mpeg4_cuvid .
После открытия входного потока доступ к декодеру обычно реализуется следующим образом:
Но таким образом можно получить только декодер по умолчанию для данного идентификатора кодека. Для альтернативных декодеров нужно использовать имя декодера примерно таким образом:
Для использования альтернативных декодеров в командной строке надо использовать опцию с ключом -c:v расположив ее перед ключом -i примерно таким образом
Для экспериментов по измерению скорости декодирования были выбраны два видеоролика, один закодирован в H264, другой в HEVC(H265). Размер кадра — 3840х2160 (Ultra HD), скорость — 30 к/с. Тестировались стандартные декодеры — h264 , hevc и соответствующие QSV декодеры — h264_qsv , hevc_qsv . Стандартные декодеры настраивались в 4х вариантах: по умолчанию, два рабочих потока, четыре рабочих потока, аппаратное ускорение dxva2 . В наших экспериментах dxva2 показал лучшие результаты, чем d3d11va , поэтому последний не участвовал в измерениях скорости декодирования. Для проведения тестов была написана программа которая извлекала пакеты из файла и декодировала их с максимально возможной скоростью, игнорируя метки времени и не выполняя рендеринг или иную обработку. Было два режима этой программы: в первом выполнялось только декодирование, в втором еще производилось конвертирование декодированного кадра в 32-битный формат BGRA с использованием библиотеки libswscale . (На выходе декодера кадр обычно имеет 12-битный планарный формат YUV420P или NV12 .) Проводилось измерение времени, затраченного программой, и фиксировалось относительное время по отношению к номинальной длительности видеопотока (в процентах). Таким образом, если результат меньше 100%, то у нас есть шанс обработать видеопоток в реальном масштабе времени, если больше, то таких шансов нет. Также с помощью Диспетчера задач фиксировалась примерная загрузка ЦП и графического процессора. Использовалась 64-битная сборка FFmpeg.
Большого обсуждения результаты, наверное, не требуют. Единственно на что стоит обратить внимание — это заметные затраты на преобразование в BGRA . И главное, что эти затраты сильно меняются в зависимости от тестовой конфигурации, хотя работа во всех случаях выполнялась очень близкая.
Эксперименты проводились также для 32-битной сборки FFmpeg. Результаты довольно близкие, кроме одного случая: декодер hevc в конфигурациях без аппаратного ускорения показал падение производительности в 2-3 раза. Весьма неожиданный результат.
Описанные тесты можно выполнить в командной строке. Надо использовать глобальную опцию -benchmark и установить нулевой выход. Вот несколько примеров:
На выходе будет показан фактический fps , а параметр speed покажет во сколько раз он выше номинального. Если не задана опция с ключом -threads или для N указано специальное значение auto , то декодер использует максимально возможное число потоков, загрузка ЦП при этом 100%.
В рассматриваемой сборке FFmpeg есть следующие QSV декодеры: h264_qsv , hevc_qsv , vp8_qsv , mpeg2_qsv , vc1_qsv . Два последних оказались неработоспособными. Декодер mpeg2_qsv выдавал искаженную картинку, а vc1_qsv выдавал ошибку при передаче пакета на декодирование. Правда, эти декодеры не особо актуальны, но, все-таки, зачем выкладывать неработоспособные компоненты, не вполне понятно.
К оставшимся декодерам тоже есть претензии. В целом они работают, за исключением одного момента — они некорректно отрабатывают вызов avcodec_flush_buffers() . Ошибки нет, но после этого вызова позиционирование работает некорректно.
Подобные статьи, в которых мы тестируем всевозможные платформы на предмет воспроизведения HD-видео различных форматов, постепенно становятся привычным дополнением к тестированию процессоров и графических ускорителей по традиционной методике. В прошлый раз под прицелом оказались настольные процессоры Intel и AMD различных поколений. На этот раз мы решили изучить способности аппаратных декодеров у обновленных бюджетных решений обоих крупнейших производителей и конкурентов.
Обновленная методика тестирования
Но сперва несколько слов об обновленной методике тестирования. Время не стоит на месте, Microsoft всячески подталкивает пользователей уйти с привычной Windows 7 на более новую версию ОС, и как следствие, уже сейчас можно найти немало нового железа, драйвера которого пишутся для Windows 8 (8.1), а для Windows 7 выходят позже или вообще никогда.
Главным образом по этой причине мы обновили ОС на тестовом стенде до Windows 8.1 (редакция Профессиональная x64), включая все обновления по состоянию на сентябрь 2015 года. Поскольку сравнивать напрямую старые результаты, полученные на Windows 7, с новыми в любом случае будет некорректно, мы перешли на DXVA Checker версии 3.8.0. В этой программе есть очень удобный для тестировщика режим Benchmark, в котором видео воспроизводится настолько быстро, насколько это позволяет аппаратный или программный декодер.
Важно отметить, что в прошлых частях сводного тестирования использовалась одна и та же, самая первая версия DXVA Checker. Между тем, начиная с версии 2.0.0 алгоритм для режима Benchmark был сильно изменен (вероятно, он стал более аккуратным и качественным, хотя в режиме оценки «на глаз» никакой разницы заметить не удается), в результате чего показатели всех без исключения декодеров стали значительно более скромными. Чтобы лучше увидеть разницу между старым и новым алгоритмом, мы еще раз протестировали платформу на базе Intel Celeron G540, о возможностях которой было рассказано в третьей части данного тестирования.
Набор кодеков, напротив, остался прежним. В него входят LAV Filters, Media Player Classic Black Edition (MPC-BE) и Windows Media Player 12. Часть кодеков доступна как в виде DirectShow(DS)-фильтров, так и в качестве компонента для фреймворка Media Foundation (ME). Кроме того с переходом на 64-битную платформу появилась возможность выбирать между 32- и 64-битной версиями озвученных выше продуктов. Забегая вперед, отметим, что практической разницы между DS и ME, а также 32- и 64-битной версиями кодеков на сегодняшний день нет, их результаты различаются в пределах погрешности.
Список тестовых роликов в основном остался тем же, однако для каждого из сценариев в пару к столь привычному и отлично поддерживаемому «железом» кодеку H.264 (AVC) был добавлен ролик, закодированный в формате H.265 (HEVC) — более современном и прогрессивном, но все еще довольно сыром и плохо поддерживаемом как устройствами записи, так и устройствами воспроизведения. На текущий момент поддержку аппаратного декодирования HEVC можно считать приятным бонусом и заделом на будущее. Главное, чтобы финальная версия стандарта не была переработана настолько, чтобы выпускаемые сейчас декодеры потеряли свою актуальность.
Тестировать ролики с разрешением ниже 1080p на современных платформах — занятие бессмысленное, поэтому самый «легкий» экземпляр в нашем списке примерно соответствует качеству BDRip 1080. Full HD-ролики, доступные для онлайн-воспроизведения на Youtube и других видеохостингах, имеют, как правило, такой же или более низкий битрейт. Во втором ролике битрейт повышается до 30 Мбит/с, что примерно соответствует качеству BDRemux, то есть Blu-ray без какого-либо ухудшающего качество картинки пережатия. Третий ролик намеренно использует ненормально высокий битрейт, который обычно не встречается в реальной жизни. Это хорошая проверка для выявления «запаса прочности» у тестируемого декодера, однако плохие результаты именно на этом ролике еще не означают, что платформа не подходит в качестве основы для построения HTPC.
Ролики с увеличенным до 60 количеством кадров в секунду сейчас умеют снимать даже не самые дорогие экшн-камеры и смартфоны, поэтому все большее количество спортивных видео, роликов из путешествий, да и просто «влогов» становятся доступны в формате с 50 и 60 FPS. С другой стороны, если кроме воспроизведения полнометражных фильмов и сериалов ничего не требуется, то на качество декодирования подобных роликов можно не обращать особого внимания.
Видео в разрешении 2160p (оно же 4K) также становится в последнее время все популярнее. И хотя доступных и качественных мониторов и телевизоров с соответствующим разрешением пока что крайне мало, да и платформы с видеовыходами HDMI и DisplayPort подходящего стандарта встречаются не повсеместно — все равно воспроизведение таких роликов даже на экране с разрешением Full HD будет давать выигрыш в качестве хотя бы из-за более высокого битрейта. Ролики в этом разрешении также представлены с двумя вариантами битрейта — обычным и сильно завышенным, по аналогии с Full HD, о котором мы говорили выше.
Эти же шесть роликов, с сохранением параметров битрейта и разрешения, были перекодированы в формат H.265 (HEVC). Набор кодеков и методика тестирования с помощью DXVA Checker для них точно такая же, никаких дополнительных действий и настроек не производилось.
Краткий обзор тестируемых платформ
Всего платформ в этой части тестирования представлено 5 штук, при этом полностью новой и неизученной является только одна — процессор Intel Celeron N3150, интегрированный на плату ASRock N3150-ITX. Этот процессор выполнен по техпроцессу 14 нм и входит в новую линейку Braswell. Его графический ускоритель Intel HD Graphics восьмого поколения оснащен аппаратным декодером H.265 и позволяет выводить картинку в разрешении 4K через разъемы HDMI и DisplayPort.
- Intel Celeron N3150 (ASRock N3150-ITX)
- Intel Pentium J2900 (ASRock Q2900-ITX) (графика Radeon HD8400)
- дискретная видеокарта AMD Radeon R7 240 (Asus R7240-SL-2GD3-L)
Откровенно старый процессор Intel Celeron G540 был повторно протестирован только для того, чтобы продемонстрировать разницу в результатах старой и новой версии DXVA Checker, о чем мы уже упоминали выше. Результаты Intel Pentium J2900 должны быть очень похожи на результат Celeron J1800, равно как и AMD Athlon 5350 по скорости аппаратного декодирования не должен сильно отличаться от AMD A6-5200, поскольку эти пары являются представителями одного семейства — Bay Trail и Kabini соответственно.
В проводимых нами тестированиях платформ явно не хватает дискретных видеокарт AMD и Nvidia. Их основное сравнение будет представлено в следующих частях сводного тестирования, а в качестве пробного шага мы решили посмотреть на результаты графического ускорителя AMD Radeon R7 240 — относительно новой платы начального уровня без поддержки вывода картинки с разрешением Ultra HD.
Воспроизведение HD-видео
В сводную диаграмму включены показатели среднего количества FPS согласно данным DXVAChecker для наиболее производительного декодера. Для удобства восприятия результаты для роликов H.264 и H.265 представлены отдельно.
Результаты получились интересные и немного озадачивающие. С роликами в разрешении Full HD все испытуемые справились вполне успешно. Проблемы возникли только у «старичка» Celeron G540, которому намного комфортнее работалось на 32-битной версии Windows 7 со старыми драйверами и версиями кодеков. Если раньше его аппаратный декодер с огромной скоростью молотил абсолютно любое видео 1080p, то теперь декодер включается, нагрузки на центральный процессор нет, но видео явно тормозит, воспроизводится с пропуском кадров. Использование старых роликов (Ducks Take Off и Porsche Demo) и разных плееров проблему не решает, помогает только отключение аппаратного ускорения и декодирование силами CPU — в таком режиме ролик с разрешением 1080p и скоростью 60 FPS воспроизводится нормально.
С видео в ультравысоком разрешении ситуация заметно хуже. У самого нового Intel Celeron N3150 аппаратный декодер включается, но работает недостаточно быстро — небольшой пропуск кадров периодически случается, это будет раздражать в моменты резкой смены картинки. Пропуски видны и при обычном воспроизведении роликов через Windows Media Player и MPC-BE, так что на ошибку в DXVA Checker это не похоже. Возможно, ситуация станет лучше с выходом новой версии драйверов Intel.
Более старый Intel Pentium J2900 справляется с задачей немного лучше, хотя и у него запаса практически не чувствуется. И это при том, что со старыми ОС и драйверами его ближайший «родственник» Celeron J1800 показывал примерно вдвое лучший результат.
Ранее мы уже убеждались в том, что интегрированный графический чип Radeon HD8000 не оснащается аппаратным декодером 4K-видео и, следовательно, воспроизведение таких роликов полностью ложится на CPU. AMD Athlon 5350 справляется с этой задачей немного лучше, чем AMD A6-5200, но в любом случае его скорости не хватает для стабильных 30 кадров в секунду. Было интересно узнать, на что способна дискретная карта начального уровня AMD. Ведь если для игр она практически непригодна, то, быть может, в нее устанавливают более продвинутый аппаратный декодер для видео. Однако по факту оказалось, что ни по скорости, ни по количеству поддерживаемых форматов Radeon R7 240 не отличается от Radeon HD8000: только Full HD, никакого 4K.
Занятно, что результат программного декодирования потока 2160p для процессора Intel Celeron G540 стал заметно выше, чем был на Windows 7. Теперь его производительности вполне хватает на 4K-ролики со стандартным битрейтом. Нагрузка на процессор при этом не поднимается выше 85%, так что остается еще небольшой запас на фоновые операции, которые могут помешать плавному воспроизведению видео.
Результаты графической карты AMD Radeon R7 240 на данной диаграмме не представлены по той простой причине, что аппаратного ускорителя HEVC в этом чипе нет, а скорость программного декодера зависит исключительно от скорости центрального процессора. Дискретный видеочип в этом случае никак не помогает и не мешает процессу.
Из оставшихся участников тестирования блок аппаратного декодирования потока H.265 обнаружился только у Intel Celeron N3150, и это полностью совпадает с заявленными спецификациями платформ. Занятно, что скорость декодирования H.265 у нового процессора Intel оказывается даже немного выше, чем для более старого и распространенного H.264. Особенно это важно и заметно при воспроизведении видео в разрешении 2160p: если на роликах AVC были заметны пропуски как в режиме бенчмарка, так и в обычных плеерах, то с HEVC ситуация несколько выправляется, ролики 4K с адекватным битрейтом можно смотреть на скорости 30 кадров в секунду. Правда, «запаса прочности» по-прежнему не наблюдается, что несколько настораживает и расстраивает.
Вычислительной мощности всех остальных платформ вполне хватает на воспроизведение Full HD-роликов в новом формате, даже при удвоенной частоте кадров. Но стоит поднять битрейт до аномально высоких значений или повысить разрешение до 2160p, и просмотр видео превращается в слайд-шоу.
Итоги
По итогам очередной части сводного тестирования можно сделать два основных вывода. Во-первых, дискретные видеокарты AMD 2xx начального уровня обладают точно таким же по скорости и поддерживаемым форматам аппаратным декодером для видеопотока, что и встроенные в современные APU графические ускорители этой компании. Возможности этого декодера на сегодняшний день покрывают потребности большей части пользователей, потому как работа с кодеком H.265 и разрешением 4K по-прежнему является скорее экзотикой, чем повседневной необходимостью. Тем не менее, никакого задела на будущее AMD Radeon R7 240 и другие построенные на аналогичном GPU ускорители не обеспечивают, а это делает их чуть менее привлекательными в сравнении с конкурентами.
Во-вторых, аппаратный декодер Intel для процессоров из линейки Braswell можно назвать одним из самых продвинутых на рынке x86-совместимого оборудования. В него заложена поддержка как ультравысокого разрешения 4K, так и нового перспективного кодека H.265 (HEVC). Правда, полноценно воспользоваться им в варианте «из коробки» получится не всегда. Наши тесты показали, что для нахождения оптимального по скорости решения может потребоваться не самый быстрый и увлекательный процесс подбора версии операционной системы, драйверов, кодеков, плеера и их совместной настройки.
Доброго времени суток! В общем дело такое: купил я недавно ноутбук. Б/у; Core i7; GTX 960M 4гб.; 12гб. оперативки; стоит SSD. Игры тянет на максималках, писать, что железо слабое - нет смысла. Взял его исключительно для работы с видео. А теперь такое дело - почему-то тормозят видео с кодеком h265 ( HEVC, MPEG-II ) Как только конвертирую его в исходных настройках* в видеокодек h264, сразу становится всё нормально. Меня не совсем устраивает конвертировать каждый файл. Кто может мне что посоветовать?
*Исходные настройки:
-1080p 240fps;
-4K 60fps.
P.S. Драйвера новейшие, винда чистая, работал со всеми возможными видеоплеерами (VLC; K-Light codec pack; и т. д.)
Прикол всего этого в том что на других ноутбуках, у которых совсем нет дискретной видеокарты, всё воспроизводится без всяких нареканий.
"GTX 960M"
не поддерживает на аппаратном уровне декодирование видео в H265 (HEVС).
то есть при использовании этого кодека за декодирование будет отвечать процессор, а не видеокарта.
У меня последний вопрос. Я дополнил свой вопрос в основной части:
"Прикол всего этого в том что на других ноутбуках, у которых совсем нет дискретной видеокарты и стоит у него вообще intel pentium. Всё воспроизводится без всяких нареканий."
Как можно это объяснить?
Миша Искусственный Интеллект (190381) Давид Кулешов, прикол в том что зависит от конкретного процессора, даже у относительно свежих селеронов интегрированная графика поддерживает на аппаратном уровне декодирование видео в h265. поэтому какой именно pentium?
Да говвно ноут у него, первого покления небось, да ssd на sata и да и планки разные 2х канала там нет. Из какашек ноут собрал и жалуется
Давид Кулешов Ученик (114) Lincoler, ни в коем случае не жалуюсь. Ноут я не собирал, а купил такой какой он вышел с завода. Если мой аппарат слабее вашего - это не причина оскорблять других. Вы опускаете своими словами, только самого себя. Меня и других это нисколько не колышет))))
Это тяжёлый кодек, для декодирования видео в таком разрешении и/или частотой кадров, особенно на ЦП ноутбука. Современная техника быстро и легко кодирует/декодирует только на аппаратных модулях. Смотрите, что поддерживает ваш GPU.
Текущую ситуацию в области медиакодеков, можно описать буквально несколькими словами: простые решения себя исчерпали. С каждым годом материал для кодирования становится все сложнее, а требования к качеству результата – все выше. В этих условиях, когда лобовая атака уже не дает эффекта, особое значение приобретает оптимизация как кодирования, так и воспроизведения медиа под конкретные платформы с использованием их самых современных возможностей. Чего можно добиться такой оптимизацией, мы покажем на примере перспективного кодека Н.265. В качестве целевой платформы рассмотрим серверное решение Intel — процессор Xeon.
Краткое описание H.265/HEVC
- Особые возможности для произвольного доступа и сращивания цифровых потоков. В H.264/MPEG-4 AVC цифровой поток должен всегда начинаться с блока адресации IDR, а в HEVC поддерживается произвольный доступ.
- Изображение разделяется на единицы дерева кодирования (CTU), каждая из которых содержит блоки дерева кодирования (CTB) яркости и цветности. Во всех прежних стандартах кодирования видео использовался фиксированный размер массива для выборок яркости — 16×16. HEVC поддерживает блоки CTB разного размера, который выбирается в зависимости от потребностей кодировщика с точки зрения памяти и вычислительной мощности.
- Каждый блок кодирования (СВ) может быть рекурсивно разделен на блоки преобразования (ТВ). Разделение определяется остаточным квадродеревом. В отличие от прежних стандартов в HEVC один блок ТВ может охватывать несколько блоков предсказания (РВ) для перекрестных предсказываемых единиц кодирования (CU).
- Направленное предсказание с 33 различными направлениями ориентации для блоков преобразования (TB) размером от 4×4 до 32×32. Возможное направление предсказания — все 360 градусов. HEVC поддерживает различные методики кодирования предсказания интракадров.
Проблемы производительности HEVC
- Отсутствие параллельной схемы.
- Неэффективная настройка векторизации.
Рисунок 1. Профиль проекта HM — параллельная работа потоков
Рисунок 2. Профиль проекта HM — ресурсоемкий код
-
(совместим с HM10.0, оптимизация декодера) (совместим с HM, распараллеливание и векторизация)
Рисунок 3. Нагрузка на ЦП в проекте X.265
Рисунок 4. Проект X.265 с настройкой Intel® SIMD
В проекте x265 также были использованы инструкции Intel® SIMD (автогенерация компилятором), что обеспечило повышение производительности более чем на 70%. Вместе с дальнейшей оптимизацией компиляторными опциями, компилятор Intel обеспечивает удвоение производительности на платформе IA. Тем не менее, производительность кодировщика по-прежнему существенно ниже, чем требуется для кодировщика реального времени, особенно для видео высокой четкости с разрешением 1080p.
Ниже мы покажем результаты, достигнутые китайской компанией Strongene при поддержке специалистов компании Intel на пути оптимизации созданного ей кодека H.265/HEVC под различные платформы Intel.
Оптимизация HEVC под платформу Intel® Xeon™
Основную часть самых ресурсоемких функций по обработке видео и изображений составляют интенсивные вычисления блочных данных. Для их оптимизации можно использовать инструкции векторизации Intel® SIMD. В кодировщике в составе кодека Strongene, согласно данным профилирования, с помощью инструкций Intel SSE можно провести ручную векторизацию всех наиболее ресурсоемких функций, таких как кадровая интерполяция низкой сложности с компенсацией движения; целочисленное преобразование без транспозиции; преобразование Адамара; вычисление сумм абсолютных разностей (SAD)/квадратов разности (SSD) с наименьшим избыточным использованием памяти. Мы включили инструкции Intel SSE в виде интринсик-функций, как показано на рис. 5.
Рисунок 5. Пример включения инструкций Intel® SIMD/SSE в кодеке Stongene
Разработчики Strongene переписали все ресурсоемкие функции, чтобы добиться наибольшего прироста производительности кодировщика. На рис. 6 показаны наши данные профилирования в сценарии кодирования видео стандарта 1080p с помощью HEVC. Видно, что 60% ресурсоемких функций обрабатываются инструкциями Intel SIMD.
Рисунок 6. Результаты профилирования функций кодирования Strogene
Таблица 1. Результаты реализации Intel® SSE и Intel® AVX2
Циклы ЦП | Исходный код | Intel® SSE | Intel® AVX2 |
---|---|---|---|
Запуск 1 | 98877 | 977 | 679 |
Запуск 2 | 98463 | 1092 | 690 |
Запуск 3 | 98152 | 978 | 679 |
Запуск 4 | 98003 | 943 | 679 |
Запуск 5 | 98118 | 954 | 678 |
Среднее | 98322,6 | 988,8 | 681 |
Ускорение | 1,00 | 99,44 | 144,38 |
Как видно из таблицы 1, применение инструкций Intel SSE и Intel AVX2 обеспечивает повышение производительности в 100 раз, при этом код Intel AVX2 дополнительно выигрывает еще 40% по сравнению с Intel SSE.
Как мы видели ранее, в большинстве существующих реализаций используются не все ядра многоядерных платформ. Опираясь на последнюю многоядерную архитектуру Intel Xeon с параллельной зависимостью между алгоритмами на основе CTB, разработчики Strongene предлагают заменить исходные методы OWF и WPP параллельной структурой IFW, а затем разработать трехуровневую схему управления потоками, чтобы гарантировать полное использование структурой IFW всех ядер ЦП для ускорения кодирования HEVC.
Рисунок 7. Параллельная работа потоков и использование ЦП в кодировщике Strongene
За счет применения новой параллельной структуры WHP и полной реализации инструкций Intel SIMD соответственно на уровне задач и уровне данных разработчикам кодировщика Strongene удалось добиться весьма значительного повышения производительности на процессорах x86 для видео с разрешением 1080p, используя вычислительные ресурсы всех ядер, как показано на рис. 8.
Дальнейшая настройка с использованием SMT/HT
Также представляет интерес зависимость производительности кодека от включения в системе широко распространенной на всех платформах с архитектурой Intel одновременной многопоточности (SMT), также называемой технологией гипертрединга (HT).
Таблица 2. Скорость кодирования Strongene HEVC на платформе Intel® Xeon®
Как видно из таблицы (показано желтым цветом) на платформе Ivy Bridge (процессор Intel Xeon E5-2697 v2 для отключенного SMT кодирование видео HEVC с разрешением 1080p осуществляется в реальном времени!
Добившись огромнейшего увеличения производительности, мы продолжили изучение возможностей кодирования Strongene HEVC на платформе Ivy Bridge, уделяя внимание скорости потока и вопросам качества.
Таблица 3. Сравнение производительности кодеков H.264 и H.265
В таблице 3 видно, что кодек H.265/HEVC снижает объем данных на 50% при сохранении прежнего качества видеоизображения.
H.265/HEVC, по всей видимости, станет наиболее популярным стандартом видео в ближайшее десятилетие. Во множестве приложений и продуктов мультимедиа в настоящее время реализуется поддержка HEVC. В этом документе мы реализовали основанное на ЦП полнофункциональное решение HEVC реального времени на платформах Intel с новыми технологиями IA. Наше оптимизированное решение на базе процессоров Intel развернуто в компании Xunlei, занимающейся предоставлением услуг видео через Интернет, и будет способствовать повсеместному внедрению и распространению технологии H.265/HEVC.
4K60fps — это новый стандарт видео. Тем не менее, эти файлы не очень маленькие и легкие для вашего процессора, поэтому вы можете столкнуться с небольшими трудностями при просмотре их в VLC Media Player. В этой статье мы рассмотрим несколько простых советов по устранению проблем с прерывистым воспроизведением или задержкой видео при воспроизведении видео Ultra HD 4K60fps в VLC Media Player в Windows 10.
2] Отключить или включить аппаратное ускорение
Аппаратное ускорение — это функция в медиаплеере VLC, которая направляет работу по декодированию с вашего процессора на графический процессор.
Если у вас старая машина, скорее всего, ваша видеокарта немного слабее процессора, поэтому вам следует отключить аппаратное ускорение. С другой стороны, если у вас есть новый компьютер и вы столкнулись с проблемой задержки VLC, попробуйте включить эту функцию.
- Для этого запустите VLC;
- Нажмите Инструменты;
- Настройки;
- Ввод/кодеки.
Теперь измените декодирование с аппаратным ускорением на Автоматическое (для нового компьютера) или Отключить (для старого компьютера) и нажмите «Сохранить».
1.2. Подключение аппаратного ускорения в стандартных декодерах
FFmpeg позволяет для некоторых декодеров подключить аппаратное ускорение. При программировании с использованием FFmpeg API все необходимое для подключения к декодерам аппаратного ускорения находится в заголовочном файле libavutil/hwcontext.h . В этом файле определено перечисление enum AVHWDeviceType , каждый элемент которого и соответствует некоторому типу аппаратного ускорения. Какие типы аппаратного ускорения доступны в текущей сборке FFmpeg можно узнать с помощью следующего кода:
Для описанной выше программно-аппаратной конфигурации мы получим:
Понятно, что cuda требует установки платы Nvidia и соответствущего ПО, qsv использует технологию Intel Quick Sync Video (QSV), реализованную на встроенных графических процессорах Intel (см. [1]), dxva2 и d3d11va используют технологию DirectX Video Acceleration (см. [2]), доступную только в Windows, но зато реализованную для видеокарт разных производителей (Intel, Nvidia, AMD).
Конкретные декодеры не обязаны поддерживать все эти типы аппаратного ускорения (или хотя бы один из них). Для определения типов, поддерживаемых конкретным декодером, можно воспользоваться следующим кодом:
Для описанной выше программно-аппаратной конфигурации декодеры h264 , hevc , vp9 , vc1 поддерживают следующие типы аппаратного ускорения:
А вот theora вообще не поддерживает аппаратного ускорения.
Теперь совсем кратко рассмотрим процедуру подключения к декодеру аппаратного ускорения, за дополнительными деталями надо обратится к примеру hw_decode.c . Также можно посмотреть статью [3], написанную 2expres.
После декодирования данные кадра находится в некотором специальном формате, который определяется типом устройства, поэтому его надо конвертировать в один из обычных пиксельных форматов с помощью функции av_hwframe_transfer_data() . Для dxva2 и d3d11va этот формат будет NV12 .
Для подключения аппаратного ускорения в командной строке надо использовать опцию с ключом -hwaccel .
3] Пропустить фильтр внутренней деблокировки H.264
Один из лучших способов решить проблему задержки VLC при воспроизведении видео 4K — это изменить параметр «Пропустить внутрицикловый фильтр деблокирования H.264» на «Все» .
- Для этого вам нужно запустить VLC;
- Щелкнуть Инструменты;
- Настройки;
- В окне «Простые настройки», перейдите на вкладку «Ввод/кодеки»;
- Измените «Пропустить внутрицикловый фильтр деблокирования H.264» на «Все»;
- Нажмите «Сохранить» .
Надеюсь, эти решения помогут вам при воспроизведении видео 4K 60fps.
1] Обновите VLC Media Player
Первое, что вам нужно сделать, чтобы решить проблему с запаздыванием, — это обновить VLC Media Player.
- Для этого запустите VLC Media Player;
- Перейдите на вкладку «Справка»;
- Нажмите «Проверить наличие обновлений»;
- Следуйте инструкциям на экране, чтобы обновить приложение.
Если ваше приложение обновлено, попробуйте другие решения.
1.1. Подключение дополнительных рабочих потоков в стандартных декодерах
Многие декодеры (но, конечно, не все) позволяют установить количество рабочих потоков, используемых для декодирования. Для этого перед вызовом avcodec_open2() член thread_count структуры AVCodecContext надо установить в требуемое значение. Другой способ — добавить опцию threads в словарь опций, передаваемый в качестве третьего аргумента в avcodec_open2() .
Наиболее популярные декодеры, используемые для тяжелых форматов, ( h264 , hevc , vp9 ) поддерживают эту возможность, а вот theora нет.
Для подключения дополнительных потоков в командной строке надо использовать опцию с ключом -threads .
Тормозит 4K в VLC
- Обновите VLC Media Player.
- Отключить или включить аппаратное ускорение.
- Пропустить фильтр внутренней деблокировки H.264.
Читайте также: