Кратко

  • RFC 2448 предлагал надёжнее доставлять информацию высокой важности (HP), оставляя видео низкой важности (LP) на обычном пути.
  • Получение HP не доказывает, что пришли LP, что обе части согласованы, что декодирование успешно или что кадр показан вовремя.

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

RFC 2448 перенёс это решение на сторону кодировщика или приложения. Отправитель отделял сегменты высокой важности HP, необходимые для декодирования, от остального потока LP. HP можно было передать надёжно до начала LP, поместить в отдельные RTP-пакеты, дублировать рядом с исходным непартиционированным потоком либо один раз отправить вне полосы и сохранить на приёмнике для повторного использования. Приоритет не обеспечивала сеть — систему строили вокруг разных путей надёжности.

Классификация становилась ключевым решением. В RFC сказано, что для определения HP нужны знания о синтаксисе и семантике алгоритма кодирования; универсального способа для любого битового потока нет. Пример MPEG-2 показывает цену выбора. HP только с заголовками обычно занимали менее 2% видеоданных. Добавление DC-коэффициентов могло увеличить долю примерно до 40% и дать некоторое пригодное видео только из HP, но надёжно доставлять пришлось бы гораздо больше информации. Это цифры примера из RFC, а не универсальные измерения видео.

Предварительная доставка HP уменьшает их подверженность потерям, но добавляет ожидание перед началом воспроизведения. Отдельные RTP-пакеты HP могут использовать свой тип полезной нагрузки и при этом разделять с основным потоком формат временных меток и пространство SSRC. Эти идентификаторы помогают координации, но не создают общей гарантии доставки. Отправитель также может оставить HP в исходном потоке и использовать отдельные копии только при потере.

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

Приёмнику нужно проверить больше, чем завершение надёжной передачи: относится ли HP к текущей версии кодека и правильному месту в LP; пришли ли нужные LP-данные; выдал ли декодер результат до срока воспроизведения; был ли результат показан. Полное получение HP само по себе не отвечает ни на один из этих вопросов.

RFC 2448 опубликован в ноябре 1998 года как информационный документ, а не стандарт Интернета. В нём упоминались патенты AT&T/Lucent и оговаривалось, что IESG и IETF не высказывают позицию об их действительности, объёме или доступности лицензии. Описание метода не доказывает его принятие, нынешнее развертывание, совместимость или пользу для зрителей. Исторический вывод уже: выборочная надёжность превращает транспортную задачу в политику кодека, а каждый дополнительный путь создаёт условие соединения, которое нужно наблюдать, а не предполагать.

Источники

RFC 2448; запись RFC 2448; карточка IETF Datatracker; список исправлений RFC 2448; RFC 2250, RTP-формат полезной нагрузки MPEG; RFC 3550, RTP; RFC 2198, дублированные аудиоданные; RFC 2733, FEC для RTP; RFC 5109, общий FEC для RTP; RFC 4588, повторная передача RTP; RFC 1191, определение MTU пути; RFC 1889, ранняя спецификация RTP; Heng Lu, приоритет исполняемого кода; Heng Lu, спецификация и добровольное принятие.