Ces technologies sont également mises à profit pour faire évoluer les câblages dédiés (SDI ou HDMI) des studios et régies vers les infrastructures réseau qui innervent la totalité des entreprises.
Pour la réception de flux vidéo sur les terminaux domestiques, les éditeurs de logiciels et les équipes techniques des plates-formes de streaming ont redoublé d’efforts pour rendre l’accès aux contenus le plus facile possible, sous réserve de disposer d’un équipement récent et des versions d’OS et de navigateurs à jour. Du côté production, dès que l’on se penche sur les spécifications d’un matériel ou d’un logiciel d’encodage, l’utilisateur est confronté à une myriade de sigles, de protocoles et de fonctions qui risque de l’effrayer ou, au minimum, de le décourager.
Comme pour toutes les technologies numériques de communication, cette multiplication de paramètres et de codages évolue avec le temps en enrichissant de nouvelles fonctionnalités ou pour profiter des améliorations régulières des performances et des débits. Elle correspond également à une vaste diversité des usages et des fonctions. L’organisation des protocoles réseau en multiples couches superposées (selon le fameux modèle OSI) ne fait que rajouter une bonne dose de complexité pour l’utilisateur.
Comme dans beaucoup d’autres domaines technologiques, les protocoles et codages de streaming sont conçus pour correspondre à des situations fort diverses et aux étapes spécifiques de la chaîne de production et de diffusion.
Comme pour la TV traditionnelle, on distingue trois grandes étapes dans le cheminement des images et des sons depuis le lieu de captation jusqu’à l’écran du spectateur. D’abord les liaisons de contribution qui servent à transporter les signaux depuis le studio d’enregistrement ou le lieu de captation jusqu’à la régie finale de la chaîne ou du nœud de commutation qui assure la continuité du programme ou la sélection du contenu. Ensuite, l’étape de distribution vers les relais de desserte auprès des spectateurs (émetteurs de TV, serveurs CDN) et enfin la diffusion finale vers l’écran fixe ou mobile du spectateur, ce dernier segment étant souvent dénommé « the last mile ».
Le protocole IP inadapté à l’audiovisuel
Pour fonctionner correctement un service de streaming doit combiner plusieurs éléments. La première étape consiste à réduire le débit du flux numérique engendré par les signaux vidéo et audio grâce à un codec de compression. Leur évolution depuis les débuts du JPEG et du MPEG a fait l’objet de nombreux articles et autres conférences pour suivre leur évolution vers le H.264, puis le H.265 et tout dernièrement le VVC, sans oublier le JPEG2000 puis le JPEG XS et le VP9 et l’AV1 du côté des géants du streaming. Ces informations sont largement connues et répercutées par les constructeurs et les spécialistes car elles ont une influence directe sur la qualité des contenus et en parallèle le débit numérique et par conséquent la taille des fichiers.
Lorsque ce flux numérique vidéo et audio compressé emprunte les liaisons IP d’Internet, il est indispensable de leur associer un protocole de transport spécifique, destiné à respecter l’intégrité temporelle des signaux audiovisuels tous basés sur une référence horaire stricte (balayage vidéo, respect de la durée et du rythme des sons…). Or, l’organisation initiale d’Internet, conçue au départ pour transmettre des fichiers de données ou des messages textuels ne garantit aucun respect de la synchronisation.
Le réseau Internet comme de nombreux réseaux de télécommunications fonctionne selon le principe du « best effort », que l’on peut assimiler familièrement à « je fais de mon mieux ». Le service de streaming, et en particulier le protocole de transport entre la source et la destination, devra mettre en place des procédures permettant de garantir un flux stabilisé respectueux de la référence temporelle du signal audiovisuel malmené dans une liaison irrégulière et imprévisible. L’une des solutions consiste à mettre en place une mémoire tampon au niveau récepteur pour atténuer les à-coups de la transmission. D’où l’apparition d’une latence (ou retard) lors d’une transmission audiovisuelle basée sur Internet.
Distinguer TCP et UDP
Tous les protocoles de transport de contenus audiovisuels sur Internet s’appuient sur l’échange de paquets IP entre les équipements reliés par réseau. À ce niveau, deux protocoles d’échange coexistent, le TCP et l’UDP. Le plus connu est le TCP (Transmission Control Protocol) car il est souvent cité et apparaît à un moment ou un autre dans les panneaux de réglages de l’interface réseau d’un ordinateur. Il est également le plus utilisé.
Au-delà de l’établissement de la liaison entre la source et le destinataire, il est doté d’outils de contrôle du flux de données et surtout de mécanismes assurant leur robustesse et garantissant que les données reçues sont identiques à celles émises, élément impératif pour la transmission fiable de fichiers de données. En cas de réception de données corrompues, une commande est renvoyée à l’émetteur pour réexpédier le paquet concerné. Ces mécanismes peuvent ralentir le flux des données et créer des retards préjudiciables au flux continu des données audiovisuelles, à moins de prévoir des mémoires tampons (buffers) pour encaisser les à-coups mais qui augmentent en conséquence la latence globale de la liaison et du service.
Pour les transmissions de contenus audiovisuels, c’est un autre protocole de transport qui lui est préféré, l’UDP (User Datagram Protocol). Contrairement au TCP, aucune communication préalable n’est requise pour établir la connexion entre la source et la destination, et la vérification de l’intégrité des données se limite à une somme de contrôle sur l’en-tête sans renvoi des données altérées.
Pour donner une image simplifiée des différences entre les deux protocoles, le TCP peut être assimilé à une lettre recommandée avec AR, tandis que l’UDP correspond à un courrier normal distribué dans sa boîte aux lettres. Cette simplification des procédures rend l’UDP plus sensible aux aléas du réseau mais offre une transmission plus rapide et sans à-coups. Il est donc choisi dans une majorité des cas pour assurer des liaisons audiovisuelles en mode flux. Dans le cas de la transmission de fichiers, le TCP sera toujours privilégié.
Une première génération de protocoles
Les premiers services de streaming ont été créés dès la fin des années 90 avec parmi les plus connus, Real Player, puis quelques années plus tard Windows Media. Ces premiers services étaient basés sur des protocoles propriétaires. Les organismes au cœur de la normalisation d’Internet ont proposé toutes une série de codages et de protocoles standardisés pour faciliter l’interopérabilité des services. Chacun est affecté à une fonction ou un service, ce qui a conduit à une collection de sigles, souvent similaires, qui n’aide pas à la lecture des spécifications des matériels, des logiciels et des plates-formes.
À la base il y a le RTP (Real-Time Transport Protocol), un protocole de communication permettant le transport de données soumises à des contraintes de temps réel comme les flux audio et vidéo. Utilisant l’UDP, il fonctionne en mode unidirectionnel et doit être associé à un autre protocole pour établir la session, comme le SIP ou le H.323 pour les services de téléphonie sur IP ou de visioconférence. Pour des services de streaming, il est souvent associé au RTSP (Real Time Streaming Protocol) qui complète RTP avec des commandes de lecture du flux (stop, pause, lecture…) évitant ainsi de télécharger le contenu au préalable sous forme d’un fichier, contrainte impérative pour diffuser un contenu live.
Ces protocoles RTP et RTSP, largement délaissés par les services modernes de streaming, sont encore disponibles sur de nombreux équipements comme des encodeurs hardware ou les caméras pourvues d’une sortie réseau. Assez simples à mettre en œuvre, ils servent encore pour déployer des services à l’intérieur d’un réseau local pour de la vidéo surveillance, du monitoring ou la distribution de contenus en live au sein d’un organisme. Par contre, pour déployer des services sur des réseaux publics à longue distance, il sera nécessaire de configurer les routeurs et les pare-feu avec leurs ports spécifiques.
Le protocole RTCP ne transporte aucune information mais vient compléter le RTP pour fournir des informations statistiques sur le fonctionnement du réseau et la qualité de service. Ces informations peuvent être récupérées par un encodeur pour adapter ses paramètres en fonction des variations de débit et de la charge du réseau.
Le dernier protocole historique le plus connu est le RTMP (Real Time Messaging Protocol) lancé par Adobe à l’aube des années 2010. Il s’agit d’un protocole propriétaire fonctionnant dans une architecture client/serveur en conjonction avec le player Flash. Largement déployé sur de nombreux services et en particulier YouTube, il est disponible sur de très nombreux équipements et logiciels d’encodage.
Basé sur TCP, il offre un contrôle d’erreur mais au prix d’une latence de l’ordre de cinq secondes. Sans support direct d’HEVC, beaucoup considèrent que le RTMP a atteint son apogée et qu’il passe sur la phase descendante de sa longue et brillante carrière. Ce protocole est encore largement employé pour l’envoi des flux de streaming vers de nombreuses plates-formes de diffusion et il est donc encore largement exploité pour des liaisons de contribution.
Des protocoles adaptés à la diffusion vers le grand public
Pour la diffusion vers le grand public, les premiers services de streaming s’appuyaient sur des services propriétaires exigeant la mise en place de serveurs dédiés et l’installation d’applications ou d’extensions spécifiques. En outre leurs protocoles fonctionnaient avec des ports dédiés que les pare-feu devaient laisser passer. Dans le cadre des loisirs à la maison, cela ne présentait pas trop de complications mais en entreprise, l’accès à ces services était souvent bloqué.
L’arrivée de nouveaux services basés sur l’ABR (Adaptative Bit Rate) a fait émerger de nouveaux protocoles basés sur le Web et le HTTP. Ainsi, plus besoin de serveurs dédiés et le passage à travers les pare-feu est garanti dans toutes les situations, car sans l’ouverture des ports 80 et associés, plus de navigation sur le Web. Parmi les quatre technologies de streaming basées sur l’ABR, seules deux se sont réellement répandues, le HLS lancé par Apple et le MPEG-Dash proposé dans le cadre des travaux du MPEG.
Les désagréments de la latence
Toutes les technologies de streaming actuelles sont soumises à un décalage temporel, la latence, due aux divers traitements numériques tout au long de la chaîne de diffusion. Pour la lecture d’un programme proposé en VOD, le spectateur ne ressent aucun désagrément s’il découvre la clé d’une énigme policière avec un léger décalage. Pour les événements diffusés en direct, ce retard crée un agacement bien compréhensible chez le fan de sport qui suit la finale de la Coupe du Monde en streaming sur sa tablette ou son ordinateur. Il attend avec anxiété le tir d’un dernier penalty à la toute fin du match et il entend déjà la clameur de la victoire chez ses voisins installés devant téléviseur ou s’il voit la notification du résultat sur les réseaux sociaux.
Sur les services de streaming basés sur l’ABR, ce retard est de l’ordre de trente à quarante-cinq secondes selon les situations, les codecs et les services. Sur les outils utilisés pour les liaisons de contribution ou les duplex basés sur la visioconférence, ce retard plus limité, de l’ordre de trois à six secondes, rend tout dialogue haché et complique les échanges entre les invités de l’émission.
Tous les acteurs engagés dans la conception des outils et services de streaming se sont penchés sur ce problème de latence et proposent soit de nouveaux outils ou protocoles ou des versions améliorées. Pour la diffusion vers les multiples terminaux grand public, Apple propose le LL-HLS (Low Latency HTTP Live Streaming) tandis que le Low Latency CMAF for Dash a été mis au point dans le cadre du MPEG. Ces deux nouveaux protocoles ne sont pas encore totalement validés et restent très peu exploités pour l’instant car ils demandent des modifications ou des adaptations tout au long la chaîne de diffusion. Nous reviendrons sur leurs caractéristiques dans un prochain article.
Du côté des usages du streaming en contribution, deux nouveaux protocoles sont disponibles depuis un certain temps et leur usage tend à supplanter les protocoles traditionnels car outre une latence plus réduite ou maîtrisée, ils apportent plusieurs améliorations intéressantes selon leurs conditions d’exploitation.
Le SRT pour renforcer la sécurité et maîtriser la latence
En 2013, Haivision, un constructeur spécialisé dans les outils d’encodage et les systèmes de transmission vidéo aussi bien pour les marchés broadcast, l’enseignement, le corporate que le militaire, a mis au point un nouveau protocole de streaming dénommé SRT (Secure Reliable Transport). À ne pas confondre avec le format de fichier SRT destiné au sous-titrage des documents audiovisuels.
Dans un premier temps le constructeur l’a développé comme un outil propriétaire qu’il a intégré dans ses produits. En 2017, il a décidé d’en publier les spécifications et le code sur GitHub pour en ouvrir l’accès à d’autres constructeurs sous la forme d’une licence publique de type Mozilla. En 2017, l’Alliance SRT a été créée et a rassemblé dans un premier temps quarante membres, puis a accueilli des acteurs aussi divers que Microsoft, VLC, le FFMEG. En 2020, elle regroupe plus de quatre-cent-cinquante membres dont Avid, Grass Valley et récemment Sony.
Haivision a travaillé sur les principaux défauts des premiers protocoles de streaming en les améliorant sur plusieurs aspects, la fiabilité, la sécurité et la réduction de la latence. Une autre caractéristique importante du protocole SRT est d’être totalement agnostique par rapport au choix du codec de compression vidéo et audio. Il est avant tout destiné aux liaisons de contribution et ne concerne pas pour l’instant la diffusion vers le grand public. Son implantation et sa compatibilité en termes de lecture restent limitées à une gamme certes de plus en plus étendue mais restreinte d’équipements ou d’outils logiciels.
Le protocole SRT est dérivé de l’UDT (UDP Data Transfer Protocol) et a été conçu pour offrir un transport fiable de données au travers d’un réseau « imprévisible » comme l’est Internet. Il est capable de transmettre tout type de données mais s’avère particulièrement adapté aux données audiovisuelles. Lors de la transmission des contenus entre la source et la destination, grâce à des marqueurs temporels insérées dans le flux de données, il détecte le jitter (gigue) et les variations dues à la charge et aux perturbations le long du cheminement des données. Cela permet de réduire la taille du buffer au niveau du récepteur et ainsi limiter la latence.
En matière de correction d’erreur, le protocole SRT s’appuie sur l’ARQ (Automatic Repeat Request) qui demande à la source pendant un intervalle de temps limité choisi par l’utilisateur de renvoyer un paquet perdu ou corrompu. Cette durée est directement liée à la taille du buffer de réception et d’émission. Au-delà de cet intervalle fixé par l’utilisateur, le paquet est irrémédiablement perdu et se traduira par un défaut à l’image. Ce mécanisme lui offre le choix entre une latence réduite avec un risque de dégradation de la qualité ou au contraire de préserver la qualité mais au prix d’une latence plus élevée. Il peut ainsi effectuer un choix éclairé selon les performances de la liaison empruntée et le souhait de qualité du contenu selon les situations de production.
Cette procédure a été préférée à la méthode traditionnelle de correction d’erreur FEC, pour Forward Error Correction, (qui reste néanmoins disponible) car elle exige un traitement plus complexe (donc plus de puissance de calcul et en conséquence plus de latence) et conduit à une redondance de données et donc un débit plus élevé.
Une latence améliorée par rapport au RTMP
La latence constatée lors d’une transmission live en streaming est due à l’addition des temps de traitement dans les équipements eux-mêmes (compression, adaptation aux protocoles de transport…), à la durée de transmission sur le réseau (le passage à travers tous les nœuds de routage et la longueur des liens), au processus de traitement des erreurs, au chiffrage des données et enfin à la taille des mémoires tampons (buffer) pour compenser les erreurs temporelles de la transmission. Avec le protocole SRT et l’ARQ, cette latence est nettement réduite par rapport à celle constatée avec l’usage du RTMP, comme l’indique le tableau de tests réalisés par Haivision. Par rapport au RTMP, la latence totale de la liaison est divisée par deux ou trois en moyenne.
Dans les divers documents de présentation du SRT, il est recommandé de fixer la latence du buffer à une valeur comprise entre 2x et 4x la valeur du RTT (Round Trip Time) qui correspond au temps de réponse d’une requête envoyé depuis un poste client vers un serveur et son retour. La durée du RTT dépend fortement de la distance géographique entre la source et la destination mais aussi au nombre de routeurs et d’équipements traversés.
Dans une liaison de contribution, la protection contre les intrusions est un élément crucial de l’architecture technique pour éviter le vol des contenus ou des accès malveillants cherchant à s’immiscer pour diffuser des contenus alternatifs. Lors de l’établissement de la liaison, l’accès aux flux est protégé par un identifiant avec un mot de passe. D’autre part, si nécessaire, les contenus peuvent être chiffrés avec un protocole de type AES à 128 ou 256 bits, mais au prix d’une augmentation du flux.
Le protocole SRT disponible sur un nombre croissant d’outils
La technologie SRT est mise à disposition des développeurs de logiciels, des constructeurs d’équipements et de prestataires de streaming sous forme d’API et de code source distribués via la plate-forme Github en open source. Avec ce mode de distribution, les premiers à l’implanter sont évidemment des éditeurs de logiciels et les plates-formes déployées dans le cloud.
Les principaux logiciels d’encodage ou de mixage vidéo (OBS, vMix, Wirecast…) offrent depuis un moment l’accès à des flux SRT et proposent de les diffuser aussi dans ce format. De plus en plus de plates-formes de streaming acceptent ces signaux, mais plutôt dans le monde professionnel. Curieusement, les principales plates-formes publiques de streaming comme YouTube, Facebook, Twitch, etc. restent à l’écart et continue de privilégier le RTMP.
Au niveau des équipements, bien entendu Haivision a développé tout une série d’équipements dédiés au SRT sous la gamme Makito ainsi qu’une série de logiciels de conversion, de transcodeur ou encore de lecture. Matrox, Kiloview, Teradek (Cube 600 et 700) et Magewell proposent aussi de leur côté des encodeurs compatibles SRT.
Avid a annoncé un partenariat avec Haivision pour permettre à sa plate-forme Media Central de recevoir directement les flux de contribution transmis en SRT. Panasonic a conçu une caméra PTZ dotée d’une sortie réseau SRT, le modèle AW-UE100, tout comme Lumens avec la VC-A50P. L’éditeur de logiciel Softvelum a développé Larix Broadcaster, un outil de prise de vue pour smartphones iOS et Android qui transmet en live via 4G ou wi-fi les images filmées en direct. Il complète son produit par Nimble Streamer, un serveur SRT capable de convertir les flux reçus en NDI, LL-HLS ou en SDI.
Ce rapide panorama montre que le protocole SRT devient de plus en plus présent dans le monde de la production live et du streaming. Par rapport au RTMP encore largement exploité, il apporte des améliorations significatives. Le nombre de tutoriels ou de vidéos présentant des configurations innovantes montre qu’il suscite beaucoup d’intérêt au-delà de la sphère professionnelle.
Le WebRTC pour rendre les duplex plus fluides
Le second protocole qui tend à se généraliser n’est pas à proprement parler un protocole de streaming mais plutôt une interface de programmation et une API Javascript destinées à la communication en images et sons entre deux interlocuteurs à distance. Développé dans le cadre du W3C et de l’IETF, il se rapproche des outils de visioconférence mais comme les briques nécessaires à son fonctionnement sont intégrées dans les versions modernes des navigateurs, il est beaucoup plus simple à mettre en œuvre que les outils ou services de visioconférence qui exigent soit l’installation de logiciels et la connexion avec un compte d’utilisateur, soit la mise en place d’extensions dédiées.
Son usage a dépassé le cadre des outils de communication. Il est déployé dans de nombreux logiciels de mixage vidéo pour accueillir des invités à distance dans des duplex et devient, du coup, un peu un outil de streaming. D’autant que ses concepteurs ont réduit au maximum la latence dans les échanges pour préserver la spontanéité d’une conversation, au prix hélas d’une dégradation potentielle de la qualité des images. Mais cela n’est pas trop préjudiciable car il s’agit la plupart du temps de filmer un interlocuteur unique dans une position statique. La communication étant bidirectionnelle, il est facile de lui renvoyer l’image du programme final ou au moins l’audio pour établir une véritable conversation.
L’architecture technique du WebRTC est organisée sous forme d’un triangle avec une transmission directe bidirectionnelle des flux vidéo et audio entre les deux postes, en mode point à point (peer to peer) sans passer par un serveur central, d’où la rapidité des échanges, avec une latence inférieure à 500 ms. Le troisième sommet du triangle est occupé par un serveur d’applications, utilisé comme point de rendez-vous afin de coordonner les échanges entre navigateurs jusqu’à ce que la connexion directe entre eux soit établie.
Concrètement l’initiateur de la communication récupère un lien sur la page d’accueil du service, l’adresse par e-mail ou messagerie instantanée à son interlocuteur, qui à son tour va se connecter sur le service. Le serveur récupère les adresses IP de chacun et fournit les divers éléments de connexion à chaque navigateur. Une fois que les deux participants ont validé l’accès à leurs caméras et micros respectifs, la communication s’établit de manière directe entre les deux postes.
Ce processus est beaucoup plus simple et rapide que la création de comptes sur des services dédiés. D’autant que l’encodeur est directement intégré au navigateur. D’ailleurs, tous les fournisseurs de services de visioconférence ou de communication unifiée ont bien compris les avantages de cette simplification et offrent maintenant des services similaires de connexion directe via une page Web, soit en intégrant les technologies WebRTC dans leurs services (comme Google Hangouts ou Meet, Facebook Messenger, Discord ou Amazon Chime) ou en les calquant avec des outils plus propriétaires. Privilégiant la communication directe entre deux interlocuteurs, le WebRTC est peu adapté à la diffusion vers de larges audiences.
Au début du WebRTC, seuls quelques navigateurs étaient compatibles comme Google Chrome, Opera ou Mozilla Firefox. Mais depuis, Microsoft et Apple, qui étaient réticents au départ, ont incorporé le WebRTC dans Internet Explorer, Edge ou Safari. Tous les logiciels de mixage vidéo comme OBS, vMix ou Wirecast disposent d’une fonction de duplex avec des invités à distance (le nom varie selon le logiciel) basées sur le protocole WebRTC. Grâce à sa latence très réduite et sa facilité de mise en œuvre pour l’interlocuteur à distance, le WebRTC rencontre un succès grandissant et devrait permettre d’élargir les dispositifs de communication en facilitant la mise en place de plateaux sans compliquer le dispositif technique et avec un coût très réduit.
Article paru pour la première fois dans Mediakwest #42, p. 98-103. Abonnez-vous à Mediakwest (5 numéros/an + 1 Hors série « Guide du tournage) pour accéder, dès leur sortie, à nos articles dans leur intégralité.
