Кратко

  • RFC 10034 определяет RTP-нагрузку для атласа V3C и SDP-группу V3C, связывающую медиастроки атласа, занятости, геометрии и атрибутов. Группа описывает состав представления, но не подтверждает доставку и восстановление всех необходимых компонентов.
  • Решение о завершении должно сверять переговоры, версию параметров, разрешённый источник, потери, сборку фрагментов, порядок декодирования, синхронизацию потоков, результат декодера и прикладную контрольную проверку. Локальный marker bit такой власти не имеет.

Представим систему, в которой каждая команда честно выполнила свою норму. Поток атласа получает пакеты. У занятости допустимый уровень потерь. Атрибуты продолжают передавать цвет. Сеанс геометрии активен, а последний RTP-пакет несёт marker bit. Сводная панель выводит: V3C-представление готово.

Но у отображённого объекта отсутствует часть поверхности.

Одна геометрическая NAL-единица была разделена на три фрагмента, и средний не пришёл. Более поздние пакеты поддерживали поток в активном состоянии. Атлас совершенно корректно закрыл собственную access unit. Ни один локальный отчёт не был ложным — ложным оказался переход от четырёх локальных фактов к глобальному результату, которого никто не наблюдал.

RFC 10034, опубликованная в августе 2026 года на треке стандартов IETF, устанавливает более дисциплинированную границу. Она задаёт RTP-формат для подбитового потока атласа V3C, использует соответствующие форматы видеокодеков для видеокомпонентов и позволяет через SDP объявить, что несколько медиастрок образуют одно V3C-представление.

Стандарт координирует состав. Он не выдаёт сертификат результата.

До отправки сцена превращается в набор зависимостей

V3C проецирует трёхмерное содержимое на несколько двумерных представлений и добавляет сведения, необходимые для обратной проекции. Карта занятости указывает, какие пиксели значимы. Геометрия задаёт положение восстановленных точек. Атрибуты несут цвет, отражательную способность, нормали или иные свойства. Атлас описывает патчи и обратное отображение, возвращающее плоскостям пространственный смысл.

Публичная карточка ISO/IEC 23090-5:2026 указывает спецификацию V3C и V-PCC, на которую опирается RFC. Практическое следствие видно уже из краткого описания архитектуры: получатель ждёт не автономный видеокадр, а компоненты, ценность которых зависит от совпадения идентификаторов, версий и времени.

Разделение сохраняется в сети. Атлас использует application/v3c поверх RTP с частотой часов 90 кГц. Занятость, геометрия и атрибуты передаются форматами RTP выбранных видеокодеков. В одном offer разные компоненты могут применять H.264, H.265 и H.266, тогда как атлас остаётся строкой application media.

Поэтому отчёт «работают четыре потока» говорит об инвентаре, а не о пригодности. Потеря цвета может быть приемлема в грубом геометрическом режиме и критична в анализе материала. Без пригодной геометрии безупречно пакетированный атлас не создаёт сцены.

Группа указывает связь, а не факт исполнения

RFC 10034 вводит SDP-строку вида:

a=group:V3C 1 2 3 4

Токены ссылаются на значения mid медиастрок. Общую модель группировки определяет RFC 5888. Семантика V3C сообщает приложению, что описания принадлежат одному битовому потоку. Она не переносит медиа, не проверяет источник и не получает состояние декодера.

Те же медиастроки могут участвовать в переговорах BUNDLE. Общий транспорт сокращает число ресурсов, но не сливает идентичности компонентов. Пакет всё равно нужно связать с правильным медиаписанием, типом V3C-единицы, набором параметров, атласом и контекстом безопасности.

a=v3cfmtp допускается на уровне сеанса и медиа. При конфликте RFC 10034 отдаёт приоритет сеансовому значению. Это устраняет произвольный выбор реализации, но не доказывает, что закэшированный offer, внутрипоточное переопределение и байты на входе декодера относятся к одной ревизии.

Регистрация IANA для application/v3c требует sprop-v3c-parameter-set и ограничивает медиатип RTP-фреймингом. Реестры параметров SDP IANA предоставляют общие пространства имён. Регистрация делает метку совместимой. Она не доказывает, что отправитель её предложил, получатель реализовал или реальный сеанс восстановил содержимое.

Параметры описывают битовый поток, а не способность приёмника

Обязательный sprop-v3c-parameter-set переносит Base64-кодированные байты набора параметров. Они описывают профиль и ресурсы реконструкции. RFC 10034 отмечает пользу внеполосной передачи: если требования станут известны лишь после начала медиа, приёмнику может не хватить возможностей, а поведение окажется неопределённым.

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

