Кратко

  • В RFC 3016 граница RTP-пакета стала границей отказа: агрегация сокращала накладные расходы, но связывала судьбу нескольких видеоблоков и могла лишить следующие данные точки повторного входа.
  • Sequence number, timestamp и marker описывали транспортную структуру. Они не доказывали наличие конфигурации, успешный decode, показ изображения или восприятие человеком.

В обоих испытаниях отправили по два RTP-пакета и потеряли второй. В первом случае пропал только второй логический видеоблок. Во втором — оба. Сетевой график был одинаковым: одна последовательность, одна дыра. Различалось лишь размещение внутренней зависимости.

Именно эта разница делает RFC 3016 больше, чем инструкцией по упаковке MPEG-4.

Документ вышел в ноябре 2000 года и описал прямую передачу MPEG-4 Audio и MPEG-4 Visual через RTP без функций синхронизации и управления потоками MPEG-4 Systems. H.323 мог применять H.245, SIP и RTSP — MIME и SDP. Для приложений это давало единый способ работы с MPEG-4 и другими RTP-кодеками.

Однако packetizer теперь решал, где заканчивается одна независимо переживающая потерю часть и начинается другая. Он соединял синтаксис кодека с отказами сети.

Синтаксическая вершина должна была пережить границу

В MPEG-4 Visual уже имелись механизмы устойчивости. RFC 3016 не создавал дополнительный медиазаголовок RTP, а напрямую помещал выровненный по байтам Visual bitstream в payload, не удаляя его элементы.

Прямое отображение подчинялось порядку. Конфигурация и Group_of_VideoObjectPlane должны были стоять в начале payload или сразу после синтаксически более высокого заголовка. Если заголовки присутствовали, payload начинался с самого высокого. Делить заголовок между RTP-пакетами запрещалось.

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

RFC рекомендовал отправлять один video packet в одном RTP packet и подбирать размер ниже Path MTU. При высокой вероятности потерь другие video packets могли оставаться декодируемыми благодаря Header Extension Code, даже если пакет с VOP header не дошёл.

Для малых блоков RTP/IP-заголовки были дорогими. Несколько блоков разрешалось объединить. Цена была прямой: одна потеря RTP выбрасывала все вложенные video packets.

Так оптимизация байтов меняла единицу ущерба.

Две одинаковые дыры имели разную причинность

Запрещённая схема RFC распределяла два логических video packets по двум RTP packets. В корректной раскладке потеря второго удаляла только второй видеоблок. В другой первый блок пересекал границу, а заголовок второго находился после его продолжения; потеря второго RTP уничтожала оба.

Количество переданных байтов могло быть близким. Счётчик потерь не различал случаи. Для восстановления решающим оказалось не число оболочек, а место, где лежал смысл.

Поэтому процент потерь не равен проценту утраченного видео. За одним sequence gap могли скрываться независимый фрагмент, несколько агрегированных блоков, точка синхронизации или конфигурация, от которой зависело продолжение.

Если coder отключал video packets, VOP разрешалось делить на произвольных байтовых позициях. На гарантированно безошибочном пути это допускало равные фрагменты. В сети с ошибками RFC считал такую схему плохо устойчивой. Разрешение стандарта не доказывало, что эксплуатационное условие выполнено.

Marker описывал конец отправленной конструкции

Для Visual marker ставился на последнем или единственном RTP-пакете VOP. При нескольких VOP в одном payload он тоже устанавливался, timestamp относился к самому раннему, а дальнейшие времена вычислялись из внутренних заголовков.

Это помогало depacketizer, но не подтверждало результат. Пакет с marker мог потеряться; он мог прийти без предыдущего фрагмента; собранную единицу мог отвергнуть decoder; готовое изображение могла не показать программа.

Общий RTP определяет sequence number для обнаружения дыр и восстановления порядка. Timestamp отражает sampling instant и нужен для синхронизации; фактическая презентация происходит позже. Значение marker задаёт формат payload. Это не универсальный флаг «зритель увидел».

Звуковая конфигурация делала прошлое условием будущего

MPEG-4 Audio использовал LATM. Полный audioMuxElement или его часть помещались прямо в RTP payload, начиная с первого байта. Один элемент на пакет рекомендовался; превышающий Path MTU элемент мог быть фрагментирован.

В режиме in-band useSameStreamMux позволял применить StreamMuxConfig предыдущего frame. Экономия повторов создавала состояние. Если предыдущий frame терялся, текущий мог не декодироваться, хотя пришёл целиком. Поэтому RFC рекомендовал повторять конфигурацию в зависимости от сетевых условий.

Интервал повтора определял глубину зависимости. В out-of-band режиме config мог прийти через SDP, но тогда правильность зависела от канала сигнализации, версии и привязки к потоку.

Один потерянный пакет мог унести не звук, а право понимать последующие звуки.

Capability не заменяла текущую configuration

Для Visual параметр profile-level-id описывал комбинацию инструментов, которую codec способен поддержать. config описывал конфигурацию конкретного bitstream и не должен был применяться как capability.

Приёмник мог поддерживать общий набор и не иметь состояния этого потока. Одинаковый Profile/Level не доказывал одинаковых параметров. SDP описывал предполагаемую сессию, но не наблюдал доставку и декодирование.

FEC защищал уже сформированную ставку

RFC 3016 допускал Generic FEC из RFC 2733 и резервный звук из RFC 2198. Но FEC получал source packets после того, как packetizer определил их содержимое.

Это отделяет тезис от опубликованной статьи о RFC 2733. Та посвящена parity, условиям восстановления, задержке и bandwidth. Здесь рассматривается более раннее решение: сколько логических единиц и зависимостей оказалось внутри одного защищаемого объекта.

RFC 2429 даёт другой контраст. Формат H.263+ добавлял payload header и мог копировать picture header, позволяя декодировать пакет после потери исходного заголовка. RFC 3016 полагался на встроенные средства MPEG-4 Visual. Общий RTP не делал контракты восстановления одинаковыми.

RFC 6416 обнаружил несовместимость под тем же семейным именем

В 2011 году RFC 6416 заменил RFC 3016, исправляя несовпадения MPEG-4 Audio с 3GPP PSS. Обязательная новая версия LATM была бинарно несовместима с той, на которую ссылался старый текст. Изменились StreamMuxConfig, SBR, Parametric Stereo, rate, каналы и сигнализация scalable layers.

Некоторые реализации под вывеской «RFC 3016» уже применяли более новый LATM и могли фактически быть ближе к RFC 6416, то есть не соответствовать буквальному старому документу. Номер RFC не был wire fingerprint.

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

Подлинность пакета не меняла его внутреннюю зависимость

RFC 3016 наследовал вопросы безопасности RTP и допускал шифрование после сжатия. Ограниченный аудио-видео payload не переносил MPEG-J applets и scripts полного MPEG-4 Systems.

Confidentiality, integrity и source authenticity защищают содержимое и происхождение. Они не уменьшают пакет до Path MTU, не возвращают потерянную конфигурацию и не разделяют агрегированные блоки. Подлинный пакет может оставаться слишком крупной единицей отказа.

RFC не назначал универсальный оптимум: bitrate, loss, MTU и возможности кодека различались. Вместо этого он защищал ключевые синтаксические границы и называл цену локального выбора.

Две потери, одинаковые для сетевого счётчика, разрушали разное. RFC 3016 объяснил, где искать разницу.

Источники