Кратко

  • RFC 2032 запрещал делить один макроблок H.261 между RTP-пакетами. Каждый пакет начинался и заканчивался на границе макроблока.
  • GOBN, MBAP, QUANT, HMVD/VMVD и I/V переносили состояние, нужное для нового начала. Это возвращало читаемость синтаксиса, но не потерянный участок изображения.
  • Необязательные сообщения FIR и NACK просили полный INTRA-кадр или называли отсутствующие номера последовательности. Координаты запроса не подтверждали доставку, исполнение и своевременное отображение результата.

В сжатом видео грамматика способна восстановиться раньше изображения. RFC 2032 проектировал именно эту промежуточную реальность.

Документ вышел в октябре 1996 года как Proposed Standard и определил прямую передачу H.261 по RTP. Кодек создавался для каналов ISDN с фиксированной скоростью, где 512-битные кадры H.221 объединяли видео, звук, данные и коррекцию ошибок. Интернет-формат не переносил эту оболочку, а помещал в RTP сам Huffman-кодированный видеопоток. Потеря дейтаграммы оставалась возможной; задача состояла в том, чтобы она не лишала смысла весь последующий поток.

Граница макроблока стала границей отказа

Изображение H.261 делится на группы блоков, по 33 макроблока в каждой. Макроблок соответствует области 16 на 16 пикселей. RFC 2032 выбрал его единицей фрагментации: пакет должен начинаться и завершаться на границе макроблока, не разрезая его. Нельзя было также разорвать заголовок GOB и первый макроблок.

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

Синтаксическая самостоятельность не означает визуальной. H.261 использует межкадровое предсказание и разности. Верно разобранный макроблок может ссылаться на уже повреждённую область опорного изображения. RFC прямо предупреждает: искажение способно сохраняться, пока соответствующие макроблоки снова не будут закодированы в режиме INTRA. Точка входа сужает неизвестность, но не возвращает прошлые пиксели.

Четыре байта сохраняли память начала

SBIT и EBIT указывают число невидеобитов в первом и последнем октетах. Так побитовый синтаксис H.261 укладывается в пакеты, выровненные по байтам.

GOBN определяет группу блоков в начале пакета; ноль означает начало с заголовка изображения. MBAP хранит предиктор адреса макроблока относительно начала GOB. QUANT сохраняет значение квантователя для следующего макроблока. HMVD и VMVD несут горизонтальные и вертикальные опорные данные для восстановления разностей векторов движения.

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

Биты I и V — осторожные подсказки. I сообщает, что поток содержит только INTRA-макроблоки; V — что могут использоваться векторы движения. RFC допускает их вывод из потока и разрешает реализации консервативные V=1 и I=0. Они помогают выбрать безопасный путь декодирования, но не проверяют каждый макроблок и не измеряют качество.

Отмеченный конец не означал полный кадр

Все RTP-пакеты одного изображения используют общий временной штамп с частотой 90 кГц. Бит marker ставится в последнем пакете кадра, чтобы получатель не ждал стартового кода следующего изображения. Если пакет содержит несколько изображений, RTP-метка относится только к первому; время последующих выводится из заголовков H.261.

Эти сигналы описывают время и заявленный конец. Marker не подтверждает доставку всех прежних номеров последовательности. RTP позволяет увидеть пробел, тогда как сама отправка по UDP не сообщает источнику об успешном приёме. «Получен последний пакет» и «получен полный кадр» — разные наблюдения.

Локализация ошибки не была исправлением

RFC 2032 перечисляет три способа сократить стойкое повреждение: периодический полностью INTRA-кадр, изменение частоты обновления по уровню потерь и запрос обновления от декодера. Каждый способ может открыть контур управления. Ни один сам по себе не фиксирует его замыкание.

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

FIR и NACK адресовали намерение

RFC определил два необязательных сообщения RTCP для H.261. Full INTRA-frame Request с Payload Type 192 просил кодер сделать следующий кадр полностью INTRA; SSRC обозначал получателя, пославшего просьбу. Negative Acknowledgement с типом 193 использовал FSN для первого считающегося потерянным номера RTP, а 16-битный BLP — для следующих шестнадцати номеров.

FIR означает «обновите основу предсказания». NACK означает «эти позиции я не наблюдал». Локальный диагноз получает адрес, пригодный для действия.

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

Перехваченный FIR доказывает отправку просьбы, но не её доставку и не появление INTRA-кадра. NACK доказывает представление получателя о потерях, но не наличие повторной передачи, её своевременность или показ исправленного изображения. Чтобы замкнуть доказательство, нужны действие источника, последующие пакеты, результат декодера и срок показа.

Общая спецификация остановилась до результата

Принцип минимальной начальной спецификации Лу Хэна точно показывает границу. RFC 2032 стандартизировал общие точки разреза, контекст возобновления, время, конец кадра и необязательный синтаксис обратной связи. Срок буфера, стратегия обновления, цена INTRA-кадра и допустимое искажение остались локальными решениями.

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

Сегодня RFC Editor отмечает RFC 2032 как заменённый RFC 4587. Без разбора механики преемника исторический вывод уже ясен: одна потеря должна была делать непонятной меньшую часть потока, а намерение исправить получило координаты. Исправленное изображение всё равно требовало отдельного подтверждения.

Источники