Кратко

  • RFC 2038 требовал такого разбиения, при котором начало следующего среза MPEG обнаруживалось без поиска внутри полезной нагрузки. Биты B и E объявляли положение RTP payload относительно границ среза.
  • Каждый видеопакет повторял Temporal Reference TR, Picture Type P и нужные параметры прямых и обратных векторов движения. При утрате GOP Header или Picture Header они позволяли собрать ограниченный заменяющий контекст у следующего среза.
  • Разрыв номеров, B/E и повторенное состояние обосновывают лишь локальное решение о перезапуске. Они не доказывают доставку предыдущих срезов, истинность заголовков, полноту изображения, наличие опорного кадра, правильность декодирования, непрерывность показа, получение зрителем или QoS.

Пакет с номером 7318 не появился в приемном журнале. Следующий, 7319, сообщает B=1, TR 4 и тип I, а поля векторов, как и положено для I-изображения, равны нулю. Приемник получил достаточно информации, чтобы прекратить ожидание утраченного продолжения и предложить декодеру новую границу среза.

Он не получил доказательства целого изображения. В пропавшем пакете могли находиться обязательные макроблоки. Объявление B могло не совпадать с настоящим start code. Декодер мог принять синтаксис и все же вывести искаженный участок либо ничего полезного. RFC 2038 не скрывал разницу между точкой, где можно попробовать снова, и результатом этой попытки.

Единица восстановления стала видна на уровне пакета

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

RFC 2038 задавал для этого деления строгие позиции. Video Sequence Header должен был начинать RTP payload. GOP Header начинал payload либо следовал сразу за Sequence Header. Picture Header начинал payload либо следовал за GOP Header. Каждый такой заголовок Elementary Stream целиком помещался в один пакет.

Особое правило касалось среза. Документ называл slice предусмотренной MPEG единицей восстановления после потери или повреждения. Его начало могло быть первым содержимым payload, идти после разрешенных MPEG-заголовков либо после целого числа завершенных срезов внутри того же payload. Сам срез при этом разрешалось фрагментировать по нескольким пакетам. Равенства «один пакет — один срез» не было.

После потери приемнику больше не требовалось просматривать произвольные байты, пытаясь угадать следующий start code. Пакетизатор размещал возможную точку входа там, где ее можно было объявить. Кодек определял смысловую границу, специализированный RTP-заголовок делал ее видимой. Но транспортные метаданные не получали права удостоверять содержимое MPEG.

B и E сообщали форму выравнивания

После фиксированного RTP-заголовка находился 32-битный видеозаголовок. B=1 означал, что payload начинается с кода начала среза, возможно после одного из разрешенных заголовков Sequence, GOP или Picture. E=1 означал, что последний байт payload завершает MPEG-срез.

Четыре сочетания позволяли различать пакет, выровненный по обеим границам; начало среза с продолжением; продолжение, которое заканчивает срез; и только промежуточный фрагмент. Такую форму приемник знал до глубокого разбора сжатых данных.

Однако B=1 был заявлением отправителя, а не проверкой фактического start code. E=1 не подтверждал присутствие остальных частей среза. Даже пакет с обоими установленными битами мог следовать за разрывом, где исчезла другая часть изображения. Пакет без обоих битов мог быть безупречно доставлен, но оставаться бесполезным без своего начала.

Точная формулировка свидетельства такова: B/E показывают состояние границы, записанное в заголовке. Настоящий MPEG-синтаксис, завершенность среза и пригодность для декодера проверяются отдельно.

В каждом пакете повторялось малое досье изображения

Десятибитное поле TR несло Temporal Reference текущего изображения внутри GOP и было одинаковым во всех RTP-пакетах этого изображения. Трехбитное P обозначало I-, P-, B- или D-изображение и тоже не менялось внутри него.

Еще четыре поля переносили из последнего Picture Header признаки full-pel и f-code для обратных и прямых векторов движения. Для I-изображений они обнулялись. P-изображения использовали прямую пару, обнуляя обратную. B-изображения могли использовать все четыре. Это была не копия изображения и не полный исходный заголовок, а минимальный набор для выбранных действий восстановления.

Если единственный Picture Header пропадал с пакетом, одна лишь последующая граница среза не сообщала декодеру тип изображения и способ трактовки векторов. Повторение переносило эти значения к каждой потенциальной точке продолжения и разрывало зависимость на следующем пригодном срезе.

Повторы также давали сигнал согласованности. Неожиданная смена TR или P могла указывать на потерянный GOP Header или Picture Header. Приложение предлагало вести счетчики опорных и зависимых изображений и сравнивать ожидаемое продвижение с полученным Temporal Reference. Несовпадение показывало расхождение ожидания и объявления. Оно не восстанавливало исходные байты заголовка и не объясняло причину исчезновения.

Реконструкция была явной аппроксимацией

При потере GOP Header RFC предлагал создать замену с нулевым time code, значением closed_gop от предыдущей GOP и broken_link=1. Потерянный Picture Header можно было собрать у следующего Beginning-of-slice из P, TR, четырех полей векторов и зависящих от потока значений по умолчанию.

Такая операция не возвращала оригинал побайтно. Нулевой time code не был утраченным временем отправителя. Старый closed_gop не являлся независимым наблюдением нового GOP. Значение по умолчанию оставалось предположением приемника. broken_link=1 честно фиксировал, что предсказательной связи через разрыв доверять нельзя.

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

Разрыв последовательности запускал локализацию ущерба

Приложение описывало практический порядок: обнаружив потерю по разрыву номеров RTP, приемник мог отбрасывать последующие пакеты до первого Beginning-of-slice. Там было достаточно ограниченного состояния, чтобы начать MPEG-обработку, при необходимости сначала заменив GOP Header или Picture Header.

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

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

Семь квитанций нельзя сворачивать в слово «восстановлено»

При расследовании следует разделять как минимум семь наблюдений: непрерывность RTP-последовательности; объявление B/E; реально разобранный синтаксис MPEG-границы; повторенные TR/P/векторы; наличие и целостность нужных опорных изображений; вывод декодера и маскирование ошибок; временную подачу и наблюдение зрителя.

Ранний уровень может служить основанием для следующей проверки, но не заменяет ее. Согласованные B/E не доказывают полный кадр. Правдоподобные TR/P не являются утраченным заголовком. Успешный разбор не доказывает правильное предсказание. Выходной кадр не доказывает непрерывный показ. Событие проигрывателя не доказывает, что человек увидел и принял результат.

RFC 2038 был опубликован в октябре 1996 года как Proposed Standard и заменен RFC 2250 в январе 1998 года. Нынешний реестр параметров RTP у IANA перечисляет статический payload type 32 как MPV с частотой 90 кГц и ссылается на RFC 2250. Эта запись доказывает выделение параметра, но не современное внедрение, качество реализации или применение в конкретной сети.

Долговечный вывод из недолго действовавшего стандарта не зависит от формата видео. Устойчивость растет, когда реальная единица восстановления сжатого потока видна на границе пакета, а рядом повторяется минимально необходимое состояние. Граница перезапуска разрешает попробовать снова; она не доказывает целостность изображения до или после нее.

Источники