Résumé

  • La RFC 10034, signée par Lauri Ilola et Lukasz Kondrad, définit le transport RTP des unités NAL de l’atlas V3C et le groupe SDP V3C qui associe les lignes média d’une même représentation.
  • L’offre peut être complète tandis que la réponse refuse certains composants. Une perte de fragment, un ordre de décodage mal rétabli, un jeu de paramètres incompatible ou un décalage entre flux suffit à empêcher la reconstruction.
  • Le format de charge utile n’impose pas une sécurité unique. Chaque flux et la signalisation qui les relie doivent disposer de leurs propres preuves d’origine, d’intégrité et, si nécessaire, de confidentialité.

Une représentation volumétrique arrive rarement sous la forme rassurante d’un seul flux. La scène a d’abord été dépliée : des images 2D portent l’occupation, la géométrie ou des attributs comme la couleur ; un atlas explique comment des régions de ces images se projettent dans l’espace. Au récepteur, ces éléments doivent se retrouver, être remis dans l’ordre et converger dans le même instant.

La RFC 10034 donne à cette séparation une forme transportable. Publiée sur la voie des normes de l’IETF en août 2026, elle décrit la charge utile RTP de l’atlas, les paramètres V3C placés dans SDP et le mécanisme qui groupe les différentes lignes média. Son mérite n’est pas de rendre les dépendances invisibles, mais de permettre de les nommer.

Le groupe a=group:V3C est le point de départ. Les identifiants qui le suivent renvoient aux mid de l’atlas, de l’occupation, de la géométrie et des attributs. L’atlas emploie une ligne m=application avec l’encodage v3c. Les composantes vidéo restent sur des lignes m=video et utilisent le format RTP du codec choisi. Toutes appartiennent à la même représentation sans devenir un seul paquet ni un seul domaine de panne.

L’atlas n’est pas une miniature de la scène

Dans V3C, l’atlas contient les indications qui permettent d’interpréter les représentations 2D. Ses patches associent des boîtes rectangulaires à des régions du volume. L’occupation indique quels pixels participent ; la géométrie situe les points reconstruits ; les attributs leur donnent couleur, matière ou autres propriétés.

Recevoir seulement l’atlas ne livre donc pas la scène. Recevoir seulement les vidéos ne donne pas nécessairement la transformation qui permet de les replacer dans l’espace. Même la présence de tous les noms dans SDP ne dit pas si les octets ont atteint le décodeur.

Le jeu de paramètres V3C ajoute une dépendance décisive. Il décrit les ressources nécessaires au décodage et à la reconstruction. La RFC conseille généralement de le signaler hors bande. S’il arrive dynamiquement alors que le récepteur ne dispose pas des capacités requises, le comportement peut devenir indéfini. Une trace doit ainsi distinguer le paramètre annoncé, son identité exacte et la décision réelle de capacité.

Un paquet reçu peut cacher une unité perdue

Le transport de l’atlas dispose de trois structures. Le paquet simple porte une unité NAL. Le paquet d’agrégation réunit au moins deux petites unités afin de réduire le surcoût. L’unité de fragmentation répartit une grosse NAL sur plusieurs paquets RTP.

Chaque structure a ses contraintes. Une agrégation doit rester dans un paquet IP et devrait éviter la fragmentation IP. Elle ne peut pas être fragmentée à son tour. Les fragments d’une même NAL doivent se suivre avec des numéros RTP croissants ; ils ne peuvent pas contenir une autre fragmentation. Si un fragment disparaît, le récepteur devrait jeter ceux qui suivent pour cette même unité.

Un compteur global peut alors rester presque parfait tout en ayant perdu l’élément qui rend un atlas décodable. La preuve utile est plus fine : limites AP et FU, bits de début et de fin, fragment manquant, politique de rejet et résultat de la NAL reconstituée.

L’ordre demande un reçu supplémentaire. Si sprop-max-don-diff vaut zéro, l’ordre de transmission doit être l’ordre de décodage. Sinon, DON et DONL permettent de transmettre autrement, à condition que le récepteur remette les NAL dans l’ordre avant le décodeur. La séquence RTP observe le trajet ; le numéro d’ordre de décodage observe la logique du média. Les confondre produit un diagnostic vert pour un résultat inutilisable.

