Résumé

  • Publié en août 2026, le RFC 10034 normalise le transport RTP des données d’atlas V3C et ajoute à SDP un groupe V3C pour associer les lignes médias d’une même représentation. Cette relation décrit les pièces attendues ; elle n’atteste pas leur arrivée ni leur assemblage.
  • La preuve d’achèvement doit rapprocher offre, réponse, paramètres, sources autorisées, fragments, ordre de décodage, synchronisation, résultat du décodeur et test applicatif. Le marqueur d’un flux ou quatre cadenas valides ne suffisent pas.

Dans une régie, quatre colonnes portent le même identifiant de session. L’atlas reçoit ses paquets. L’occupation est à jour. Les attributs restent sous le seuil de perte. La géométrie affiche, elle aussi, un flux actif. Le dernier paquet de l’unité d’accès de l’atlas porte le bit marqueur. Le superviseur conclut : représentation complète.

Le casque montre un volume fendu.

Un NAL de géométrie avait été fragmenté. Le fragment central s’est perdu ; les fragments suivants ont continué à faire avancer les compteurs. Chaque voyant disait quelque chose de vrai sur son périmètre. Aucun ne prouvait que le récepteur possédait les octets nécessaires à la scène.

Le RFC 10034 donne précisément les moyens de ne pas confondre ces niveaux. Cette norme proposée de l’IETF définit un format de charge RTP pour les sous-flux d’atlas V3C. Elle renvoie les composantes vidéo à leurs propres formats RTP et décrit, dans SDP, comment réunir atlas, occupation, géométrie et attributs sous une même représentation logique.

La norme organise une chaîne de dépendances. Elle ne nomme pas un voyant souverain.

La 3D est d’abord distribuée entre plusieurs plans

V3C compresse une scène en projetant l’information volumétrique sur plusieurs représentations bidimensionnelles. L’occupation indique quels pixels contribuent au volume. La géométrie situe les points reconstruits. Les attributs peuvent décrire couleur, réflectance, normales ou matière. L’atlas relie des régions de ces images aux positions qu’elles reprennent dans l’espace.

La page publique d’ISO/IEC 23090-5:2026 identifie l’édition de la norme V3C et V-PCC citée par le RFC. Le texte public du RFC expose ensuite l’enjeu opérationnel : une image volumétrique n’est pas transportée comme un tout indivisible. Elle dépend d’un ensemble de sous-flux.

Cette décomposition reste visible dans SDP. L’atlas est annoncé comme application/v3c à 90 kHz. Les composantes vidéo emploient le type et les règles du codec retenu. Une offre peut donc mêler H.264, H.265 et H.266, tout en associant les lignes à un même atlas.

Le mot « actif » devient alors dangereux s’il ne porte pas de sujet. Un flux actif peut avoir perdu l’unité dont dépend le prochain cadre. Un attribut absent peut être tolérable pour une vue de secours et rédhibitoire pour une inspection de matériau. La disponibilité du transport et la disponibilité de la représentation sont deux mesures différentes.

a=group:V3C dessine le périmètre de rapprochement

Le nouveau groupe prend une forme simple :

a=group:V3C 1 2 3 4

Les nombres renvoient aux valeurs mid des lignes médias. Le RFC 5888 fournit le cadre général de regroupement. Le RFC 10034 ajoute la sémantique V3C : ces lignes appartiennent à une même représentation.

Appartenir n’est pas arriver. Le groupe ne transmet aucun paquet, n’authentifie aucune source et ne dit rien du résultat du décodeur. Il indique au récepteur quelles observations doivent être rapprochées.

Les mêmes lignes peuvent être regroupées par BUNDLE. BUNDLE autorise un transport partagé ; il ne dissout pas les rôles médias. Le récepteur doit toujours rattacher chaque paquet au bon mid, au bon type V3C, au bon identifiant d’atlas et au bon état de paramètres.

Le registre IANA pour application/v3c fixe un nom et rend sprop-v3c-parameter-set obligatoire. Le registre des paramètres SDP conserve les vocabulaires communs. Ces inscriptions prouvent qu’un langage a été réservé. Elles ne prouvent ni adoption, ni activation, ni interopérabilité d’un produit.

Les paramètres décrivent une dépendance, pas une capacité acquise

sprop-v3c-parameter-set transporte, en base64, les paramètres dont dépend la reconstruction. Le RFC recommande souvent de les transmettre hors bande : découvrir trop tard que le récepteur ne dispose pas des outils nécessaires peut conduire à un comportement indéfini.

Les paramètres facultatifs identifient le type de composante, l’ensemble actif, l’atlas, l’attribut, sa partition et la carte. Un en-tête compact de quatre octets peut remplacer cette liste. Les deux formes ne doivent pas coexister, précisément pour empêcher deux descriptions contradictoires.

Des NAL d’atlas, d’atlas commun ou de SEI transmis hors bande restent applicables pendant le flux jusqu’à ce qu’un NAL en bande du même type les remplace. Ce remplacement doit être traité comme un changement d’état. Faute de version de session, le récepteur peut conserver un atlas ancien et décoder des composantes nouvelles sans violation cryptographique apparente.

Le champ a=v3cfmtp peut exister au niveau de la session ou de la ligne média. En cas de conflit, le niveau session prévaut. La règle enlève une ambiguïté de priorité ; elle ne garantit pas que tous les caches de signalisation et tous les décodeurs ont adopté la même révision.

