Кратко

  • В RFC 9924 способность декодера APV объявляется отдельно для каждого профиля тройкой profile–level–band: набором алгоритмических функций, пределом частоты яркостных отсчётов и геометрии тайлов, а также максимальной скоростью кодированных данных.
  • Синтаксическая корректность, объявленная способность, успешное декодирование, ограниченное потребление ресурсов, воспринимаемое качество и производственная приёмка — разные доказательства.

У «совместимости» есть неприятная особенность: чем короче запись в спецификации закупки, тем больше решений она может скрывать. Галочка APV и название профиля не отвечают, какое разрешение, частоту кадров, раскладку тайлов и битрейт получатель обязуется принять. Категория незаметно подменяет границу нагрузки.

Представим только для объяснения, что в постпродакшн поступил высокоскоростной 8K-материал. Заголовок читается, профиль известен. Но объявленные декодером уровень и полоса для этого профиля не охватывают работу. Другой файл даёт изображение, однако не проходит визуальную приёмку. Это не сведения о реальном продукте, а два различных отказа, которые одно слово «поддерживается» сделало неразличимыми.

RFC 9924 Advanced Professional Video опубликован в феврале 2026 года как Informational-документ Independent Stream. Карточка RFC Editor прямо сообщает: это не продукт IETF и не выражение консенсуса IETF. Публикация не подтверждает соответствие реализации, производительность или распространённость.

APV предназначен для профессиональной записи и постобработки, где важны малая задержка, высокий throughput и многократные циклы decode/re-encode. Кодек intra-frame-only и использует тайлы для параллельной работы. Документ рассматривает 2K, 4K и 8K с кодированными скоростями до нескольких Gbit/s, форматы от 4:0:0 до 4:4:4:4, alpha, HDR и пользовательские метаданные.

Синтаксис допускает глубину от 10 до 16 bit, но сегодня определены только профили для 10 и 12 bit. Возможность записать значение 16 bit в синтаксисе не создаёт профиль 16-bit и не доказывает поддержку устройством.

Профиль выбирает подмножество алгоритмических средств и обязательства, которые выполняет каждый соответствующий ему декодер. Это не скорость процессора и не объём памяти. Уровень ограничивает частоту яркостных отсчётов и геометрию тайлов. Полоса внутри уровня задаёт максимальную скорость кодированных данных.

Тройка относится к конкретному профилю. Одна реализация может поддерживать разные уровни для разных профилей. Поэтому самый высокий профиль в рекламном списке нельзя превратить в общую максимальную способность всего декодера. Одинаковое имя профиля у двух систем ещё не означает одинаковый рабочий диапазон.

RFC 9924 не вводит отдельно выбираемые опции декодера. Каждая такая опция умножила бы сочетания, которые encoder способен выдавать, а decoder должен предугадывать. Реализации остаются разными, но различия удерживаются на явных, объявляемых границах profile, level и band. Так сужается пространство проблем совместимости.

Правила резервных идентификаторов подчёркивают различие семантики. Зарезервированный profile_idc между известными значениями нельзя считать промежуточной способностью: профили — это наборы функций, а не одна числовая лестница. Зарезервированные level_idc и band_idc между заданными значениями, напротив, должны интерпретироваться как промежуточные способности, потому что это упорядоченные пределы ресурсов.

Работающий код добавляет доказательства, но не закрывает вопрос. Доступны OpenAPV и его bitstream-тесты, материалы об APV в Android 16, страница FFmpeg 8.0 и упомянутый commit энкодера. Их наличие даёт объекты для проверки, но не удостоверяет полное соответствие, скорость, охват устройств, безопасность, качество или внедрение.

Хороший протокол испытаний сохраняет несколько вердиктов. Корректен ли синтаксис? Входит ли тройка потока в объявленную способность данного профиля? Выполнил ли конкретный build разбор и восстановление? Остались ли время, память и путь ошибки в пределах? Сравнён ли результат с эталоном по раскрытому методу? Принял ли его владелец производственного процесса с учётом цвета, метаданных и повторных поколений?

Безопасность требует измерять и отказ. Предсказуемые биты заголовка и padding опасно сочетать с шифрами или режимами, уязвимыми к known-plaintext; APV не обеспечивает конфиденциальность. Вредоносный payload не должен вызывать выход за память, чрезмерные затраты или integer overflow. Ошибка, полученная лишь после исчерпания ресурсов, не является устойчивым поведением.

Через transcoding gateway враждебный поток может достичь и encoder. То, что ошибки encoder встречаются реже, не отменяет проверки входа. Decoder не должен обрабатывать неизвестный тип metadata: неверная интерпретация способна оставить его в неопределённом состоянии. Фраза о том, что содержимое не предназначено для исполнения, также не гарантирует безопасность malformed media.

Поиск errata RFC 9924 описывает обслуживание текста, а не свойства бинарного файла. «Perceptually lossless» остаётся целью проектирования, пока не названы материал, дисплей, метод наблюдения и результат.

Принцип Heng Lu Running-Code Primacy переносит авторитет с ярлыка на фактически работавшие parser, decoder, encoder и gateway. Minimum Initial Specification оставляет общий контракт узким и точным. Reality Layers не позволяет слить публикацию, синтаксис, заявление, выполнение, выход, восприятие и приёмку в один статус.

Полезная квитанция связывает тройку файла с объявленной тройкой декодера для его профиля. Она хранит размеры, frame rate, tiles, chroma, alpha, bit depth, скорость, build и конфигурацию, результаты, пик ресурсов, метаданные, метод сравнения, идентификатор выхода и решение производства. «APV поддерживается» годится для поиска кандидата. Для распределения ответственности этого мало.

Источники