Кратко
- RFC 9584 определяет одиночный пакет NAL, пакет агрегации и единицу фрагментации для EVC. Они формируют вход декодера, но не удостоверяют готовое изображение.
- Номер последовательности, маркер, timestamp, DON, PLI и FIR имеют ограниченный смысл. Для воспроизведения нужны отдельные квитанции вплоть до поверхности дисплея.
У чёрного экрана может быть идеальная сетевая биография. Пакеты пришли по порядку, последний пакет access unit отмечен, временная шкала движется без скачков. Но у декодера нет опорного изображения или поддерживаемого набора инструментов. Сетевая запись не ложна — она просто закончилась слишком рано, чтобы описать пользовательский результат.
RFC 9584 опубликован в июне 2024 года в стандартизационном потоке IETF и описывает RTP payload для Essential Video Coding. Одна NAL может занять пакет целиком. Несколько NAL одной access unit можно агрегировать. Большую NAL можно разнести по нескольким FU. Формат сознательно наследует подходы H.264, HEVC и VVC. Знакомая схема уменьшает новую сложность, но не доказывает совместимость конкретных реализаций.
Номер последовательности RTP помогает восстановить порядок отправителя, а не гарантирует доставку. Точка наблюдения тоже может пропустить пакет или увидеть тот, который позднее отбросит конечное устройство. Бит M отмечает последний пакет access unit в потоке, но не подтверждает все предыдущие. Частота timestamp 90 кГц задаёт временную опору для показа, однако не является записью фактического показа. SSRC различает источник в RTP, не заменяя аутентификацию.
Во фрагментированной NAL биты S и E отмечают начало и конец. Восстановление требует последовательного объединения всех FU между ними. Если один фрагмент потерян, приёмник обычно должен отбросить следующие FU этой NAL, если только декодер не умеет безопасно работать с неполным объектом. Полученный конец не превращает отсутствующую середину в данные.
Пакет агрегации содержит как минимум две NAL одной access unit в порядке декодирования. Внутри не может быть FU или другой агрегации. Эти ограничения делают оболочку проверяемой. Но внутри всё ещё возможны неверный синтаксис, отсутствующий SPS/PPS/APS, неподдерживаемый профиль либо ссылка на недоступное изображение. Целая посылка не доказывает исполнимость содержимого.
DONL и DOND участвуют в вычислении AbsDon, по которому NAL упорядочиваются перед декодером. Пропуски могут быть нормальными: шлюз вправе не пересылать высокие временные слои или отдельные SEI. При равных значениях допустим любой порядок. Это отношение между входами, а не свидетельство успешного декодирования, выхода изображения или соблюдения времени показа.
Стандарт различает буфер депакетизации и практический jitter buffer. Первый извлекает, собирает и сортирует NAL; второй компенсирует колебания сетевой задержки. Достаточный объём первого не резервирует время для второго, ресурсы декодера или очередь рендеринга. Единый показатель «буфер в норме» может оставаться зелёным после потери срока презентации.
PLI сообщает о потере неопределённого количества кодированных данных одного или нескольких изображений. FIR требует IDR-изображение и, если параметры не установлены вне потока, их повторную отправку. Запрос восстановления, передача IDR, получение, декодирование и появление на экране — разные события. Управляющее сообщение не является квитанцией о результате.
RFC прямо указывает, что payload format сам по себе не образует полную систему. RTP не резервирует ресурсы и не гарантирует качество обслуживания. Конфиденциальность, целостность и подлинность источника зависят от механизмов, выбранных приложением. Запись IANA video/EVC подтверждает согласованное имя, но не наличие продукта или успешное использование.
Надёжная цепочка разделяет: приём на нужном endpoint; проверку источника и целостности; наличие всех фрагментов; сборку NAL; определение порядка; принятие параметров и возможностей; выход изображения из декодера; соблюдение срока; commit рендерера; обновление поверхности. Квитанция одного шага разрешает следующий. Она не имеет права заранее объявить его результат.
Источники
- https://www.rfc-editor.org/rfc/rfc9584.html
- https://www.rfc-editor.org/info/rfc9584
- https://datatracker.ietf.org/doc/rfc9584/
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-evc/history/
- https://www.rfc-editor.org/errata/rfc9584
- https://www.rfc-editor.org/rfc/rfc3550.html
- https://www.rfc-editor.org/rfc/rfc4585.html
- https://www.rfc-editor.org/rfc/rfc5104.html
- https://www.rfc-editor.org/rfc/rfc8866.html
- https://www.rfc-editor.org/rfc/rfc3711.html
- https://www.rfc-editor.org/rfc/rfc7798.html
- https://www.rfc-editor.org/rfc/rfc9328.html
- https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml
- https://www.iana.org/assignments/media-types/media-types.xhtml
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

