Correction d’erreurs, la clé d’une bonne transmission
Notre équipe effectue actuellement des recherches et développe des prototypes sur l’utilisation de la correction d’erreurs avant transmission (Forward Error Correction, FEC) pour les transmissions vidéo.
La FEC [1] est une technique bien connue pour contrôler les erreurs dans la transmission de données. Dans les réseaux IP, les erreurs se traduisent en réalité par la perte d’un datagramme UDP ou TCP complet, ce qui explique pourquoi la FEC est également appelée Forward Erasure Correction. L’objectif est alors de pouvoir recréer un paquet perdu à partir des autres paquets transmis et des informations redondantes incluses dans des paquets FEC spécifiques.
Pourquoi y a-t-il des pertes de paquets ?
Les pertes de paquets [2] sont fréquentes en télécommunications en raison de la nature des transmissions : par exemple, un réseau sans fil peut subir des interférences radio. D’autres causes de pertes de paquets sont les congestions temporaires survenant dans les routeurs.
Dans la réalité, il est courant et généralement acceptable d’observer un taux de perte d’environ 1 à 2 % pour de nombreux types de connexions Internet (xDSL, LTE, 5G, Wifi, etc.).
Pourquoi les pertes de paquets posent-elles problème ?
Dans la plupart des usages d’Internet, les pertes de paquets sont gérées par le protocole TCP : le récepteur accuse réception des paquets reçus et attend que l’émetteur retransmette les paquets perdus.
Cependant, cette technique n’est pas applicable pour les communications en temps réel, car il est inacceptable d’interrompre le flux jusqu’à ce que les paquets retransmis arrivent.
C’est pourquoi les flux audio et vidéo en temps réel sont préférentiellement transmis via le protocole UDP. Bien que des retransmissions au niveau applicatif puissent être mises en œuvre efficacement sur UDP, elles sont souvent inadaptées en raison des délais aller-retour entre l’émetteur et le récepteur.
Les pertes de paquets sont bien gérées pour les flux audio grâce au Packet Loss Concealment (PLC), ce qui les rend presque imperceptibles pour l’utilisateur final tant que le taux de perte reste inférieur à 5 %.
En revanche, elles sont beaucoup plus compliquées à gérer pour les données vidéo. En effet, la nature du codage vidéo fait qu’une seule perte dans une image vidéo rend l’image entière illisible, ainsi que les images suivantes, jusqu’à la réception d’une image spéciale appelée image clé (key-frame). Ceci est une conséquence du codage différentiel utilisé pour la compression vidéo.
Comment les pertes de paquets sont-elles gérées pour les vidéos en temps réel ?
Lorsqu’un récepteur vidéo détecte une perte de paquet, il peut notifier l’émetteur à distance grâce à des paquets RTCP spéciaux (PLI – packet loss indication [3]), afin que l’émetteur génère immédiatement une image clé et permette au récepteur de continuer le rendu de la séquence vidéo.
Cette technique, implémentée dans Linphone depuis plusieurs années, a toutefois l’inconvénient de geler l’affichage vidéo jusqu’à la réception de l’image clé.
Pour un flux vidéo de qualité moyenne et un taux de perte de 1 %, ces gels ne se produisent pas fréquemment.
En revanche, pour un flux vidéo de haute qualité (HD), la quantité de données étant beaucoup plus importante, même un taux de perte de 0,5 % entraîne des gels presque chaque seconde, provoquant un rendu saccadé pour l’utilisateur final.
Pourquoi la FEC peut-elle aider ?
La FEC offre une solution pour compenser les taux de perte typiques observés sur Internet. Grâce à un surcharge relativement faible et une latence minimale, les informations de redondance transmises par l’émetteur permettent au récepteur de recréer les paquets manquants, tant que le taux de perte reste compatible avec la quantité de redondance envoyée par l’encodeur.
Ainsi, la vidéo peut être lue de manière fluide, sans effet perceptible pour l’utilisateur final.
Comment cela sera-t-il géré dans Linphone ?
Il existe actuellement diverses techniques FEC standard documentées par l’IETF.
Notre équipe a choisi le schéma Flexible Forward Error Correction (flexfec) documenté dans le RFC8627 [4], car il combine un codage redondant à faible complexité (basé sur XOR) avec un haut niveau de flexibilité des paramètres FEC, ce qui est essentiel pour ajuster la surcharge de redondance selon le taux de perte observé et la bande passante du réseau.
Les résultats semblent très prometteurs !
Nous serons bientôt ravis d’annoncer une future version de Linphone et Linphone SDK, intégrant un algorithme FEC pour la transmission vidéo !
Annexes :
[1] https://en.wikipedia.org/wiki/Error_correction_code#Forward_error_correction
[2] https://en.wikipedia.org/wiki/Packet_loss
