Résumé

  • RFC 3016 ne se bornait pas à transporter MPEG-4 dans RTP : il faisait du découpage une décision sur l’étendue de la panne, entre économie d’en-têtes et récupération indépendante.
  • Numéro de séquence, horodatage et bit marqueur décrivaient la forme du transport ; ils ne prouvaient ni la présence de la configuration, ni le décodage, ni la présentation au public.

Le raisonnement comptable était séduisant. Sur une liaison à faible débit, trois petits paquets vidéo coûtaient trois fois les en-têtes RTP, UDP et IP. En les réunissant, l’émetteur économisait des octets sans changer le codec, l’image ou le profil annoncé.

Puis un datagramme disparaissait. L’économie s’inversait : une seule perte réseau supprimait trois unités vidéo qui auraient pu être récupérées ou décodées séparément.

C’est dans ce choix discret que RFC 3016, publié en novembre 2000, raconte une histoire importante d’Internet. Le texte définissait le transport direct des flux MPEG-4 Audio et Visual dans RTP, sans les fonctions de synchronisation et de gestion de flux de MPEG-4 Systems. H.323 pouvait s’appuyer sur H.245 ; SIP et RTSP sur MIME et SDP. La pile devenait plus simple et les codecs MPEG-4 pouvaient être traités comme d’autres formats RTP.

Mais une couche retirée ne faisait pas disparaître ses responsabilités. Il fallait toujours placer la configuration, respecter la syntaxe, choisir une taille compatible avec le chemin et donner au récepteur assez d’indices pour reprendre après une perte. Le paquetiseur devenait le comptable du risque.

L’économie d’en-têtes créait un lot de perte

MPEG-4 Visual possédait déjà des mécanismes de résistance aux erreurs. RFC 3016 choisit donc de ne pas ajouter d’en-tête RTP propre au média. Le flux visuel était copié directement, aligné sur l’octet, sans supprimer ses éléments syntaxiques.

Cette simplicité restait encadrée. Les informations de configuration et les champs Group_of_VideoObjectPlane devaient commencer la charge RTP, ou venir immédiatement après l’en-tête de niveau syntaxique supérieur. Dès qu’une charge contenait des en-têtes, elle devait débuter par le plus élevé. Un en-tête ne pouvait jamais être coupé entre plusieurs paquets RTP.

Le motif n’était pas cosmétique. Un en-tête bien placé donnait au récepteur un point d’entrée identifiable. Coupé en deux, il rendait chaque moitié dépendante de l’autre. Le réseau pouvait livrer presque tous les octets tout en supprimant ceux qui donnaient leur sens aux suivants.

Le document recommandait de mettre un paquet vidéo dans un paquet RTP, puis d’ajuster sa taille pour rester sous la MTU du chemin. Sur un réseau sujet aux pertes, ce choix isolait mieux les dégâts. Même si le paquet contenant l’en-tête du VOP disparaissait, d’autres paquets pouvaient rester décodables grâce au Header Extension Code du flux MPEG-4.

La recommandation laissait pourtant une marge. Des unités minuscules rendaient les en-têtes proportionnellement lourds. Plusieurs paquets vidéo pouvaient être concaténés. RFC 3016 exposait sans détour le prix de cette densité : la perte d’un paquet RTP supprimait toutes les unités qu’il contenait.

L’« efficacité » avait donc deux dénominateurs. Mesurée en octets d’en-tête par seconde, la concaténation gagnait. Mesurée en contenu indépendant perdu par datagramme, elle pouvait perdre.

Le même nombre de paquets ne donnait pas la même récupération

Un exemple interdit du RFC rend le phénomène presque matériel. Deux paquets vidéo logiques pouvaient être répartis sur deux paquets RTP. Dans une disposition, la perte du second RTP n’effaçait que la seconde unité vidéo. Dans une autre, la première unité traversait la frontière et l’en-tête de la seconde arrivait derrière son reste : perdre le deuxième RTP rendait alors les deux inutilisables.

Deux paquets sur le fil, mais deux rayons d’explosion différents.

Un tableau de bord qui compte seulement les datagrammes ne voit pas cette différence. Le numéro de séquence constate le trou, mais ne dit pas quelle hiérarchie syntaxique s’y trouvait. Le taux de perte peut être identique tandis que la durée du gel, le nombre de régions d’image atteintes ou la capacité de reprise divergent.

Le découpage arbitraire d’un VOP illustrait la même autorité. Lorsque le codeur désactivait les paquets vidéo, RFC 3016 permettait de couper à n’importe quelle position d’octet. Sur un réseau supposé sans erreur, des fragments réguliers pouvaient convenir. Dans un environnement bruité, le RFC jugeait cette pratique peu résistante. La conformité du flux ne validait pas l’hypothèse sur le réseau.

Le marqueur fermait une unité, pas une preuve

Pour la vidéo, le bit marqueur RTP valait un sur le dernier — ou l’unique — paquet d’un VOP. Si plusieurs VOP partageaient une charge, il était également posé. L’horodatage indiquait alors le premier instant ; les en-têtes internes donnaient les temps suivants.

Ce mécanisme aidait le dépaquetiseur. Il ne témoignait pas devant le lecteur final. Le paquet marqué pouvait être perdu. Il pouvait arriver alors qu’un fragment antérieur manquait. L’unité pouvait être complète au niveau RTP et rejetée par le décodeur. Elle pouvait être décodée mais jamais affichée.

