Zusammenfassung

  • RFC 10034 von Lauri Ilola und Lukasz Kondrad definiert RTP für V3C-Atlas-NALs sowie die SDP-Semantik V3C, mit der zusammengehörige Atlas- und Video-Medienzeilen benannt werden.
  • Der Empfänger darf einzelne Zeilen ablehnen und nur eine Teilmenge annehmen. Fragmentverlust, Dekodierreihenfolge, Parametersatz-Fähigkeit und Zeitabgleich bleiben eigenständige Bedingungen der Rekonstruktion.
  • Das Payload-Format schreibt keinen einheitlichen Schutz vor. Herkunft, Integrität und Vertraulichkeit müssen jeden Teilstrom sowie SDP und RTCP umfassen; Gruppenzugehörigkeit erzeugt kein Vertrauen.

Volumetrisches Video wird für den Transport zerlegt. Aus einer dreidimensionalen Aufnahme entstehen mehrere zweidimensionale Darstellungen. Belegungsdaten markieren relevante Pixel, Geometrie ordnet rekonstruierte Punkte im Raum an, Attribute liefern Farbe oder Material. Atlas-Patches beschreiben den Weg zurück in die dritte Dimension.

RFC 10034 gibt dieser Aufteilung ein RTP- und SDP-Vokabular. Das im August 2026 auf dem IETF Standards Track veröffentlichte Dokument legt fest, wie Atlas-NALs paketiert, V3C-Parameter signalisiert und Medienzeilen gruppiert werden. Es macht die Teile gemeinsam transportierbar, ohne aus dem Transport ein Ergebnis zu erfinden.

Ein Atlas ist eine Abhängigkeit, keine fertige Szene

Atlas und Videokomponenten beantworten verschiedene Fragen. Der Atlas enthält die Zuordnung; die Videos liefern Belegung, Geometrie und Eigenschaften. Fehlt die passende Seite, können empfangene Bytes nutzlos bleiben.

Der V3C-Parametersatz beschreibt Ressourcen, die für Dekodierung und Rekonstruktion benötigt werden. Er wird sinnvollerweise außerband signalisiert. Trifft er dynamisch ein und fehlen dem Empfänger notwendige Fähigkeiten, warnt die RFC vor undefiniertem Verhalten. Der Hash des Parametersatzes belegt eine Konfiguration; erst der Fähigkeitsentscheid belegt, ob sie verwendbar war.

Deshalb müssen vier Zustände auseinandergehalten werden: in SDP benannt, im Angebot angenommen, als RTP empfangen und vom Decoder verarbeitet. Eine Monitoranzeige, die sie alle als „Stream vorhanden“ zusammenfasst, verliert die Fehlerursache.

Verlust wirkt auf NAL-Ebene

Für Atlas-NALs gibt es Einzelpakete, Aggregation Packets und Fragmentation Units. Ein AP bündelt mindestens zwei kleine Einheiten. Eine FU teilt eine große Einheit auf mehrere RTP-Pakete.

Ein AP muss in ein IP-Paket passen und sollte IP-Fragmentierung vermeiden; er darf selbst nicht fragmentiert werden. FUs dürfen nicht verschachtelt sein. Die Fragmente einer NAL müssen aufeinanderfolgend und mit steigenden RTP-Sequenznummern gesendet werden. Geht eines verloren, soll der Empfänger die folgenden Fragmente derselben Einheit verwerfen.

Damit kann eine sehr kleine Paketverlustrate eine ganze Atlas-NAL beseitigen. Gesamtbytes und letzte Sequenznummer beweisen weder vollständige FU-Grenzen noch einen parsebaren AP. Für den Nachweis braucht es Start/Ende, Lücken, Verwerfungsentscheidung, Wiederzusammenbau und Decoderübergabe.

Die Dekodierreihenfolge besitzt eine weitere Achse. Bei sprop-max-don-diff gleich null muss sie der Übertragungsreihenfolge entsprechen. Bei einem größeren Wert ermöglichen DON und DONL eine andere Übertragung, solange der Empfänger vor dem Dekodieren sortiert. RTP-Sequenz und Medienreihenfolge sind dann bewusst verschiedene Belege.

