Кратко

  • RFC 3984 отделила NAL-единицы с данными изображения от наборов параметров последовательности и изображения, задававших правила их декодирования.
  • Полная трасса пакетов могла остаться неполным доказательством: без истории версий, активации и владения идентификаторами нельзя восстановить смысл, который видел декодер.

В архиве есть RTP-последовательность без заметных дыр. Есть полезная нагрузка каждого пакета и время его прибытия. Не хватает другого журнала: когда старый PPS перестал действовать, когда новый был установлен и не использовали ли два источника один номер для разных правил. Пакетная история сохранилась, история смысла — нет.

RFC 3984 в феврале 2005 года определила формат полезной нагрузки RTP для H.264. Статус, список исправлений и история Datatracker показывают, что позднее её заменила RFC 6184. Помимо фрагментации и агрегации NAL документ описывал состояние, без которого правильные байты изображения не имели однозначного прочтения.

H.264 выносит повторно используемую информацию в наборы параметров. SPS описывает свойства кодированной видеопоследовательности. PPS хранит свойства, применяемые к кодированным изображениям, включая режимы и возможное распределение макроблоков по группам срезов. Заголовок среза не повторяет весь набор, а ссылается на него по идентификатору.

Ссылка создаёт зависимость во времени. Нужные SPS и PPS должны быть доступны до зависимой NAL-единицы в порядке декодирования. Наличие номера в заголовке не доказывает наличие определения. Наличие определения в сигнализации не доказывает, что именно эта версия была активна в нужную секунду.

RFC 3550 помогает понять предел трассы RTP. Номер последовательности служит для обнаружения потерь и восстановления порядка, метка времени — для момента дискретизации и синхронизации. Ни статус, ни исправления, ни Datatracker не превращают эти поля в реестр версий SPS/PPS. Доставка пакета и готовность контекста — разные факты.

RFC 3984 выделила три принципа передачи наборов. Принцип A — надёжно вне полосы до начала RTP-сеанса. Принцип B — надёжно вне полосы обновлять состояние во время сеанса. Принцип C — передавать наборы внутри самого RTP-потока. Документ 2005 года рекомендовал надёжный внеполосный путь для A и B. Для внутриполосной доставки требовались повтор, повторная передача либо прямая коррекция ошибок, поскольку одна потеря могла повлиять на много последующих NAL.

Начальные наборы мог переносить параметр sprop-parameter-sets в виде base64. Они должны были предшествовать ссылающимся на них единицам в порядке декодирования. Это не было объявлением возможностей приёмника. Параметр описывал предполагаемое состояние потока, но не доказывал, что приёмник поддерживает любую указанную конфигурацию.

Внеполосная передача связывала состояние с описанием сеанса. RFC 4566, её статус, исправления и запись Datatracker определяют SDP как формат описания. RFC 3264 задаёт offer/answer и допускает только одно незавершённое предложение; статус, исправления и история фиксируют этот порядок.

RFC 3984 советовала при внеполосном обновлении дождаться подтверждения сигнализации, прежде чем отправлять зависящие от него NAL. Но для расследования важно, что именно означало подтверждение: получение, проверку, запись или активацию. Само по себе оно не доказывает успешный вывод изображения.

Особенно трудно восстановить прежний смысл после ранней перезаписи идентификатора. Старые срезы могут оставаться в сети, очереди переупорядочивания или буфере декодера. Если тот же ID уже содержит новый PPS, старые единицы разрешают ссылку через новую таблицу. Контрольные суммы пакетов не обязаны заметить подмену контекста.

Поэтому спецификация предлагала выбирать давно не использовавшийся идентификатор либо добавлять новый. Безопасный срок должен покрывать путь, переупорядочивание, jitter-буфер и внутреннее удержание. Старое определение живёт до исчезновения последней зависимой единицы, а не до момента команды на замену.

В многоточечной системе к времени добавляется авторство. Два кодера способны выбрать один ID для разных наборов, оставаясь внутренне согласованными. На шлюзе значения сталкиваются. Необходим контроллер, который делит диапазоны, переписывает ссылки или изолирует контексты. Иначе локальная корректность не складывается в общую.

RFC 3984 также не разрешала без достаточной синхронизации смешивать обновления принципа B вне полосы и принципа C внутри потока. Поздний участник мог получить начальное SDP, но пропустить уже прошедшее внутриполосное обновление. Приёмник, потерявший такое обновление, сохранял старые правила, даже когда следующие изображения приходили без потерь.

RFC 6184 позднее изменила общую рекомендацию. Её статус, исправления и Datatracker показывают, что допускаются оба способа без общего предпочтения, а in-band-parameter-sets участвует в согласовании. Поэтому исторический вывод — не вечное превосходство внеполосного пути, а необходимость явно согласовать путь и момент смены состояния.

RFC 7798, её статус, исправления и история Datatracker позволяют сравнить задачу с HEVC поверх RTP. Повторение проблемы наборов параметров показывает устойчивость класса задач, но не доказывает распространённость конкретных реализаций.

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

Для будущего расследования нужны SDP-обмены, подтверждения, все версии SPS/PPS, происхождение каждого ID, смены типа полезной нагрузки и горизонт буферов. Следует фиксировать не только появление определения, но и момент его активации и окончания действия. Иначе точная трасса байтов не отвечает на вопрос, что эти байты означали для конкретного декодера.

RFC 3984 оставила важный урок об инфраструктурных доказательствах. Данные и правила их чтения имеют разные журналы и разные часы. Если сохранить только один, система может выглядеть полностью наблюдаемой, оставаясь необъяснимой. Управление версиями, именами и границей переключения — часть доставки смысла, а не необязательная метаинформация.

Источники