Кратко

  • RFC 10034, написанная Lauri Ilola и Lukasz Kondrad, задаёт RTP-перенос NAL-единиц атласа V3C и семантику SDP V3C, связывающую строки атласа и видео одной репрезентации.
  • Получатель может отклонить отдельные строки и выбрать лишь часть. Потерянный фрагмент, порядок декодирования, несовместимый набор параметров или рассинхронизация потоков способны остановить реконструкцию.
  • Формат не предписывает единую защиту. Происхождение, целостность и конфиденциальность нужно подтвердить для каждого потока, SDP и RTCP; членство в группе не переносит доверие.

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

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

Атлас и видеокомпоненты не заменяют друг друга

Атлас сообщает, как интерпретировать двумерные области. Без соответствующих потоков занятости, геометрии и атрибутов он не содержит готовой сцены. Потоки без атласа и подходящего набора параметров могут не дать декодеру пути обратно в 3D.

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

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

Маленькая потеря может уничтожить целую NAL

NAL атласа передаётся одиночным пакетом, пакетом агрегации или блоками фрагментации. AP объединяет минимум две небольшие единицы, FU делит большую NAL на несколько RTP-пакетов.

AP должен помещаться в один IP-пакет и не должен сам фрагментироваться. FU не вкладываются друг в друга. Фрагменты одной NAL идут подряд с растущими RTP-номерами. Если один утрачен, получателю следует отбросить последующие фрагменты той же единицы.

Низкий общий процент потерь может означать отсутствие критической NAL. Сумма байтов не показывает, сошлись ли начало и конец FU и был ли AP разобран. Нужны границы, пробелы, решение об отбрасывании, результат сборки и передача декодеру.

Порядок декодирования — отдельная ось. При sprop-max-don-diff равном нулю он совпадает с порядком передачи. При большем значении DON/DONL позволяют перестановку перед декодированием. RTP sequence number описывает сеть; DON — логику медиаданных.

Атлас использует RTP-частоту 90 кГц, а RTP timestamp должен управлять показом. Это не доказывает, что занятость, геометрия, атрибуты и атлас вошли в одно допустимое временное окно. Межпотоковую синхронизацию измеряют в точке сборки.

Группа выражает замысел отправителя

RFC 5888 задаёт общий механизм группировки SDP, а RFC 10034 добавляет V3C. Токены ссылаются на mid: атлас использует m=application и v3c, видеокомпоненты — m=video и RTP-формат своего кодека.

В unicast offer/answer отправитель перечисляет компоненты и рекомендует совместное потребление. Получатель может принять их либо обнулить порт нежелательной строки. Разрешена и часть набора, если получатель полностью или частично не знает схемы V3C.

Следовательно, корректный ответ может сознательно быть неполным. Для одного приложения геометрия без цвета полезна, для другого отсутствие атласа делает вывод невозможным. Продолжение сессии не содержит этой продуктовой оценки.

В декларативном SDP получатель должен поддерживать значения или не участвовать. Участие подтверждает принятие описания, но не качество восстановленной сцены.

Доверие должно охватывать весь граф

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

Аутентифицированная геометрия не делает надёжным атлас от неожиданного источника. Защищённая нагрузка не спасает при изменяемой группе или параметрах. В multicast набор параметров должен оставаться связанным с исходным отправителем и использоваться только для его bitstream.

RFC 7201 описывает варианты, RFC 7202 — причину отсутствия единственного решения. Эксплуатационный отчёт обязан назвать механизм, охваченные компоненты, ключи или якоря доверия и результат проверки. «RTP получен» не является вердиктом о безопасности.

Вклад Kondrad полезен именно своей границей

Официальный профиль Nokia называет Kondrad Principal Standardization Specialist в стандартах иммерсивных медиа ISO/IEC и IETF. RFC 10034 соединяет эти системы: ISO/IEC 23090-5 определяет V3C, а RTP, SDP и группировка дают ему транспорт.

Работа коллективна. Ilola — соавтор, предыдущие RFC дают основу, IANA регистрирует application/v3c, v3cfmtp и V3C. Реестр доказывает общий идентификатор, не внедрение. Должность Kondrad не доказывает конфигурацию продукта Nokia.

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

Принцип Running-Code Primacy Heng Lu требует сохранить точные offer и answer, каждый mid, принятые и отклонённые строки, хэш параметров, карту компонентов, SSRC, защиту, потери, DON/DONL, AP/FU, синхронизацию, версию и ошибки декодера, число восстановленных кадров и проверку сцены.

Объявленная группа — первая квитанция. Доставка, происхождение, полнота, порядок, синхронизация и декодирование — следующие. Восстановленная сцена — последняя. RFC 10034 связывает цепочку, но не позволяет пропустить звенья.

Источники