Résumé

  • RFC 3497 ajoutait seize bits au numéro de séquence RTP : à 1,485 Gbit/s, les seize bits ordinaires bouclaient en 336 millisecondes, contre environ six heures pour 32 bits.
  • Ce compteur rendait la perte observable sans rendre le débit adaptable. Sur un service au mieux, le récepteur devait partir lorsque le flux n'était plus compatible avec le débit qu'aurait obtenu TCP.

Le moment décisif n'était pas celui où l'image se brouillait. C'était celui où un récepteur, encore capable de numéroter correctement le flot, devait cesser de le recevoir pour protéger le réseau. RFC 3497 ne confondait pas un diagnostic précis avec une boucle de commande.

SMPTE 292M décrivait une interface série pour la télévision haute définition non compressée. Dans un studio, une caméra, un magnétoscope et un encodeur pouvaient échanger des mots de dix bits sur une liaison dédiée. Le débit était de 1,485 Gbit/s, ou de 1,485/1,001 Gbit/s. Transporter cette matière à distance sur IP exigeait de conserver la grammaire de l'image, sans prétendre que n'importe quel chemin Internet possédait la même capacité qu'un câble de studio.

RFC 3497 découpait chaque ligne SMPTE en un ou plusieurs paquets RTP. Les signaux SAV et EAV+LN+CRC, utilisés par le décodeur pour reconnaître les limites de ligne, ne pouvaient pas être fragmentés. Un en-tête de charge utile de quatre octets suivait l'en-tête RTP. Le bit marqueur repérait la fin d'une trame et un numéro de ligne sur onze bits maintenait un indice lorsque le paquet contenant EAV était perdu.

Le pgroup protégeait la cohérence des groupes de pixels. Le sous-échantillonnage 4:2:2 employait couramment cinq octets; 4:2:0 et 4:4:4 en employaient quinze. Une valeur d'un autorisait une coupure sur chaque octet lorsque la représentation source était inconnue, mais jamais au milieu des structures temporelles indispensables. Le type video/SMPTE292M, la fréquence et le paramètre facultatif pgroup permettaient à SDP de décrire cette convention.

Le compteur court posait alors un problème proportionnel au débit. Avec des paquets d'au moins mille octets, seize bits revenaient à leur point de départ en 336 millisecondes. Un paquet retardé risquait d'être confondu avec un nouveau paquet portant le même nombre. Les seize bits supplémentaires portaient l'espace à 32 bits et le cycle à environ six heures. La mesure devenait exploitable.

Mais le flux abritait plusieurs horloges qui ne racontaient pas la même histoire. L'horodatage RTP fonctionnait à 148,5 MHz et bouclait en 21 secondes. Le compteur d'octets de l'émetteur dans RTCP bouclait en 23 secondes; le total cumulé de paquets perdus, en 93 secondes. Une application voulant un total depuis le début devait comptabiliser elle-même les tours. Un champ borné attestait un intervalle; il n'était pas un grand livre perpétuel.

Cette instrumentation ne produisait aucune bande passante. RFC 3497 qualifiait le flux de constant, élevé et dépourvu de contrôle de congestion. Ses 1,485 Gbit/s avant même la surcharge RTP pouvaient constituer un déni de service sur la plupart des chemins Internet disponibles en 2003. L'usage devait donc rester limité à des extrémités convenablement raccordées ou à un réseau doté de garanties de ressources et de qualité de service.

Même une QoS annoncée restait une hypothèse à vérifier. Le récepteur devait surveiller les pertes pour confirmer que le service demandé était effectivement livré. Si les mesures le démentaient, il devait considérer qu'il recevait un service au mieux. Le nom de la classe appartenait au plan symbolique; la perte mesurée décrivait l'exécution.

Sur un chemin au mieux, l'obligation devenait plus ferme. Le récepteur devait suivre le taux de perte et quitter la session s'il était trop élevé. Le critère comparait le flot HDTV à un flot TCP placé sur le même chemin et dans les mêmes conditions : TCP devait pouvoir obtenir un débit moyen au moins égal. Or SMPTE 292M ne pouvait pas réduire progressivement son débit. Quand l'équité n'était plus plausible, le départ du récepteur était le seul coupe-circuit.

RTP, RTCP, SDP et le registre IANA distribuaient donc des responsabilités différentes. L'un transportait et numérotait, l'autre observait, le troisième décrivait, le quatrième coordonnait les noms. Aucun n'élargissait un lien. Les travaux ultérieurs — RFC 3550 pour RTP, RFC 4175 pour la vidéo non compressée, RFC 8083 pour les coupe-circuits et RFC 8888 pour un retour de congestion plus riche — ont précisé les outils, sans transformer rétrospectivement le débit fixe de RFC 3497 en source élastique.

La chaîne de preuve va de la description de session à la conformité des paquets, puis aux limites de ligne, à la continuité des séquences, à la reconstruction temporelle, aux compteurs RTCP corrigés des bouclages, à la QoS réellement mesurée, à la coexistence avec TCP et enfin à une image utile et durable. Une capture peut valider les premiers maillons tandis que le chemin échoue aux derniers.

L'apport historique de RFC 3497 tient à cette modestie. Le standard définissait un minimum d'interopérabilité pour transporter une réalité physique exigeante. Il n'accordait aucun droit sur la capacité d'autrui. Lorsque l'étiquette et la réalité divergeaient, il demandait au récepteur de croire la réalité.

Sources