Les sports en direct sont passionnants à regarder. Surtout pendant les moments cruciaux, comme quand un tir sort de nulle part pour gagner la partie. Ces moments peuvent également être passionnants pour l’équipe technique chargée de livrer des actions fluides et en temps réel. Les flux sportifs en direct doivent équilibrer plusieurs considérations techniques et compromis, en moyenne 30 secondes derrière le match en direct sur le terrain. Pourquoi ce 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’acquisition 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, qui peut être affecté par la bande passante et l’infrastructure disponibles. Vient ensuite le transcodage et le packaging du contenu pour divers appareils et bandes passantes. Enfin, pendant que le flux est en cours de lecture, la publicité peut être insérée dynamiquement dans le flux juste avant qu’il ne se déplace à travers le dernier kilomètre de l’Internet vers 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 gagnant 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 en même temps. 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, tels que les courses de chevaux, les diffusions différées désavantagent les participants distants par rapport à ceux présents 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 regardent à la télévision et en streaming en direct. Et avec de plus en plus de spectateurs utilisant un deuxième écran tout en regardant des sports en direct, il n’est pas étonnant que la réduction du temps derrière le direct devienne une exigence importante pour rester compétitif et offrir une expérience visuelle exceptionnelle.
Réduire la latence est un domaine d’intérêt pour nous chez Edgecast, maintenant Edgio. Cet effort implique la recherche et la mise en œuvre d’améliorations incrémentielles à chaque étape du traitement et des 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 le volume de requêtes accru qui résulte d’une stratégie de plus en plus populaire à faible latence – celle de la réduction de la taille des segments.
Dans le but de réduire le temps passé en direct, 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 cela entraîne des compromis tels que des frais supplémentaires et un 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 QoE. 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 de la publicité personnalisée, de la programmation 4k ou pour permettre l’édition de contenu en direct.
Rôle de la taille du segment dans la latence
L’industrie du streaming vidéo utilise depuis longtemps les technologies ABR (Adaptive bitrate) qui divisent un flux en de nombreux segments ou blocs vidéo individuels. Chaque segment a la même durée ou la même taille, mais est encodé à 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 joueur doit télécharger un nombre prédéfini de segments avant de pouvoir commencer à jouer le flux en direct. Ceci est fait pour que le lecteur vidéo client puisse 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 dans le réseau. Cependant, cela met également le flux derrière en direct dès le début. 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 en mémoire tampon trois segments avant de pouvoir commencer à jouer, alors le client est déjà 12 secondes en retard sur Live. 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 mis en œuvre cette fonctionnalité.
Réduction du temps passé en direct
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 vie 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 écoulé entre le temps d’activation est réduit à seulement six secondes, soit la moitié de ce qu’il serait avec des segments de quatre secondes.
Les segments plus petits peuvent entraîner des remises en mémoire tampon
Lorsque vous utilisez des segments de plus petite taille, le workflow vidéo doit être plus réactif pour offrir une expérience de streaming vidéo en direct sans tampon. Ceci est dû à deux facteurs:
Premièrement, en réduisant la taille des segments, le lecteur, qui stocke un nombre fixe de segments, stocke désormais moins de vidéos. Et comme la taille des segments plus courte signifie plus de fichiers, votre workflow vidéo et, surtout, le réseau de diffusion de contenu doivent traiter et transmettre deux fois plus de demandes de fichiers de la part 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 d’événements de congestion plus petits.
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 sursauts de téléspectateurs lorsque des événements populaires commencent ou lorsqu’un match proche approche les dernières minutes. Au fur et à mesure que le nombre de demandes de fichiers augmente, le CDN doit prendre en charge plus 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 les paramètres de débit adaptatif.
Pour illustrer l’augmentation du volume de fichiers, la figure 2 montre un segment vidéo de 16 secondes livré dans des segments de longueur différente. Avec des segments de quatre secondes, seuls quatre fichiers sont nécessaires pour livrer le segment de 16 secondes. Mais lorsque nous passons à des segments de deux secondes, nous avons besoin de huit fichiers distincts – deux fois plus de fichiers qui doivent être traités via le CDN.
Améliorez les performances de livraison des segments avec Hot Filing
Nous avons créé une fonctionnalité appelée Hot Filing pour faire face au phénomène appelé « flash crowd » 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 « fichier actif » sur des serveurs supplémentaires au sein d’un POP (point de présence), afin qu’il puisse être livré aux spectateurs aussi rapidement que la demande augmente rapidement.
En répartissant la charge sur de nombreux serveurs, le Hot Filing empêche un serveur de se trouver submergé lorsque les demandes de fichiers augmentent soudainement. Lorsqu’un serveur est surchargé, comme 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 actifs, 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 le Hot Filing (Fig. 3.b) améliore les performances en évitant 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 à empirer alors que S1 dessert 200 téléspectateurs au plus fort. En revanche, le 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 demandes de fichiers vers le serveur nouvellement disponible.
Identification plus rapide des fichiers actifs
Nous avons récemment amélioré le Hot Filing en réduisant d’une seconde le temps nécessaire pour déplacer les Hot Files vers plusieurs serveurs. Nous avons amélioré le temps de réaction en modifiant la façon dont les fichiers chauds sont identifiés dans un 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 ait bien fonctionné, nous avons découvert qu’un serveur Web lent pouvait ralentir l’agrégation des données de fichiers chauds. Pour résoudre ce problème, les serveurs écrivent maintenant leur requête et décompte les octets sur le disque toutes les secondes. 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 suffit à lui seul pour accommoder 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 du fonctionnement du processus de dépôt à chaud 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 à mesure qu’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.
Archivage à chaud sur plusieurs ports
Pour les événements extrêmement populaires, tels que les matchs de football professionnel ou les grands matchs internationaux de football, les pics et les pics de trafic peuvent être très importants. Pour répondre à ce niveau de demande, il est également nécessaire 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, de sorte que chaque POP peut 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 consisté à répliquer les fichiers sur plusieurs serveurs, et nous utilisons le hachage CARP pour sélectionner un seul port sur chaque serveur. Nous faisons cela pour empêcher les requêtes en double d’être envoyées au serveur d’origine et pour limiter la communication entre processus.
Lorsqu’un fichier devient suffisamment chaud, CARP commence à sélectionner plusieurs ports par serveur pour prendre en charge encore plus de demandes. Cette approche fonctionne bien pour les fichiers chauds 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 de fichier prioritaire. Cette approche augmente le volume de données servi par serveur et la quantité de puissance CPU disponible pour traiter ces demandes.
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 plate-forme d’Edgio aident le réseau de diffusion de contenu à gérer l’augmentation des demandes de fichiers vidéo, en particulier à mesure que la taille du public augmente pour les événements sportifs populaires.
