Les sports en direct sont passionnants à regarder. Surtout pendant les moments cruciaux, comme quand un tir sort de nulle part pour gagner le match. Ces moments peuvent également être passionnants pour l’équipe technique chargée de fournir des actions fluides et en temps réel. Les diffusions sportives en direct doivent équilibrer plusieurs considérations techniques et compromis, avec une moyenne d’environ 30 secondes de retard par rapport au match en direct sur le terrain. Pourquoi le retard ?
Bien que les réseaux de diffusion de contenu soient essentiels, ils ne peuvent pas réduire la latence causée par d’autres parties du workflow vidéo. Par exemple, la latence est ajoutée à partir du moment de l’ingestion lorsqu’une image est convertie en signal. Le signal brut doit ensuite être converti en un format compressé et transmis au centre de traitement vidéo, généralement hors site et souvent dans le cloud, ce qui peut être affecté par la bande passante et l’infrastructure disponibles. Vient ensuite le transcodage et le conditionnement du contenu pour divers appareils et bandes passantes. Enfin, lorsque le flux est en cours de lecture, la publicité peut être insérée dynamiquement dans le flux juste avant qu’il ne parcourt le dernier kilomètre d’Internet jusqu’à l’appareil du spectateur. Ici, le lecteur met en mémoire tampon le décodage, la décompression et le rendu du segment vidéo final. C’est beaucoup d’étapes entre l’objectif de victoire de l’équipe et le réseau de diffusion de contenu. Et ils peuvent s’additionner, surtout quand cela doit arriver pour des millions de téléspectateurs tout à la fois. La latence dans les flux en direct du Super Bowl, par exemple, est en moyenne de 28 à 47 secondes.
La réduction de la latence est devenue une priorité pour les fournisseurs de services de streaming. Pour les sports liés à des Paris de jeu d’une fraction de seconde, comme les courses de chevaux, les diffusions mettent les participants distants dans une position désavantageuse par rapport à ceux qui se trouvent sur le site. Les tweets en direct des téléspectateurs et des journalistes sur le site peuvent gâcher des moments passionnants pour les fans qui le regardent à la télévision et en streaming en direct. Et avec de plus en plus de téléspectateurs utilisant un deuxième écran tout en regardant des sports en direct, il n’est pas étonnant que réduire le temps derrière le live devienne une exigence importante pour rester compétitif et offrir une expérience visuelle exceptionnelle.
La réduction de la latence est une priorité pour nous chez Edgecast, maintenant Edgio. Cet effort implique la recherche et la mise en œuvre d’améliorations incrémentielles à chaque étape de traitement et les autres facteurs impliqués dans la diffusion de flux en direct. Dans cet article, nous examinons ce qui est impliqué dans un aspect spécifique de la réduction de la latence – comment notre réseau de diffusion de contenu gère l’augmentation du volume de requêtes résultant d’une stratégie de faible latence de plus en plus populaire – celle de la réduction de la taille des segments.
Dans le but de réduire le temps passé par rapport au live, les fournisseurs de services de streaming commencent à adopter l’utilisation de segments HLS ou DASH plus courts. Cela peut réduire considérablement la latence, mais il y a des compromis tels que la surcharge supplémentaire et le risque accru de remise en mémoire tampon. La pertinence de ces compromis dépend entièrement de la priorité accordée à la latence par rapport aux autres considérations de qualité de l’expérience. Dans certaines situations, comme indiqué ci-dessus, une faible latence est une priorité absolue, tandis que dans d’autres, les niveaux de latence actuels peuvent être acceptables pour diffuser des publicités personnalisées, des émissions 4K ou pour permettre l’édition de contenu en direct.
Rôle de la taille du segment dans la latence
L’industrie de la vidéo en streaming utilise depuis longtemps les technologies ABR (Adaptive bitrate) qui divisent un flux en plusieurs segments ou fragments vidéo individuels. Chaque segment a la même durée ou la même taille, mais est codé à différents niveaux de qualité vidéo ou débits binaires afin que le flux puisse s’adapter à la bande passante disponible du spectateur lorsque de nouveaux segments sont demandés. Les deux principaux protocoles ABR, HLS et MPEG-DASH d’Apple, fournissent des commandes pour ajuster la taille des segments.
La taille des segments joue un rôle majeur dans la latence car le lecteur doit télécharger un nombre prédéfini de segments avant de pouvoir commencer à lire le flux en direct. Cela permet au lecteur vidéo client de mettre suffisamment de vidéo en mémoire tampon pour assurer une lecture vidéo fluide sans remise en mémoire tampon en cas de congestion du réseau. Cependant, cela met également le flux derrière en direct dès le départ. Généralement, les lecteurs vidéo intégrés sur les appareils iOS et les navigateurs Web mettent en mémoire tampon trois segments vidéo avant de commencer la lecture. Si un segment dure quatre secondes et que le joueur doit mettre trois segments en mémoire tampon avant de pouvoir commencer à jouer, alors le client a déjà 12 secondes de retard en direct. Le protocole DASH offre une certaine flexibilité en permettant aux fichiers manifest de spécifier la quantité d’un fichier à mettre en mémoire tampon. Pourtant, de nombreux lecteurs et appareils DASH n’ont pas encore implémenté cette fonctionnalité.
Réduction du temps de retard
Puisque la mise en mémoire tampon de trois segments est la norme de facto, la technique la plus populaire pour réduire le temps de retard est de réduire la taille ou la durée de chaque segment. Dans l’exemple ci-dessous, en réduisant la taille du segment de quatre secondes à deux secondes, le temps de retard est réduit à seulement six secondes, soit la moitié de ce qu’il serait avec des segments de quatre secondes.
Des segments plus petits peuvent provoquer des rebuffers
Lorsque vous utilisez des segments de taille plus petite, le workflow vidéo doit être plus réactif pour offrir une expérience de streaming vidéo en direct sans tampon. Cela est dû à deux facteurs :
Tout d’abord, en réduisant la taille des segments, le lecteur, qui stocke un nombre fixe de segments, stocke désormais moins de vidéo. Et comme les tailles de segment plus courtes signifient plus de fichiers, votre workflow vidéo et, surtout, le réseau de diffusion de contenu doivent traiter et livrer deux fois plus de demandes de fichiers des lecteurs sur une durée de diffusion donnée. Comme il y a moins de vidéo mise en mémoire tampon dans le lecteur pendant la congestion du réseau, il est plus probable que la congestion provoque une remise en mémoire tampon. Le joueur est maintenant plus sensible à la congestion, même lors de petits événements de congestion.
Deuxièmement, comme nous l’avons expliqué dans un récent article technique, optimiser le CDN pour le streaming en direct, il est courant dans les sports en direct de voir des pics de spectateurs lorsque les événements populaires commencent ou lorsqu’un match serré approche des dernières minutes. À mesure que le nombre de demandes de fichiers augmente, le CDN doit prendre en charge davantage de demandes de fichiers dans le même laps de temps. Cette tâche est aggravée par divers types de périphériques et vitesses de connexion spécifiées par des paramètres de débit binaire adaptatif.
Pour illustrer l’augmentation du volume des fichiers, la figure 2 montre un segment vidéo de 16 secondes diffusé dans des segments de longueur différente. Avec des segments de quatre secondes, seuls quatre fichiers sont nécessaires pour fournir le segment de 16 secondes. Mais lorsque nous passons à des segments de deux secondes, nous avons besoin de huit fichiers distincts, soit deux fois plus de fichiers à traiter via le CDN.
Améliorez les performances de livraison des segments avec Hot Filing
Nous avons créé une fonctionnalité appelée Hot Filing pour traiter le phénomène dit de « foule flash » lorsque de nombreux téléspectateurs en direct rejoignent un flux en même temps. Cette fonctionnalité fait référence à la réplication rapide d’un segment populaire ou d’un « fichier chaud » vers des serveurs supplémentaires au sein d’un POP (point de présence), afin qu’il puisse être livré aux téléspectateurs aussi rapidement que la demande augmente rapidement.
En répartissant la charge sur de nombreux serveurs, Hot Filing empêche un serveur d’être submergé lorsque les demandes de fichiers augmentent soudainement. Lorsqu’un serveur est surchargé, semblable à une attaque par déni de service, le serveur sera lent à répondre aux demandes de fichiers, ce qui pourrait entraîner une remise en mémoire tampon dans le lecteur client. En identifiant et en répliquant rapidement les fichiers Hot, le risque de surcharge d’un seul serveur est beaucoup plus faible. Les changements soudains de la demande peuvent maintenant être satisfaits sans ajouter de latence.
La figure 3 montre comment Hot Filing (Fig. 3.b) améliore les performances en empêchant la surcharge du serveur. Sans Hot Filing (Fig. 3.a), tout le trafic d’un segment est acheminé vers le serveur 1 (S1). À mesure que la demande du public augmente, le trafic supplémentaire circule vers S1, le poussant au-dessus de sa capacité de 100 utilisateurs. La situation continue de se détériorer, le S1 desservant 200 téléspectateurs au pic. En revanche, Hot Filing (Fig. 3.b) gère cette charge supplémentaire en répliquant les fichiers sur deux serveurs (S1 plus S2) et en réacheminant les requêtes de fichiers vers le nouveau serveur disponible.
Identification plus rapide des fichiers Hot
Nous avons récemment amélioré le Hot Filing en réduisant d’une seconde le temps nécessaire pour déplacer les fichiers Hot vers plusieurs serveurs. Nous avons amélioré le temps de réaction en modifiant la façon dont les fichiers Hot sont identifiés dans une pop. Nous utilisons un processus central pour agréger les demandes de fichiers et le nombre d’octets à des fins d’analyse. Auparavant, les données étaient extraites du processus du serveur Web sur chaque serveur. Bien que cela fonctionne bien, nous avons découvert qu’un serveur Web lent pourrait ralentir l’agrégation des données de fichiers Hot. Pour résoudre ce problème, les serveurs écrivent maintenant leur requête et les octets décompte sur le disque chaque seconde. Par conséquent, lorsque le processus central extrait des données, il n’a pas besoin d’attendre les processus du serveur Web puisque les données sont déjà écrites sur un disque SSD. Ce changement à lui seul est suffisant pour supporter la charge de la plupart des événements en direct.
L’importance cruciale d’un temps de réaction rapide pour les événements en direct est illustrée à la figure 3.c, qui offre un aperçu de la façon dont le processus de Hot Filing fonctionne pour recruter des ressources supplémentaires. Dans l’exemple illustré à la figure 3.c, lorsque le serveur S1 dépasse sa capacité de 100 utilisateurs, les fichiers sont rapidement déplacés vers S2 lorsqu’il atteint sa capacité. Cela permet au système d’accueillir les 200 utilisateurs rapidement et efficacement et d’utiliser toute la capacité des serveurs disponibles.
Dépôt à chaud sur plusieurs ports
Pour les événements extrêmement populaires, tels que les matchs de playoff de football professionnel ou les grands matchs de football internationaux, les pics et les pics de trafic peuvent être très importants. Répondre à ce niveau de demande nécessite également de modifier la façon dont les segments de fichiers sont répliqués afin d’augmenter la capacité du serveur. Auparavant, le réseau de diffusion de contenu était limité à la réplication de segments sur un port par serveur. Mais maintenant, nous pouvons répliquer des fichiers sur plusieurs ports dans chaque serveur. Cela augmente considérablement le débit de chaque serveur afin que chaque pop puisse traiter plus de requêtes et, par conséquent, des événements en direct beaucoup plus importants qu’auparavant.
Dans notre système, l’équilibrage de charge est géré par le hachage CARP (cache Array Routing Protocol). Pour le contenu régulier, notre approche a été de répliquer les fichiers sur plusieurs serveurs, et nous utilisons le hachage CARP pour sélectionner un port unique à partir de chaque serveur. Nous le faisons pour empêcher les requêtes en double d’être envoyées au serveur d’origine et pour limiter la communication entre les processus.
Quand un fichier devient assez chaud, CARP commence à sélectionner plusieurs ports par serveur pour prendre en charge encore plus de requêtes. Cette approche fonctionne bien pour les fichiers hot car ils ne représentent qu’une petite fraction des fichiers uniques servis par un serveur. Le nombre de ports ouverts dépend de la demande d’un fichier actif. Cette approche augmente le volume de données servi par serveur et la quantité de puissance CPU disponible pour traiter ces requêtes.
Conclusion
Alors que les fournisseurs de services de streaming réduisent la taille des segments vidéo pour fournir un flux en direct à latence plus faible, les capacités de dépôt à chaud de la plateforme Edgio aident le réseau de diffusion de contenu à gérer les demandes accrues de fichiers vidéo, en particulier à mesure que la taille de l’audience augmente pour les événements sportifs populaires.
