Кратко

  • Каждая RTP-нагрузка CellB начинается с четырёх 16-битных целых: X/Y первой ячейки размером 4×4 пикселя и ширины/высоты изображения в пикселях.
  • Многобайтовый код обязан целиком находиться в одном пакете. После пропажи промежуточного пакета следующий целый пакет начинается с границы кода и сообщает собственную пространственную позицию.
  • Механизм локализует ущерб, но ничего не реконструирует. Координаты, размеры, общий timestamp кадра и конечный Marker не доказывают полноту ячеек, совпадение таблиц квантования, верный результат декодера или непрерывное воспроизведение.

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

Опубликованный в октябре 1996 года RFC 2029 решал вторую задачу. Формат RTP для CellB не обещал восстановить потерянную область. Он давал каждому уцелевшему пакету достаточно локальной информации, чтобы тот не зависел от конца своего предшественника.

Пространственный адрес повторялся в каждой нагрузке

Перед сжатыми данными расположены Cell X Location, Cell Y Location, Width of Image и Height of Image. Все четыре поля—беззнаковые 16-битные числа в сетевом порядке байтов.

X и Y измеряются не пикселями, а ячейками. Одна ячейка CellB представляет блок 4×4 пикселя. Ширина и высота, напротив, записываются в пикселях. Получатель узнаёт одновременно начальную позицию в сетке и размер холста.

Размер может измениться только между кадрами, однако передаётся в каждом пакете. Повторение снимает зависимость от ранее полученного заголовка: даже после потери новый пакет знает границы изображения.

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

Сетевой разрез совпадал с синтаксическим

В потоке CellB есть коды разной длины. Обычный четырёхбайтовый код описывает одну ячейку. Однобайтовый skip code пропускает от одной до 32 ячеек. Ещё две команды объявляют новые таблицы Y/Y и U/V, после каждой следуют 512 байт.

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

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

Это не исправление ошибок в значении утраченных данных. RFC 2029 не добавляет повторную передачу, FEC, копию ячеек или алгоритм дорисовки. Пустая область остаётся пустой; формат не даёт ей автоматически испортить разбор всего остатка.

Timestamp объединял пакеты, а Marker не проводил перепись

CellB использует RTP-частоту 90 кГц. Все пакеты одного кадра несут одинаковый timestamp, а Marker отмечает последний. Эти поля образуют временную рамку для блоков с пространственными адресами.

Общий timestamp не сообщает, сколько пакетов должно быть внутри. Marker показывает заявленный отправителем конец, но не подтверждает доставку всего перед ним. RTP sequence number помогает обнаружить разрыв и восстановить порядок отправки. Базовый RFC 1889 одновременно предупреждает: RTP не гарантирует доставку, своевременность, порядок прихода и качество обслуживания.

Получить пакет с Marker и правильными координатами можно даже при дыре в середине кадра. Метаданные подтверждают маркировку уцелевшего пакета, а не отсутствие утрат.

Потерянная таблица оставляет правильное место и неправильные пиксели

Поля U/V и Y/Y в коде ячейки—индексы в таблицах векторов цветности и яркости. Смысл индекса зависит от текущей версии таблицы в декодере.

RFC 2029 описывает команды замены каждой таблицы 512 новыми байтами. Примерные encoder и decoder из документа эту возможность не реализовывали, но она была предусмотрена для будущих codec. Правило границы гарантирует, что полученное обновление не будет разрезано между пакетами.

Если пропадёт весь пакет обновления, последующая нагрузка всё равно может иметь полный код, верную координату и нужный timestamp. Получатель, однако, способен применить старую таблицу. Место блока установлено правильно, значения пикселей—нет.

Это не зафиксированный RFC инцидент, а вывод из устройства формата. Самодостаточность по позиции и синтаксису не означает самодостаточности по всей предшествующей истории состояния.

От транспортного факта до просмотра остаётся цепочка

Для расследования нужно отдельно хранить sequence number, координаты и размеры, границы кодов, группы timestamp и Marker. Затем проверяются версия таблиц, результат decoder, покрытие изображения, время rendering и вывод на конечном устройстве.

Только фактические нагрузки и карта покрытия могут поддержать утверждение о полном кадре. Только состояние таблиц и вывод decoder—о правильных пикселях. Только измерения на конце—о качестве просмотра. Заголовок CellB не заменяет эти уровни.

IANA до сих пор указывает CelB как фиксированный RTP payload type 25 для видео с частотой 90 000 Гц и ссылкой на RFC 2029. Это надёжное свидетельство назначения параметра, но не современного трафика или внедрения. Статус Proposed Standard также не подтверждает работу конкретной реализации.

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

Источники