OpenAPV 1.1.1: профессиональный видеокодек APV получил первый стабильный API линейки 1.x

Коротко: 15 сентября 2026 вышел OpenAPV 1.1.1.0 — первый стабильный релиз линейки 1.x эталонного кодека APV. Главное: новый PBU-декодер с семью точками входа для гранулярной обработки битстрима, семь профилей UNCONST с мелкой тайловой разбивкой для лучшего параллелизма, поддержка пользовательского аллокатора памяти, оптимизации AVX2 и ARM NEON, линейное планирование тайлов вместо квадратичного. API-набор 0 полностью сохранён — существующие приложения перекомпилируются без изменений.

Что такое APV и зачем нужен профессиональный кодек

APV (Advanced Professional Video) — стандарт видеосжатия, разработанный изначально Samsung и переданный в 2025 году под управление Academy Software Foundation (ASWF) — некоммерческой организации, которая развивает инструменты открытого кода для кино- и медиаиндустрии. Под эгидой ASWF уже работают OpenEXR, OpenVDB, MaterialX и USD.

В отличие от кодеков с межкадровым предсказанием (H.264, H.265, AV1), APV использует только внутрикадровое кодирование — каждый кадр сжимается независимо, без ссылок на соседние. Такой подход типичен для профессиональных стандартов: Apple ProRes, Avid DNxHR, JPEG 2000. Преимущества — нулевая задержка на декодирование случайного кадра (монтажный стол «прыгает» без ожидания), упрощённая параллельная обработка и предсказуемый битрейт. Цена — большой размер файла по сравнению с дистрибутивными кодеками. APV нацелен на производственные рабочие процессы: захват с камеры, монтаж, пост-продакшен.

OpenAPV — открытая эталонная реализация кодека APV, которую разработчики используют для интеграции поддержки формата в свои продукты и для тестирования совместимости. Познакомиться с тем, как устроены видеоформаты в целом, можно в каталоге форматов файлов Loadfile.

Версия 1.1.1: первый стабильный API-набор 1.x

До этого релиза библиотека работала на API-наборе 0, последняя версия в этой линейке — v0.3.0. Команда OpenAPV приняла новую схему версионирования: формат номера теперь «APISET.MAJOR.MINOR.PATCH», где первая цифра обозначает набор API. Это означает, что переход на 1.1.1 — не семантическое изменение мажорной версии, а выход нового API-набора с новыми возможностями.

По данным официальных release notes на GitHub (AcademySoftwareFoundation/openapv), API-набор 0 полностью сохранён: ни одна публичная функция не удалена и ни одна сигнатура не изменена. Существующие приложения, собранные под v0.3.0, перекомпилируются под v1.1.1 без каких-либо правок исходного кода — достаточно обновить параметр ops_mem до NULL при вызове инициализатора.

PBU-декодер: семь новых точек входа

Главное нововведение API-набора 1 — PBU-основанный декодер. PBU (Picture Bitstream Unit) — единица разбивки битстрима APV. Прежний декодер работал только на уровне законченного видеофрагмента; новый позволяет обрабатывать поток на уровне отдельных единиц PBU с точным контролем над каждым шагом.

В API добавлено семь новых функций:

• oapvd_info_pbu() — извлекает метаданные PBU без декодирования: позволяет быстро проанализировать заголовок, не тратя ресурсы на полное декодирование пикселей;
• oapvd_decode_frame() — декодирует один полный кадр;
• oapvd_decode_tiles() — декодирует набор тайлов; каждый тайл получает буфер, соразмерный именно тайлу, а не всему кадру — что критично для экономии памяти при параллельной обработке;
• oapvd_decode_metadata() — обрабатывает контейнеры метаданных;
• три вспомогательные функции для получения информации о форматах кадра и размерах тайлов.

Гранулярный API важен для программного обеспечения, которое выборочно декодирует части видео: систем редактирования с многопоточностью, серверных транскодеров, утилит анализа без полного декодирования.

Профили UNCONST: меньше тайлы — больше параллелизм

