Zusammenfassung

  • RFC 10034 spezifiziert die RTP-Nutzlast für V3C-Atlasdaten und eine SDP-Gruppe, die Atlas, Belegung, Geometrie und Attribute als Bestandteile einer Darstellung benennt. Die Gruppe ist eine Beziehung, keine Empfangs- oder Rekonstruktionsbestätigung.
  • Der Abschluss einer Darstellung braucht zusammenhängende Nachweise zu Aushandlung, Parameterstand, autorisierter Quelle, Verlust, Fragmenten, Dekodierreihenfolge, Zeitbezug, Decoderausgabe und Anwendungstest. Ein einzelner Marker oder vier aktive Sitzungen reichen nicht.

In einem Leitstand melden vier Kacheln Erfolg. Der Atlasstrom empfängt Daten. Die Belegung bleibt unter ihrem Verlustgrenzwert. Der Attributstrom liefert Farbe. Auch die Geometrie ist aktiv; ihr jüngstes RTP-Paket trägt sogar das Marker-Bit. Der zusammengesetzte Status springt auf „vollständig“.

Im gerenderten Bauteil fehlt eine Fläche.

Eine Geometrie-NAL-Einheit war auf drei Fragmentation Units verteilt. Das mittlere Fragment ging verloren. Spätere Pakete hielten die Sitzung am Leben, und der Atlas beendete korrekt seine eigene Access Unit. Kein lokaler Messwert war erfunden. Erfunden war nur der Schluss, dass vier grüne Übertragungszustände gemeinsam eine dreidimensionale Szene ergeben müssten.

Die im August 2026 auf dem IETF Standards Track veröffentlichte RFC 10034 liefert ein präzises Gegenmittel. Sie definiert das RTP-Nutzlastformat für den V3C-Atlas-Subbitstrom, verwendet für Videokomponenten die jeweiligen Codec-Nutzlastformate und führt eine SDP-Semantik ein, mit der mehrere Medienzeilen als eine V3C-Darstellung beschrieben werden.

Diese gemeinsame Sprache koordiniert Zuständigkeiten. Sie übernimmt sie nicht.

Vor der Übertragung wird aus der Szene ein Abhängigkeitsgraph

V3C bildet dreidimensionalen Inhalt auf mehrere zweidimensionale Repräsentationen ab. Belegung kann markieren, welche Pixel beitragen. Geometrie verortet rekonstruierte Punkte. Attribute transportieren Farbe, Reflexion, Normalen oder andere Eigenschaften. Der Atlas beschreibt Patches und die inverse Abbildung, durch die die Ebenen wieder räumliche Bedeutung erhalten.

Der öffentliche Eintrag zu ISO/IEC 23090-5:2026 bezeichnet die V3C- und V-PCC-Spezifikation, auf die RFC 10034 aufbaut. Für den Betrieb ist entscheidend: Ein Empfänger wartet nicht auf einen autarken Filmframe. Er verbindet Teile, deren Aussage von passenden Identitäten, Versionen und Zeitpunkten abhängt.

Die Trennung bleibt auf dem Netz bestehen. Der Atlas läuft als application/v3c über RTP mit 90-kHz-Takt. Belegungs-, Geometrie- und Attributkomponenten verwenden die Nutzlastformate ihrer Videocodecs. Eine einzige Offerte kann verschiedene Codecs für verschiedene Komponenten führen, während der Atlas eine application-Medienzeile bleibt.

Deshalb bezeichnet „vier Ströme verfügbar“ nur Bestand. Für eine einfache Visualisierung mag Farbe entbehrlich sein; bei Materialprüfung kann sie das entscheidende Signal tragen. Ein fehlerfreier Atlas ohne brauchbare Geometrie ist korrekt paketiert und dennoch nutzlos.

Die V3C-Gruppe ist eine Anweisung zum Abgleich

RFC 10034 ergänzt SDP um eine Zeile wie:

a=group:V3C 1 2 3 4

Die Kennungen verweisen auf die mid-Werte der Medienzeilen. Den allgemeinen Rahmen stellt RFC 5888. Die neue Semantik erklärt, dass diese Beschreibungen zu einem V3C-Bitstrom gehören. Sie überträgt keine Medien, authentisiert keine Quelle und sieht keinen Decoderzustand.

