Кратко

  • RFC 9627 вводит адресную RTCP-команду для обновления отдельных слоёв масштабируемого видео, чтобы не выполнять полное обновление, требуемое Full Intra Request, когда нужен лишь ограниченный переход.
  • SSRC источника и цели, payload type, текущий и целевой слои и номер последовательности определяют запрос и его повторы; они не подтверждают допуск, кодирование, доставку, новый режим декодера или показанный кадр.
  • Полная операционная квитанция связывает согласование, полномочие, проверку, очередь при перегрузке, codec-специфический refresh point, приём, распознавание, декодирование и отображение.

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

Каждая запись может быть правдивой. Не доказана только связь между ними. RFC 9627 определяет Layer Refresh Request как просьбу создать точку, после которой получатель сможет декодировать больше слоёв. Он не превращает эту просьбу в сквозную транзакцию.

Refresh point меняет допустимое прошлое

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

Остальные слои могут сохранить прежние зависимости. Поэтому LRR отличается от FIR. Full Intra Request требует более полного обновления состояния декодера; RFC 8082 уточняет этот смысл для слоистых кодеков. LRR ограничивает стоимость переходом, который действительно нужен.

Для временного слоя обновление означает вложенность на нижние временные уровни без ссылки на собственные старые кадры. Если поток уже всегда temporal-nested, верхний уровень можно начать без специального запроса. В таком режиме temporal LRR ничего не открывает.

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

Поля команды описывают переход и его адрес

LRR — Payload-Specific Feedback в RTCP с FMT=10. В FCI допускается несколько записей, каждая для SSRC отдельного отправителя медиа. SSRC packet sender в общем заголовке указывает источник команды; общее поле media source равно нулю, потому что цели перечислены внутри FCI.

TTID/TLID задают целевой временной и пространственный либо качественный слой. Payload type сообщает, по какой codec-карте трактовать числа. Сам tuple без offer/answer и соответствия payload type не сохраняет исходный смысл.

Флаг C определяет область. При нуле обновляются все слои до цели. При единице CTID/CLID называют высший слой, который получатель считает уже декодируемым, и исключают его и нижние уровни. Цель не может быть ниже ни по одной оси и должна быть выше хотя бы по одной. Нарушающий правило запрос отбрасывается.

Отправитель дополнительно проверяет, действительны ли payload type и индексы для текущего потока. Синтаксически корректный пакет ещё не уполномочен локальной политикой и не гарантирует наличия требуемой конфигурации кодировщика.

Наконец, «текущий» слой — утверждение получателя в момент команды. Это не последующее наблюдение декодера. Tuple фиксирует исходную точку намерения, но не подписывает конечное состояние.

Sequence number — идентификатор приказа, а не ACK

Восьмибитное пространство номеров существует отдельно для каждой пары command-source SSRC и command-target SSRC. Новая команда увеличивает номер по модулю 256. Повтор оставляет его прежним. Начальное значение произвольно.

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

Это полезно для ответа на вопрос, новая ли перед нами воля или копия прежней. Но поле не является подтверждением приёма. В нём нет решения кодировщика, времени действия, ID созданного кадра, доставки или результата decoder.

После 256 новых команд число повторится. Без сессии, времени, пары SSRC, payload type и tuple значение нельзя считать устойчивым ключом аудита.

Перегрузка имеет право отложить выполнение

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

Норма распределяет решения. Получатель формулирует желаемое изменение. Отправитель проверяет возможность. Контроль прямого пути выбирает момент, когда дополнительные биты допустимы. Если допуск сразу превращается в «готово», исчезает состояние ожидания, объясняющее задержку.

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

Нельзя смешивать и причины. RFC 9627 запрещает LRR как реакцию на потерю либо повреждение картинки и рекомендует PLI из RFC 4585. LRR означает явное изменение поведения — например, начать использовать ранее отбрасываемый слой. Одна и та же команда для ремонта и расширения лишает повторы диагностического смысла.

Каждый codec закрывает запрос по-своему

H.264 SVC распределяет слой между temporal, dependency и quality identifiers. Пространственное обновление может завершиться только после нужных признаков на всех слоях в порядке декодирования. Агрегированный PACSI не всегда раскрывает, какой NAL unit какого слоя дал признак.

VP8 в указанном payload format поддерживает временное масштабирование. Бит Y отмечает точку переключения, но распространяется на все слои. Узкий запрос способен вызвать более широкую и дорогую реакцию.

H.265 использует nesting flags и типы NAL. Обновление может завершиться одним событием, постепенно пройти несколько уровней либо быть удовлетворено IRAP picture. Универсальный счётчик keyframe неверно классифицирует эти варианты.

RFC 9628 задаёт для VP9 TID/SID и рекомендует включать сведения о слоях и ссылках, чтобы decoder или selective forwarder мог восстановить цепь. Универсальный критерий таков: перестал ли целевой слой зависеть от материала, которого нет у данного получателя?

Формат специально согласован с TID/LID из RFC 9626. Frame marking помогает наблюдать структуру, но не доказывает, что её вызвал LRR, что пакеты пришли полностью или что декодер воспользовался ими.

Источники