Der Atlas nutzt eine 90-kHz-RTP-Uhr; der RTP-Zeitstempel steuert die Darstellung. Das synchronisiert aber nicht automatisch Atlas, Belegung, Geometrie und Attribute über getrennte Ströme. Der gemeinsame Konsument muss die Abweichung messen.

Der Gruppenname beschreibt Absicht

RFC 5888 liefert das allgemeine SDP-Gruppierungsmodell. RFC 10034 ergänzt V3C. Die Token der Gruppenzeile verweisen auf mid-Werte: m=application mit v3c für den Atlas, m=video mit dem jeweiligen Codec für die Videokomponenten.

Die Beziehung ist präzise und deklarativ. Im Unicast-Angebot listet der Sender die Komponenten und empfiehlt, sie gemeinsam zu konsumieren. Der Antwortende kann einzelne Medienzeilen mit Port null ablehnen. Auch eine Teilmenge bei vollständiger oder teilweiser Unkenntnis des V3C-Schemas ist vorgesehen.

Eine gültige Antwort kann folglich absichtlich unvollständig sein. Geometrie ohne Farbe mag für eine Anwendung genügen; ein fehlender Atlas kann jede Rekonstruktion verhindern. Die laufende Sitzung entscheidet nicht, ob die Teilmenge geschäftlich akzeptabel ist.

Bei deklarativem SDP muss ein Empfänger die angegebenen Werte unterstützen oder die Teilnahme ablehnen. Teilnahme beweist Annahme, nicht eine richtige Szene.

Schutz muss alle Kanten des Graphen umfassen

RFC 10034 bestimmt keinen universellen Sicherheitsmechanismus. Die Anwendung bleibt für Vertraulichkeit, Integrität und Quellenauthentisierung verantwortlich. Das gilt für alle RTP-Teilströme und die Signalisierung, die sie verbindet.

Eine authentisierte Geometrie macht einen Atlas unbekannter Herkunft nicht vertrauenswürdig. Geschützte Payloads helfen nicht, wenn Gruppierung oder Parameter manipulierbar bleiben. Für Multicast müssen Parametersätze an ihre ursprüngliche Quelle gebunden und nur für deren Bitstream verwendet werden.

RFC 7201 beschreibt Optionen, RFC 7202 den Grund für die anwendungsseitige Wahl. Der Betriebsnachweis muss daher den tatsächlichen Schutz, die abgedeckten Komponenten, Vertrauensanker und Prüfergebnisse nennen. „RTP empfangen“ ist kein Sicherheitsurteil.

Ein Standard gewinnt durch seine Begrenzung

Nokias öffentliches Profil bezeichnet Kondrad als Principal Standardization Specialist für immersive Medien in ISO/IEC und IETF. RFC 10034 verbindet beide Welten: ISO/IEC 23090-5 definiert V3C, die IETF-Werkzeuge transportieren und beschreiben es.

Die Leistung ist kollektiv. Ilola ist Mitautor, frühere RFCs stellen das Fundament, IANA registriert application/v3c, v3cfmtp und V3C. Registrierungen belegen gemeinsame Koordinaten, keine Einführung. Kondrads Rolle belegt keine Nokia-Produktkonfiguration.

Der eng gefasste Standard schafft prüfbare Grenzen für Paketierung, Reihenfolge, Zeit, Parameter, Gruppierung, Aushandlung, Staukontrolle und Sicherheit. Fehler können dadurch dem tatsächlichen Kontrollinhaber zugeordnet werden.

Heng Lus Running-Code Primacy verlangt die Beobachtung: exaktes Angebot und Antwort, alle mid, angenommene und abgelehnte Zeilen, Parametersatz-Hash, Komponentenabbildung, SSRC, Schutz, Lücken, DON/DONL, AP/FU, Synchronität, Decoderversion, Fehler und Szenenprüfung. Erst die Wiederholung macht daraus belastbare Evidenz.

Die deklarierte Gruppe ist der erste Beleg. Transport, Authentizität, Vollständigkeit, Ordnung, Synchronisierung und Dekodierung folgen. Die rekonstruierte Szene besitzt den letzten. RFC 10034 verbindet sie, ersetzt sie aber nicht gegenseitig.

Quellen