Dieselben Medienzeilen können Teil einer BUNDLE-Aushandlung sein. Gemeinsamer Transport spart Ressourcen, hebt aber Komponentenidentitäten nicht auf. Jedes Paket muss weiterhin zur richtigen Beschreibung, zum richtigen Einheitentyp, Parametersatz, Atlas und Sicherheitskontext gelangen.

a=v3cfmtp darf auf Sitzungs- und Medienebene vorkommen. Bei Widerspruch gilt laut RFC der Sitzungswert. Diese Vorrangregel verhindert beliebige Implementierungsentscheidungen. Sie beweist nicht, dass eine gespeicherte Offerte, ein In-Band-Override und die Bytes am Decoder denselben Revisionsstand haben.

Die IANA-Registrierung für application/v3c verlangt sprop-v3c-parameter-set und beschränkt den Medientyp auf RTP-Framing. Die IANA-SDP-Register stellen gemeinsame Namensräume bereit. Registrierung macht ein Etikett interoperabel. Sie sagt nicht, ob ein Sender es angeboten, ein Empfänger es implementiert oder eine reale Sitzung etwas rekonstruiert hat.

Ein Parametersatz beschreibt Anforderungen, nicht Fähigkeiten

Der vorgeschriebene sprop-v3c-parameter-set enthält Base64-codierte Parametersatz-Bytes. Sie beschreiben Profil- und Ressourcenanforderungen für die Rekonstruktion. RFC 10034 nennt die Out-of-Band-Bereitstellung grundsätzlich sinnvoll, weil ein Empfänger andernfalls erst nach Medienbeginn feststellen kann, dass ihm Fähigkeiten fehlen.

Weitere Felder kennzeichnen Komponententyp, aktiven Parametersatz, Atlas, Attributpartition, Map und die Rolle eines Hilfsvideos. Alternativ kann ein kombinierter Vier-Byte-Einheitenheader entsprechende Angaben tragen. Beide Varianten dürfen nicht zugleich vorkommen, damit keine konkurrierenden Wahrheiten entstehen.

Out-of-Band übermittelte Atlas-, Common-Atlas- und SEI-NAL-Einheiten können fortgelten, bis eine In-Band-Einheit desselben Typs sie überschreibt. Das ist ein Zustandswechsel. Wer alten Out-of-Band-Zustand mit neuer, vollständig authentisierter Mediennutzlast kombiniert, kann trotzdem die falsche Darstellung zusammensetzen.

Im Offer/Answer-Verfahren nach RFC 3264 kann ein Answerer unterstützte Formate annehmen und eine Medienzeile durch Port null ablehnen. RFC 10034 erlaubt einem nur teilweise V3C-kundigen Empfänger, eine Teilmenge auszuwählen. „Answer akzeptiert“ kann daher nie allgemein „Szene vollständig“ bedeuten. Die Anwendung muss zulässige Teilmengen bestimmen.

Ein Marker beendet genau eine lokale Access Unit

RTP liefert Sequenznummern, Zeitstempel, Quellenkennungen und ein Marker-Bit, dessen Bedeutung das Nutzlastformat festlegt. In RFC 10034 markiert es das letzte Paket der Access Unit im gegenwärtigen RTP-Strom. Es hilft dem Playout-Puffer, ist aber kein Commit über alle Mitglieder der V3C-Gruppe.

Für Atlasdaten gibt es Single-NAL-Pakete, Aggregation Packets mit mindestens zwei kleinen Einheiten und Fragmentation Units. Aggregation soll unter dem lokalen MTU bleiben. Fragmentierung verteilt eine NAL-Einheit auf aufeinanderfolgende RTP-Pakete; Verschachtelung und ein fremdes Paket desselben Stroms zwischen Anfang und Ende sind ausgeschlossen.

Fehlt ein Fragment, soll der Empfänger spätere Fragmente dieser NAL-Einheit verwerfen, sofern der Decoder nicht nachweislich mit unvollständigen Einheiten umgehen kann. Weiterlaufender Verkehr beweist also nur neue Bytes, nicht die Reparatur der beschädigten Einheit.

