Résumé

  • La RFC 2448 proposait une fiabilité sélective : protéger plus sûrement les informations de haute priorité (HP) tout en laissant la vidéo de basse priorité (LP) suivre sa voie habituelle.
  • La réception des HP ne prouvait ni l’arrivée des LP, ni leur bon alignement, ni un décodage et un affichage à temps.

La compression répartit inégalement les conséquences d’une perte. Certains bits décrivent la structure d’une image ou les paramètres nécessaires au décodage ; d’autres portent une grande partie du contenu visuel. Le réseau, lui, voit des paquets. Sans priorité intégrée, il ne sait pas lequel fera défaut au codec.

La RFC 2448 déplaçait donc ce jugement vers l’encodeur ou l’application. L’émetteur séparait les segments HP, jugés vitaux, du reste du flux, désigné LP. Il pouvait livrer les HP de façon fiable avant l’envoi des LP, les transporter dans des paquets RTP distincts, les dupliquer en parallèle du flux original ou envoyer hors bande des informations réutilisables que le récepteur mettrait en cache. La priorité ne venait pas du réseau : elle résultait d’un chemin de fiabilité séparé.

Mais tout dépendait de la classification. Le texte précise qu’elle exige de connaître la syntaxe et la sémantique du codec et qu’il n’existe pas de méthode générale pour tous les bitstreams. Son exemple MPEG-2 rend le compromis concret : une partie HP limitée aux en-têtes représentait généralement moins de 2 % des données vidéo. En y ajoutant les coefficients DC, la part pouvait monter à environ 40 % et donner une vidéo quelque peu exploitable dans les seules HP ; il fallait alors fiabiliser beaucoup plus de données. Ce sont les chiffres de l’exemple de la RFC, pas une mesure universelle.

Envoyer les HP d’abord réduit leur exposition aux pertes, mais ajoute un délai de démarrage. Des paquets RTP HP distincts peuvent avoir un type de charge utile propre tout en partageant le format d’horodatage et l’espace SSRC du flux principal. Ces repères facilitent la coordination ; ils ne garantissent pas que les deux voies livrent leurs données. L’émetteur peut aussi conserver les HP dans le flux non partitionné et n’utiliser les copies séparées qu’en cas de perte. Pour les informations HP réutilisées hors bande, les horodatages peuvent ne rien signifier : une image clé, et parfois le bit marqueur, aident à les rattacher au flux LP.

Le récepteur doit donc vérifier davantage que l’achèvement d’un transfert fiable : les informations protégées correspondent-elles à la version du codec et au bon point du flux LP ? Les données LP nécessaires sont-elles arrivées ? Le décodeur a-t-il produit une sortie avant l’échéance ? L’affichage a-t-il effectivement eu lieu ? Une réception fiable des HP ne répond à aucune de ces questions à elle seule.

Publiée en novembre 1998, la RFC 2448 est un document informatif, pas une norme Internet. Elle mentionne des brevets AT&T/Lucent et précise que l’IETF et l’IESG ne se prononcent ni sur leur validité, ni sur leur portée, ni sur la disponibilité d’une licence. Le texte décrit une technique ; il ne démontre ni adoption, ni déploiement actuel, ni interopérabilité, ni bénéfice pour le public. Son apport historique est plus précis : la fiabilité sélective transforme un problème de transport en politique de codec, et chaque voie ajoutée crée une condition de raccordement qu’il faut observer.

Sources

RFC 2448 ; notice RFC 2448 ; fiche IETF Datatracker ; errata RFC 2448 ; RFC 2250, charge RTP MPEG ; RFC 3550, RTP ; RFC 2198, données audio redondantes ; RFC 2733, FEC pour RTP ; RFC 5109, FEC générique RTP ; RFC 4588, retransmission RTP ; RFC 1191, MTU de chemin ; RFC 1889, première spécification RTP ; Heng Lu, primauté du code exécuté ; Heng Lu, spécification et adoption volontaire.