RTP lui-même limite la portée de ses champs. La séquence aide à détecter une perte et à remettre les paquets en ordre. L’horodatage représente un instant d’échantillonnage et sert à la synchronisation ; la présentation réelle vient plus tard. Le bit marqueur reçoit son sens du format de charge. Aucun de ces champs ne signifie « le spectateur a vu l’image ».

L’audio pouvait perdre la carte avant le son

Pour MPEG-4 Audio, RFC 3016 employait LATM. Un audioMuxElement complet ou partiel était placé directement dans la charge RTP, son premier octet au premier emplacement. Le document recommandait un élément par paquet et permettait la fragmentation lorsqu’il risquait de dépasser la MTU.

La dépendance la plus révélatrice concernait StreamMuxConfig. En mode de configuration intégrée, useSameStreamMux pouvait demander de reprendre la configuration de la trame précédente. Le gain était évident : ne pas répéter la carte à chaque fois. Mais si la trame précédente avait disparu, la trame actuelle, pourtant reçue intacte, pouvait devenir indécodable.

Le RFC recommandait donc de répéter StreamMuxConfig en fonction de l’état du réseau. La fréquence de répétition dessinait une fenêtre de fragilité. Plus elle était longue, plus une perte de configuration pouvait contaminer des paquets survivants. En mode externe, SDP pouvait transporter config, mais la garde changeait simplement de canal : encore fallait-il prouver que le récepteur détenait la bonne valeur.

Ainsi, tous les paquets perdus n’avaient pas la même fonction. L’un emportait du média. Un autre emportait la clé d’interprétation du média suivant.

Capacité et configuration n’étaient pas synonymes

Les types video/MP4V-ES et audio/MP4A-LATM reliaient MIME à SDP. Côté vidéo, profile-level-id pouvait décrire les outils qu’un codec savait prendre en charge. config décrivait la configuration du flux correspondant et ne devait pas servir de déclaration de capacité.

Cette distinction empêchait un raccourci fréquent. Deux équipements pouvaient annoncer le même Profile@Level sans partager la configuration active. Une description SDP bien formée pouvait être ancienne, adressée au mauvais flux ou contredite par les octets reçus. L’accord de vocabulaire ne constituait ni un test d’interopérabilité ni une observation de décodage.

La correction venait après la taille du lot

RFC 3016 permettait d’appliquer la correction d’erreurs générique de RFC 2733 ou la redondance audio de RFC 2198. Ces mécanismes commencent toutefois après le choix du contenu de chaque paquet source. Une équation FEC protège le lot que le paquetiseur lui présente ; elle ne redessine pas sa frontière logique.

C’est ce qui sépare cette histoire de celle de RFC 2733. La parité répond à la question « peut-on reconstruire un paquet manquant ? ». RFC 3016 pose d’abord la question « qu’avions-nous décidé de faire disparaître ensemble si ce paquet manquait ? ».

RFC 2429 offrait un autre contraste : le format H.263+ ajoutait un en-tête de charge et pouvait recopier des informations d’image afin de décoder malgré la perte de l’en-tête original. RFC 3016 s’appuyait sur les outils internes de MPEG-4 Visual. Le même RTP pouvait ainsi porter des contrats de reprise très différents.

Le numéro du RFC cachait lui aussi une frontière binaire

RFC 6416 a rendu RFC 3016 obsolète en 2011. La révision corrigeait notamment un décalage entre la définition LATM du texte de 2000 et le service 3GPP PSS. La nouvelle version LATM n’était pas compatible au niveau binaire avec celle référencée auparavant. Elle clarifiait aussi StreamMuxConfig, SBR, la stéréo paramétrique, la fréquence, les canaux et les dépendances entre couches.

Certains produits décrits comme « RFC 3016 » utilisaient déjà une version LATM plus récente. Ils pouvaient ressembler au futur RFC 6416 tout en n’étant pas strictement conformes au texte qu’ils citaient. Une étiquette de protocole ne remplaçait pas l’empreinte binaire de l’implémentation.

La révision a conservé le cœur visuel du compromis : isoler une unité améliorait la résistance aux pertes ; regrouper réduisait le coût mais agrandissait le dommage potentiel.

Chiffrer le lot ne réduisait pas sa taille

Le RFC rappelait que la confidentialité du média exigeait du chiffrement et que celui-ci pouvait intervenir après la compression. Le format limité à l’audio et à la vidéo n’emportait pas les applets MPEG-J ou les scripts possibles dans le système MPEG-4 complet.

L’intégrité et l’authenticité protègent la provenance et les octets. Elles ne changent pas la MTU, ne recréent pas une configuration perdue et ne séparent pas trois unités groupées. Un paquet authentique peut rester un lot trop vaste.

La leçon historique n’est donc pas que le paquetiseur aurait dû toujours choisir petit. RFC 3016 refusait justement une règle universelle : débit, perte, MTU et outils du codec variaient. Il exigeait plutôt que les limites syntaxiques restent compréhensibles et que le compromis soit assumé.

Le codec pouvait être intact, le profil correct et RTP conforme. Le risque se trouvait dans le lot constitué entre eux. Celui qui économisait l’en-tête choisissait aussi l’étendue de la perte.

Sources