L’image et le son partageaient le paquet, pas la preuve de lecture : RFC 2343

Résumé

• La RFC 2343 définissait un paquet BMPEG avec tranches vidéo entières, trames audio entières, horloge d’image à 90 kHz, longueur audio et décalage temporel signé.
• Ce vocabulaire décrivait la proposition du paquetiseur ; l’arrivée, l’état du décodeur, la synchro labiale, la sortie du terminal et la présence du public exigeaient d’autres observations.

Une coordination très visible

Le format BMPEG plaçait côte à côte ce que les utilisateurs attendaient ensemble. Le début du paquet contenait la vidéo ; des trames audio complètes suivaient afin de couvrir la durée du segment d’image. L’en-tête RTP indiquait l’ordre de transport, l’instant de l’image et sa fin. L’en-tête propre à BMPEG précisait le type I, P ou B, un changement éventuel des en-têtes MPEG, le nombre d’octets audio et le décalage du début audio par rapport à l’horodatage du paquet.

Cette architecture répondait à un problème concret de vidéo à la demande. Un programme pouvait employer un seul port. Un serveur conservait plus naturellement l’entrelacement déjà présent dans ses fichiers. La charge commune réduisait légèrement les en-têtes et pouvait faciliter la gestion du débit total. La RFC estimait environ 1 % d’économie dans son exemple à 4 Mbit/s.

Elle avançait aussi une « synchronisation implicite ». Il fallait lire cette expression avec précision : le paquet rendait la relation calculable. Il ne mesurait pas la présentation finale.

L’efficacité renonçait à une partie de la modularité

La RFC 2343 était expérimentale et déclarait ne définir aucune norme Internet. Elle présentait le groupement comme un choix acceptable lorsque ses avantages justifiaient l’abandon de deux flux audio et vidéo indépendants.

Un seul port supprimait des opérations, mais créait un destin commun. La perte d’un paquet pouvait enlever à la fois des pixels et du son. Un client ne pouvait plus sélectionner un média avec la même indépendance. La taille du paquet, le MTU du chemin, la profondeur des tampons et la capacité du décodeur devenaient des propriétés liées.

Le format supprimait en outre des informations de la couche système MPEG jugées redondantes avec RTP. Cette économie ne supprimait pas leurs fonctions : elle les redistribuait. Un émetteur et un récepteur pouvaient tous deux respecter la syntaxe tout en divergeant sur la façon de conserver l’état, d’ordonner les images ou de masquer une perte.

Les frontières applicatives structuraient la reprise

Lorsqu’un Video_Sequence_Header était présent, il commençait la charge RTP. Un GOP_header commençait la charge ou suivait ce premier en-tête. Un Picture_Header commençait la charge ou suivait le GOP. Chaque paquet devait contenir un nombre entier de slices vidéo.

Ces contraintes plaçaient des points de reprise reconnaissables. Elles ne garantissaient pas qu’un paquet resterait intact plus bas dans la pile. Le paquetiseur devait adapter les slices et leur nombre au MTU. Au-delà du MTU du chemin, la fragmentation revenait aux couches inférieures et pouvait aussi compliquer la classification RSVP.

L’audio obéissait à une couverture temporelle, pas à une règle d’une trame par paquet. Une trame audio pouvait dépasser la durée vidéo présente ; plusieurs paquets suivants pouvaient donc ne porter aucun audio. L’émetteur pouvait répéter la dernière trame pour mieux résister aux pertes.

Un analyseur pouvait valider cette construction sans savoir si un fragment IP manquerait, si la répétition deviendrait audible ou si le tampon se viderait avant la prochaine unité utile.

Trois ordres coexistaient

Le numéro de séquence donnait l’ordre RTP. L’horodatage de 32 bits à 90 kHz donnait l’instant d’échantillonnage de l’image. L’ordre de présentation MPEG ajoutait une troisième chronologie.

Avec des images B, l’horodatage pouvait reculer légitimement car l’ordre de transmission n’était pas l’ordre d’affichage. Tous les paquets d’une image partageaient cependant le même horodatage, et le bit Marker signalait celui qui contenait la fin de l’image. Un paquet ne transportant que des en-têtes de séquence, d’extension ou de GOP prenait le temps de l’image suivante.

Le champ Audio Offset exprimait en échantillons signés la distance entre le début d’une trame audio et le temps de l’image du paquet. Sa portée était d’environ plus ou moins 750 ms à 44,1 kHz. À une image par seconde, la RFC reconnaissait que le format pouvait ne plus convenir.

L’audio restait dans l’ordre de transmission même lorsque les images B étaient réordonnées. Le décalage permettait de retrouver la relation souhaitée. C’était une instruction de placement, non la preuve qu’un pilote audio, une horloge vidéo et un rendu matériel l’avaient exécutée.

Détecter une perte ne reconstituait pas le contenu

Les numéros de séquence et les horodatages rendaient des trous visibles. Le numéro de slice et la position du premier macrobloc aidaient à en estimer l’étendue. Pour une perte limitée à une image, un décodeur pouvait poursuivre et reprendre des pixels d’une image précédente. Il pouvait aussi injecter un substitut audio, tel qu’un bruit de fond, afin de masquer le manque et de protéger la synchro labiale.

Ce procédé était un aveu utile : le système pouvait produire une sortie sans posséder le contenu d’origine. Le camouflage réduisait parfois l’impact perceptible, mais n’annulait pas la perte.

Le bit N avertissait qu’une partie des en-têtes vidéo avait changé. Après une perte, si cet état manquait, supprimer les données jusqu’à un nouveau début d’image pouvait être prudent. Des pertes plus lourdes pouvaient imposer d’attendre un nouvel en-tête de séquence.

Le format n’incluait pas un compteur d’image spécialisé comme la référence temporelle évoquée dans la RFC 2250. La perte d’un GOP_header pouvait passer inaperçue et conduire à un décodage erroné d’images B. Un paquet encore lisible n’impliquait donc pas un contexte encore vrai.

La chaîne réclamait des reçus distincts

Il fallait observer l’arrivée avant l’échéance, la complétude des fragments, la reconstruction de l’image, l’état MPEG, le décodage, l’alignement réel des sorties audio et vidéo, puis le rendu sur l’appareil. Il fallait ensuite vérifier que l’écran n’était pas caché, que le son n’était pas coupé et qu’un spectateur était effectivement présent.

RTP ne réservait pas de ressources et ne garantissait pas la qualité de service. Un paquet valide pouvait arriver trop tard. Une image décodée pouvait être abandonnée par le rendu. Deux sorties correctement planifiées pouvaient dériver. Une application pouvait afficher « lecture » en arrière-plan. Le dernier écran pouvait rester devant un fauteuil vide.

La RFC 2343 est historiquement intéressante parce qu’elle rendait une promesse locale très nette. Elle normalisait la manière d’annoncer une relation audio-vidéo groupée. Elle ne donnait pas au paquet l’autorité de parler pour le monde situé après sa réception.