Внеполосные NAL-единицы атласа, общего атласа и SEI могут действовать до тех пор, пока внутрипоточная единица того же типа их не заменит. Это переход версии. Приёмник, сохранивший старое состояние и принимающий новые медиа, способен аутентифицировать каждый пакет и всё же собрать неверное представление.

В offer/answer по RFC 3264 ответчик выбирает поддерживаемые форматы и может отклонить медиастроку, установив порт в ноль. RFC 10034 разрешает частично осведомлённому о V3C получателю выбрать подмножество. Следовательно, принятие answer не тождественно полной сцене. Продукт обязан определить полезные и недопустимые подмножества.

Marker bit завершает только локальную access unit

RTP предоставляет номера последовательности, timestamps, идентификаторы источника и marker bit, значение которого задаёт формат нагрузки. В RFC 10034 он стоит на последнем пакете access unit текущего RTP-потока. Это помогает буферу воспроизведения, но не является атомарным commit всей V3C-группы.

Атлас передаётся тремя способами. Single NAL Unit Packet несёт одну единицу. Aggregation Packet объединяет не менее двух малых единиц и должен укладываться в локальный MTU. Fragmentation Unit делит одну NAL-единицу между последовательными RTP-пакетами; вложенность и вставка иного пакета того же потока между началом и концом запрещены.

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

Порядок тоже является частью состояния. При отсутствующем или нулевом sprop-max-don-diff порядок передачи равен порядку декодирования. Положительное значение включает decoding order numbers и требует сортировки. Депакетизатор учитывает зависимые потоки и может ждать ради межпоточной синхронизации. RFC 7798 служит близким NAL-ориентированным прецедентом для HEVC, но знакомая пакетизация не отменяет многокомпонентную природу V3C.

Аутентифицировать надо состав, а проверять — ещё и смысл

RFC 10034 не выбирает единственный механизм безопасности. Причину объясняет RFC 7202: формат RTP не знает будущую схему ключей, идентичности, одноадресной или групповой доставки и доверия. RFC 7201 рассматривает варианты, а SRTP предоставляет конфиденциальность, аутентификацию и защиту от повтора для подходящих сеансов.

Специфическая обязанность V3C остаётся строгой. RFC рекомендует аутентифицировать источники всех составляющих подпотоков и согласовать подлинность RTP, SDP и RTCP с намерением отправителя. Защищённый атлас в сочетании с геометрией из непривязанного источника оставляет возможность композиционной атаки.

Даже четыре криптографически корректных потока не гарантируют результат. Они могут принадлежать разным ревизиям, защищённый атрибут — опоздать к текущему атласу, доверенный отправитель — ошибиться в atlas ID. Криптография доказывает свойства байтов под ключом. Согласованность и прикладная полезность требуют отдельных наблюдений.

Борьба с перегрузкой меняет смысл режима

RFC 10034 требует от одноадресных участников следить за потерями и применять RTP congestion control. Отправитель может снизить скорость, получатель — выйти, обе стороны — задействовать RTP circuit breaker. Разрешено снижать качество или удалять менее важные подпотоки с учётом общего восприятия.

Но «менее важный» — продуктовый, а не транспортный термин. Удаление цвета может сохранить геометрическую телеприсутствие и разрушить проверку материалов. Поэтому сетевая деградация должна явно открыть режим «только геометрия» или «анализ недоступен», а не сохранить прежний ярлык успеха.

Журнал завершения должен дойти до приложения

Для каждой ревизии стоит сохранять отпечатки offer и answer, наборы mid в группах V3C и BUNDLE, отпечатки параметров и заголовков, кодек, роль компонента, atlas ID, разрешённый источник, SSRC и транспорт. Для каждого потока нужны времена первого и последнего пакета, потери, jitter, глубина перестановки, закрытые фрагменты, порядок декодирования и граница access unit.

После RTP журнал включает NAL-единицы на входе декодера, ошибки, идентификатор восстановленного кадра, визуальный или аналитический canary, решение о деградации, circuit breaker и конечное состояние. «Согласовано», «принимается», «депакетизировано», «декодировано» и «пригодно» — разные утверждения.

Принцип Heng Lu о приоритете работающего кода размещает доказательство в исполненном пути, а не в названии стандарта. Его модель минимальной начальной спецификации и локальных решений сохраняет узкий общий синтаксис и оставляет выбор возможностей и внедрения участникам. Различие между формальным и практическим контролем данных показывает: создатель сеанса может назвать части, но не получает от этого контроля над сетевыми копиями, буферами и итоговым выводом.

RFC 10034 точно формулирует, что должно быть связано. Операторы должны столь же точно доказать, что получилось из этой связи.