Le temps reste lui aussi distribué. L’atlas utilise une horloge RTP de 90 kHz et l’horodatage RTP gouverne l’affichage. Cette règle ne prouve pas que les autres composantes ont rejoint le même instant avec une dérive acceptable. La synchronisation inter-flux doit être mesurée au point où la reconstruction les consomme.

L’offre décrit une intention, la réponse une sélection

La RFC 5888 fournit le cadre général de groupement SDP ; la RFC 10034 y ajoute la sémantique V3C. Cette inscription est précise mais déclarative. Elle affirme : « ces lignes vont ensemble ».

En unicast, l’offreur présente les composantes disponibles et propose qu’elles soient consommées ensemble. Le répondeur peut accepter cet ensemble ou mettre à zéro le port de lignes indésirables. Le texte autorise cette sélection lorsque le répondeur connaît imparfaitement, voire pas du tout, le schéma de codage V3C.

Une réponse valide peut donc constituer un choix partiel délibéré. Ce n’est pas forcément une erreur. Une application peut se satisfaire d’une géométrie sans attribut de couleur ou refuser un profil trop coûteux. Mais l’observabilité doit nommer la dégradation au lieu de compter l’existence du groupe comme une reconstruction complète.

Avec un SDP déclaratif, le récepteur doit prendre en charge les valeurs ou ne pas participer. Là encore, participer atteste une décision d’acceptation, pas la fidélité d’une scène rendue.

La confiance ne se propage pas par appartenance au groupe

La RFC 10034 ne choisit aucun mécanisme universel de sécurité. À l’application de protéger confidentialité, intégrité et authenticité de la source selon son environnement. Cette responsabilité concerne tous les sous-flux, ainsi que SDP et RTCP.

Une géométrie authentifiée ne rend pas fiable un atlas reçu d’une source imprévue. Des paquets RTP protégés ne suffisent pas si la signalisation de groupement a été altérée. En multidiffusion, la RFC exige d’associer les jeux de paramètres à leur source d’origine et de ne les employer que pour le flux de cette source. La coïncidence d’un identifiant ne justifie pas un mélange.

Les RFC 7201 et 7202 expliquent pourquoi RTP laisse ce choix aux applications et quelles familles de mécanismes peuvent être envisagées. Le rapport d’exploitation doit donc préciser le mécanisme effectivement actif, les flux couverts, l’identité vérifiée, l’état des clés et le résultat. « RTP fonctionne » n’est ni une preuve d’origine ni une autorisation.

Une contribution collective à la bonne taille

Le profil public de Nokia présente Kondrad comme Principal Standardization Specialist, engagé dans les normes de médias immersifs de l’ISO/IEC et de l’IETF. La RFC 10034 matérialise ce pont : ISO/IEC 23090-5 définit le modèle V3C ; l’IETF fournit RTP, SDP, le groupement et les conventions de sécurité.

Cette histoire reste collective. Ilola est coauteur. D’autres RFC fournissent les fondations. L’IANA enregistre le type application/v3c, l’attribut v3cfmtp et la sémantique de groupe. Un registre prouve une coordonnée commune, pas l’installation d’un produit. La fonction professionnelle de Kondrad ne prouve pas davantage la configuration d’un service Nokia.

Le principe de primauté du code en fonctionnement de Heng Lu indique le bon niveau de preuve : conserver l’offre et la réponse exactes, les mid acceptés et refusés, le hachage du jeu de paramètres, la carte des composantes, les SSRC, la protection de chaque flux, les pertes, DON/DONL, les frontières AP/FU, la synchronisation, la version du décodeur, les erreurs et le contrôle de la scène reconstruite.

Le premier reçu est l’appartenance déclarée. Puis viennent le transport, la protection, l’assemblage, le décodage et le rendu. La RFC 10034 relie ces étapes ; elle n’autorise pas à encaisser le premier reçu comme s’il était le dernier.

Sources