Выпуск кодировщика SVT-AV1 2.0 и декодировщика dav1d 1.4 для формата видео AV1

Опубликован выпуск библиотеки SVT-AV1 2.0 (Scalable Video Technology AV1) c реализациями кодировщика и декодировщика формата кодирования видео AV1, для ускорения которых задействованы присутствующие в современных CPU Intel средства аппаратного распараллеливания вычислений. Проект создан компанией Intel в партнёрстве с Netflix с целью достижения уровня производительности, пригодного для перекодирования видео на лету и применения в сервисах, отдающих видео по запросу (VOD). В настоящее время разработка ведётся под эгидой альянса Open Media (AOMedia), курирующего развитие формата кодирования видео AV1. Ранее проект развивался в рамках проекта OpenVisualCloud, который также разрабатывает кодировщики SVT-HEVC и SVT-VP9. Код распространяется под лицензией BSD.

Для использования SVT-AV1 необходим процессор x86_64 с поддержкой инструкций AVX2. Для кодирования 10-битовых потоков AV1 с качеством 4K требуется 48 Гб ОЗУ, 1080p — 16 Гб, 720p — 8 Гб, 480p — 4 Гб, при этом потребление памяти напрямую зависит от числа задействованных при кодировании процессорных ядер, регулируемых опцией »--lp». Из-за усложнения применяемых в AV1 алгоритмов, для кодирования данного формата требуется существенно больше ресурсов, чем для других форматов, что не позволяет применять штатный кодировщик AV1 для перекодирования в реальном времени. Например, штатный кодировщик от проекта AV1 требует в 5721, 5869 и 658 раз больше вычислений по сравнению с кодировщиками x264 (профиль «main»), x264 (профиль «high») и libvpx-vp9.

Среди изменений в новом выпуске SVT-AV1:

  • Осуществлён переход на новую нумерацию версий, в соответствии с которой первая цифра в версии будет меняться при каждом изменении API/ABI.
  • Внесены изменения в API, связанные с переходом к индикации завершения потока (EOS — End Of Stream) в последнем кадре вместо использования пустого кадра, что позволило исключить задержку на ожидание лишнего кадра. Изменение API уже отражено в кодовой базе FFmpeg.

  • Удалён трёхпроходный режим переменного битрейта (3-pass VBR), вместо которого теперь используется механизм многопроходного VBR. Многопроходный режим VBR сведён к выполнению двух проходов для обеспечения интеграции с FFmpeg.

  • В кодировщик добавлены оптимизации, в результате которых эффективность сжатия пресетов M9-M13 повысилась на 1–4%, а потребление памяти в пресете M5 снизилась на 20–35% в режиме LP 8 и на 1–5% в других режимах. Потребление памяти в остальных пресетах уменьшилось на 1–5%.

  • Проведена оптимизация компромиссов качество/скорость для пресетов, выставляющих высокий уровень качества. Работа пресета MR, предоставляющего эталонное качество, ускорена на 100%.

  • В функции, написанные только на языке Си, добавлены оптимизации, специфичные для архитектуры ARM.

Дополнительно можно отметить выпуск проекта dav1d 1.4.1, в рамках которого сообщества VideoLAN и FFmpeg развивают библиотеку с реализацией альтернативного свободного декодировщика формата кодирования видео AV1. Библиотека dav1d поддерживает все возможности AV1, включая расширенные виды субдискретизации и все заявленные в спецификации параметры управления глубиной цвета (8, 10 и 12 бит). Ключевой особенностью dav1d является ориентация на достижение максимально возможной производительности декодирования и обеспечение качественной работы в многопоточном режиме. Код проекта написан на языке C (C99) с ассемблерными вставками (NASM/GAS) и распространяется под лицензией BSD. Реализована поддержка архитектур x86, x86_64, ARMv7 и ARMv8, и операционных систем FreeBSD, Linux, Windows, macOS, Android и iOS.

Версия dav1d 1.4 примечательна поддержкой новых архитектур Loongarch и RISC-V, а также задействованием дополнительных оптимизаций на базе инструкций AVX-512, ускорением работы фильтров 6tap на системах ARM, повышением эффективности многопоточной работы и сокращением размера бинарных данных на системах ARM64, ARM32 и RISC-V. Устранена уязвимость CVE-2024–1580, приводившая к записи в область вне границ буфера из-за целочисленного переполнения при обработке кадров очень большого размера.



Источник: http://www.opennet.ru/opennews/art.shtml? num=60788

OpenNet прочитано 6246 раз