В прежней спецификации APV существовали ограничения на минимальный размер тайлов внутри кадра. Версия 1.1.1 добавляет семь новых профилей UNCONST (Unconstrained), которые снимают эти ограничения на разбивку кадра на тайлы.

Что это даёт на практике: меньший тайл — более короткое задание для одного вычислительного потока. Если кодек или транскодер распределяет тайлы по ядрам процессора, то с профилями UNCONST он получает больше независимых единиц работы. Для современных серверных и рабочих станций с десятками ядер это означает лучшее масштабирование: декодирование 8K-видео на 32-ядерной системе получает более тонкую нарезку задач.

Кроме того, мелкие тайлы позволяют реализовать частичное декодирование: декодировать только нужный фрагмент кадра (например, для генерации миниатюр или при прокрутке по временной шкале), не тратя ресурсы на полный кадр. Именно для этого функция oapvd_decode_tiles() в новом API выделяет буфер под каждый тайл отдельно.

Оптимизации производительности: AVX2, NEON и линейное планирование

Релиз включает несколько изменений, направленных непосредственно на скорость декодирования:

• AVX2-инструкции для операции конвертации блоков в целевое изображение — ускоряет работу на процессорах Intel и AMD с поддержкой расширенных векторных наборов;
• ARM NEON-ядра для той же операции — ускорение для архитектуры ARM (Apple Silicon, серверные ARM-процессоры, встроенные системы);
• Линейное планирование тайлов вместо квадратичного алгоритма — предыдущий планировщик имел квадратичную сложность при увеличении числа тайлов, что заметно проявлялось на кадрах с большим количеством мелких тайлов;
• очистка и унификация SIMD-кода ядра декодера.

Команда проекта анонсировала, что результаты бенчмарков будут опубликованы на OpenBenchmarking.org.

Исправления корректности включают: починку вычисления MD5-хэшей на системах с порядком байтов big-endian (критично для верификации потока на серверах на базе IBM Power и аналогичных платформ), улучшенную проверку входных данных и исправление вывода QP-параметров.

Пользовательский аллокатор памяти

Версия 1.1.1 добавляет возможность передать кодеку собственный аллокатор памяти через поле ops_mem в структуре параметров. По умолчанию (ops_mem = NULL) библиотека, как и прежде, использует стандартные malloc/free из стандартной библиотеки Си.

Пользовательский аллокатор полезен в двух сценариях. Первый — встроенные и реального времени системы, где стандартная куча недоступна или нежелательна: камеры, специализированные транскодеры, FPGA-платформы. Второй — приложения с выделенными пулами памяти или требованиями к расположению буферов в памяти (выравнивание, huge pages, DMA-доступ).

Что это значит для работы с видеофайлами

OpenAPV 1.1.1 — внутренняя библиотека, а не конечное приложение. Конечный пользователь не запускает OpenAPV напрямую: кодек интегрируется в транскодеры, монтажные системы и медиаплатформы разработчиками.

Тем не менее значение релиза для экосистемы форматов очевидно: стабильный API-набор 1.x означает, что разработчики программного обеспечения теперь могут безопасно привязываться к интерфейсу без риска поломки при обновлении. Это ускорит появление поддержки APV в инструментах, которыми пользуются операторы и монтажёры.

Если вы работаете с профессиональными видеофайлами — например конвертируете RAW-материал с камеры или готовите архивные копии, — знакомство с APV актуально: формат позиционируется как открытая альтернатива ProRes и DNxHR. Наш обзор открытого видеокодека AV2 и dav2d поможет понять, как развивается ландшафт открытых видеостандартов. Также читайте о том, как AV1 получил аппаратное кодирование через Mesa и WSL — это параллельный тренд на ускорение открытых видеоформатов на процессорной и GPU-стороне.

Источники

• Phoronix — OpenAPV Sees Big Update For Advancing The Advanced Professional Video Codec (15 сентября 2026)
• GitHub: AcademySoftwareFoundation/openapv — Release v1.1.1.0 (15 сентября 2026)