Auch die Reihenfolge hat Sitzungszustand. Fehlt sprop-max-don-diff oder ist es null, entspricht die Übertragungs- der Dekodierreihenfolge. Ein positiver Wert aktiviert Dekodierreihenfolgenummern und verlangt Sortierung. Die Depaketisierung muss Abhängigkeiten anderer Ströme berücksichtigen und darf für die Synchronisierung warten. RFC 7798 liefert einen verwandten NAL-basierten Präzedenzfall für HEVC; die bekannte Paketlogik beseitigt jedoch nicht die V3C-Abhängigkeiten.

Integrität ist auf die Zusammensetzung auszudehnen

RFC 10034 schreibt nicht für jede Anwendung dasselbe Sicherheitsverfahren vor. Die Architektur dahinter erläutert RFC 7202: Ein RTP-Nutzlastformat kann Schlüsselung, Identität, Unicast, Gruppen und Vertrauensmodell der späteren Bereitstellung nicht wählen. RFC 7201 ordnet die Optionen ein; SRTP bietet für geeignete Sitzungen Vertraulichkeit, Authentisierung und Replay-Schutz.

Die V3C-spezifische Pflicht bleibt deutlich. Alle konstituierenden Subströme sollen quellenauthentisiert werden; RTP, SDP und RTCP müssen der Absicht des Senders entsprechen. Nur den Atlas zu schützen und Geometrie aus ungebundener Quelle anzunehmen, lässt eine Kompositionsattacke zu.

Doch auch vier kryptografisch gültige Ströme können verschiedenen Revisionen entstammen. Ein geschütztes Attribut kann zu spät eintreffen, ein vertrauenswürdiger Sender die Atlas-ID falsch setzen. Integrität belegt geschützte Bytes unter einem Schlüssel. Semantische Konsistenz und Nutzbarkeit bleiben eigenständige Aussagen.

Netzdegradation ändert den Dienstmodus

RFC 10034 verlangt von Unicast-Nutzern Verlustüberwachung und RTP-Staukontrolle. Der Sender kann die Rate anpassen, der Empfänger die Sitzung verlassen, beide können den RTP Circuit Breaker nutzen. Weniger wichtige Subströme dürfen reduziert oder entfernt werden, wenn die Gesamterfahrung berücksichtigt wird.

„Weniger wichtig“ steht in keinem Paket. Farbverlust kann bei geometrischer Telepräsenz vertretbar und in der Werkstoffanalyse fatal sein. Deshalb muss eine Stauentscheidung einen sichtbaren semantischen Zustand auslösen: etwa „nur Geometrie“, nicht „vollständig bei niedrigerer Bitrate“.

Ein Abschlussregister statt aggregierter Ampeln

Für jede Sitzungsrevision gehören Fingerabdrücke von Offer und Answer, mid-Mitglieder der V3C- und BUNDLE-Gruppen, Parameter- und Headerstände, Codec, Komponentenrolle, Atlas-ID, autorisierte Quelle, SSRC und Transportbezug in ein Register. Pro Strom folgen erste und letzte Paketzeit, Verlust, Jitter, Sortiertiefe, geschlossene Fragmente, Dekodierreihenfolge und Access-Unit-Grenze.

Hinter RTP setzt sich die Kette fort: an den Decoder gelieferte NALs, Fehler, Identität des rekonstruierten Frames, Render- oder Analyse-Canary, Degradationsentscheidung, Circuit-Breaker-Ereignis und Endzustand. „Ausgehandelt“, „empfangen“, „depaketisiert“, „dekodiert“ und „brauchbar“ müssen getrennte Werte bleiben.

Heng Lus Konzept der Primärstellung laufenden Codes verortet Nachweise im ausgeführten Pfad statt im Namen des Standards. Sein Ansatz einer minimalen Ausgangsspezifikation mit lokalen Entscheidungen bewahrt eine schmale gemeinsame Syntax und lässt Fähigkeits- und Adoptionsentscheidungen bei den Teilnehmern. Die Unterscheidung von formaler und praktischer Datenkontrolle erklärt, warum der Sitzungsurheber Teile benennen, aber Netzwerkrepliken, Empfängerpuffer und Endausgabe nicht dadurch kontrollieren kann.

RFC 10034 liefert eine gemeinsame Karte. Ob das Ziel erreicht wurde, bleibt eine beobachtbare Betriebsfrage.