Summary

  • Журнал кодировщика может подтвердить создание точки обновления, но не полноту RTP-пакетов у получателя, пригодность параметров, сброс ссылочного состояния или вывод кадра.
  • Восьмибитная последовательность FIR различает новый запрос и повтор в пределах пары SSRC; это идентичность управляющего поколения, а не шкала восстановления сервиса.

После инцидента в отчёт переносят одну строку: источник создал IDR через несколько миллисекунд после FIR. Строку называют доказательством восстановления пользователя. Между этими событиями исчезают очередь, сеть, MCU, сборка пакетов, декодер и рендерер. Хороший журнал источника становится плохим итоговым выводом именно потому, что ему приписали чужую область наблюдения.

RFC 5104 добавляет к AVPF набор сообщений управления кодеками. Full Intra Request просит точку обновления декодера. TSTR и TSTN относятся к выбору между временным и пространственным качеством, VBCM переносит обратную связь H.271, а TMMBR и TMMBN описывают временное ограничение общей медиаскорости и ограничивающее множество. Эти сообщения нельзя свести к общей кнопке «подтверждено».

Запись FIR указывает SSRC медиапередатчика и содержит восьмибитный номер последовательности. Пространство номера принадлежит конкретной паре: SSRC отправителя обратной связи и целевой SSRC. Новый запрос увеличивает номер по модулю 256; повтор того же запроса сохраняет значение.

Это позволяет не принять задержавшуюся копию за новую команду и не заставляет кодировщик заново выполнять дорогое действие при каждом повторе. Номер не кодирует факт принятия, время создания, диапазон RTP-пакетов, потерю, состояние декодера или показ. Без сессии, пары SSRC и временного контекста одинаковый номер после оборота счётчика вообще неоднозначен.

Точка обновления — не просто метка IDR в журнале. По смыслу RFC это последовательность битов в одном или нескольких RTP-пакетах, полностью возвращающая декодер в известное состояние. Она может быть внутрикодированным изображением, IDR или постепенным обновлением. Если дальнейшее декодирование требует параметров выше слоя изображения, они тоже должны присутствовать в потоке.

RFC 6184 показывает на примере H.264, почему отправка одной единицы или всплеск размера не доказывают полноту. Фрагмент может потеряться, требуемые параметры могут не прийти, а набор пакетов может относиться к источнику, который MCU уже перестал показывать данному получателю. Нужна проверка с пониманием кодека и эпохи выбора.

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

Дальше медиаданные проходят очередь и транспорт. Отчёт «IDR отправлен» обычно не сообщает, означает ли это постановку в очередь, передачу последнего байта интерфейсу или наблюдение за выходным RTP. Даже самый точный вариант остаётся источниковым свидетельством. Чтобы утверждать доставку, нужен принимающий наблюдатель с диапазоном пакетов и потерями.

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

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

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

Но распознанная медиапопытка — не конец. Наблюдатель кодека определяет, полна она или повреждена. Сам декодер подтверждает сброс опорного состояния и возможность продолжить предсказание. Рендерер подтверждает предъявление кадра. Приложение определяет пользовательское восстановление. Каждый переход может дать отдельную ошибку и отдельное время.

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

MCU создаёт ещё один разрыв цепочки. В топологиях RFC 5117 переключающий MCU может принять FIR от зрителя и сформировать другой FIR к выбранному источнику. RFC 5104 считает надёжность участков зритель–MCU и MCU–источник независимой.

Входная команда может дойти, а выходная потеряться. Источник может создать обновление, пока MCU меняет выбранного говорящего. MCU может получить полный набор и не доставить часть последнего участка. Запись источника не содержит ни одного из этих переходов. Для каждого участка нужны свой SSRC-контекст, безопасность, часы и квитанция медиаданных.

Смена источника требует связи с эпохой. Настоящий IDR от A не восстанавливает пользователя, если к моменту доставки тот уже должен получать B. И наоборот, поздние пакеты B нельзя привязывать к FIR, направленной A. В журнале следует сохранять решение переключения и его неопределённость, а не исправлять временные метки ради красивой последовательности.

FIR не предназначена для всякой обычной потери изображения. Для неё RFC 5104 рекомендует Picture Loss Indication из RFC 4585. FIR нужен, когда без обновления видео остаётся непригодным: при входе нового участника без регулярных точек или после переключения MCU на иной кодированный источник.

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

TSTR и TSTN показывают другую модель ответа. TSTR просит изменить соотношение временного и пространственного качества, а TSTN сообщает реально выбранное значение. Кодировщик учитывает несколько получателей, ресурсы и местную политику, поэтому выбор может не совпасть с просьбой. Уведомление подтверждает решение, не буквальное выполнение запроса.

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

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

Защита сообщений решает другую задачу. Поддельная обратная связь способна навязать крайне низкую скорость, ложно присвоить владение ограничением, изменить предпочтение качества или породить столько обновлений, что видео начнёт заикаться. RFC 3711 и профиль SAVPF в RFC 5124 дают аутентификацию и целостность.

Аутентифицированная FIR — сильное доказательство команды: известно, какой субъект говорил в защищённом контексте и какие байты защищены. Она не аутентифицирует будущие события в кодировщике, сети, декодере или рендерере. Подлинность отвечает на вопрос о говорящем, а не о полном исполнении всей цепи.

RFC 5104 сохраняет статус Proposed Standard и обновлена RFC 7728 для приостановки и возобновления RTP-потока, а также RFC 8082 для слоистых кодеков. Сборщик, знающий только исходные поля, может не учитывать паузу или целевой слой и сделать ложный вывод даже из правильно разобранного пакета.

Защитимый журнал инцидента связывает контекст RTP и защиты, исходный и целевой SSRC, поколение FIR и повторы, участки MCU, приём кодировщиком, создание обновления по правилам кодека, диапазон RTP и потери, распознавание полной или повреждённой попытки, сброс декодера, предъявление кадра и пользовательский сигнал приложения. Он сохраняет неопределённость времени и изменения топологии.

Такой подход следует дисциплине слоёв реальности Heng Lu. Источник имеет право свидетельствовать о создании. Сеть — о доставке. Декодер — о состоянии. Рендерер — о показе. Руководство соединяет эти квитанции для решения о сервисе, но не должно превращать одну честную строку журнала в полномочие говорить за все последующие системы.

Sources