Accepter l’offre n’est pas promettre une scène entière

Dans le modèle offre-réponse du RFC 3264, l’émetteur propose des médias et le destinataire accepte des formats ou rejette une ligne en plaçant son port à zéro. Le RFC 10034 permet explicitement à un récepteur partiellement ignorant du codage V3C de sélectionner un sous-ensemble.

Cette faculté protège l’autonomie du récepteur. Elle oblige aussi le produit à définir ce qu’un sous-ensemble signifie. Une géométrie sans couleur peut constituer un mode dégradé utile. Une analyse de surface sans attribut de matière peut devenir trompeuse. Le protocole ne tranche pas cette politique.

En SDP déclaratif, les paramètres de profil et de niveau décrivent le flux, pas les capacités du destinataire. Celui qui ne les prend pas en charge doit rejeter ou ne pas participer. Une réponse positive atteste donc un choix déclaré à un instant donné. Elle ne garantit pas l’arrivée, l’ordre ou la reconstruction ultérieure.

Le bit marqueur ferme une unité locale

Le RTP du RFC 3550 fournit numéro de séquence, horodatage et identifiant de source. Dans le format V3C, le bit marqueur signale le dernier paquet de l’unité d’accès portée par le flux RTP courant. Il aide le tampon de lecture. Il ne ferme pas une transaction répartie entre tous les membres du groupe V3C.

L’atlas peut voyager dans un paquet NAL unique, dans un paquet d’agrégation ou dans une unité de fragmentation. L’agrégation réduit le coût des petits NAL mais doit rester sous le MTU local. La fragmentation permet de couper un NAL ; ses fragments se suivent sans entrelacement dans le flux et ne peuvent pas être imbriqués.

Si un fragment manque, le récepteur devrait jeter les fragments suivants du même NAL, sauf décodeur explicitement capable d’accepter l’incomplet. Le trafic postérieur ne répare donc pas automatiquement le trou. Il peut même entretenir une apparence de santé.

L’ordre de décodage a sa propre preuve. Lorsque sprop-max-don-diff vaut zéro ou est absent, ordre de transmission et ordre de décodage coïncident. Sinon, les numéros DON imposent un réordonnancement. La dépaquétisation doit aussi prendre en compte les flux dépendants et le délai volontaire nécessaire à leur synchronisation. Le RFC 7798 offre le précédent NAL dont ce mécanisme reprend la philosophie ; V3C y ajoute le problème d’un résultat composé.

Protéger chaque flux ne suffit que si l’ensemble est lié

Le RFC 10034 n’impose pas une sécurité unique. Le RFC 7202 explique pourquoi un format RTP ne peut choisir à la place de l’application sa topologie, sa gestion de clés et son modèle d’identité. Le RFC 7201 cartographie les options, tandis que SRTP fournit des mécanismes de confidentialité, d’authentification et de protection contre la répétition.

La contrainte V3C demeure : la source doit être authentifiée sur tous les sous-flux, et les flux RTP, SDP et RTCP doivent correspondre à l’intention de l’émetteur. Authentifier l’atlas mais accepter la géométrie d’un autre contexte crée un composite sans principal.

Même quatre validations cryptographiques ne prouvent pas la cohérence. Les flux peuvent être associés à deux versions de paramètres ou à des instants incompatibles. Une signature de transport répond à « ces octets ont-ils été protégés sous cette clé ? », non à « cette scène est-elle celle que l’application devait produire ? ».

La congestion modifie parfois le sens

Le RFC exige une surveillance des pertes en diffusion unicast. Émetteur et récepteur peuvent adapter le débit, quitter la session ou invoquer le coupe-circuit RTP. Certains sous-flux moins importants peuvent être réduits ou supprimés en tenant compte de la qualité globale.

Le réseau ignore lequel est « moins important ». Cette qualification relève du service. La suppression d’une couleur, d’une normale ou d’une carte auxiliaire peut être cosmétique, analytique ou sécuritaire selon l’usage. Une adaptation doit donc produire un nouvel état applicatif nommé, pas seulement un débit plus bas.

Le bon objet est un registre de complétude

Conserver uniquement les statistiques RTP laisse disparaître la causalité. Pour chaque révision de session, il faut archiver les empreintes de l’offre et de la réponse, les membres des groupes V3C et BUNDLE, le jeu de paramètres, les rôles, les codecs, les atlas, les sources autorisées et les contextes de sécurité.

À l’exécution, ajouter les couples de transport, SSRC, premières et dernières observations, pertes, gigue, profondeur de réordonnancement, fragments complets, limites d’unité et entrées du décodeur. Puis conserver l’identité du cadre reconstruit, l’erreur du décodeur, le test de rendu ou d’analyse, le mode dégradé et l’état terminal.

Cette chaîne applique la primauté du code exécuté défendue par Heng Lu : la preuve vient du chemin réel, pas du symbole. Son modèle de spécification minimale et de décision locale correspond à l’équilibre du RFC : grammaire commune, choix locaux. Enfin, la distinction entre contrôle formel et contrôle pratique des données rappelle que l’auteur de la session ne contrôle ni chaque copie en réseau, ni le tampon, ni le résultat final.

Le groupe V3C est donc précieux pour ce qu’il délimite : le périmètre des faits à réconcilier. Il devient dangereux seulement lorsqu’on le prend pour la réconciliation elle-même.