Nous sommes ravis de présenter aujourd’hui Concurrent Streaming Acceleration, une nouvelle technique permettant de réduire le temps de latence de bout en bout de la vidéo en direct sur le Web lors de l’utilisation de Stream Delivery.
Explorons la latence de la diffusion en direct, pourquoi elle est importante et ce qui a été fait pour l’améliorer.
Comment « en direct » est vidéo « en direct » ?
La diffusion en direct constitue une part croissante de la vidéo sur le Web. Qu'il s'agisse d'une émission télévisée, d'une émission de jeu en direct ou de cours en ligne, les utilisateurs s'attendent à ce que la vidéo arrive rapidement et sans accroc. Et la promesse du « direct » est que l'utilisateur voit les événements au fur et à mesure qu'ils se produisent. Mais à quelle distance du « temps réel » se trouve la vidéo Internet « en direct » ?
Diffuser de la vidéo en direct sur Internet est toujours difficile et ajoute beaucoup de temps de latence :
La source de contenu enregistre la vidéo et l'envoie à un serveur de codage ;
Le serveur d’origine transforme cette vidéo en un format tel que DASH, HLS ou CMAF pouvant être transmis efficacement à des millions de périphériques ;
On utilise généralement un CDN pour diffuser de la vidéo codée dans le monde entier
Les lecteurs des clients décodent la vidéo et l’affichent à l'écran
Et tout cela est soumis à une contrainte de temps. Tout le processus doit se dérouler en quelques secondes, sinon la vidéo sera de mauvaise qualité. Nous appelons le délai total entre le moment où la vidéo a été tournée et le moment où elle peut être visionnée sur le périphérique d'un utilisateur final, « latence de bout en bout » (considérez-le comme le temps écoulé entre l'objectif de l'appareil photo et l'écran de votre téléphone).
Livraison segmentée traditionnelle
Les formats vidéo tels que DASH, HLS et CMAF fonctionnent en divisant la vidéo en petits fichiers, appelés « segments ». Une durée de segment typique est de 6 secondes.
Si un lecteur client doit attendre que tout un segment de 6 secondes soit codé, envoyé via un CDN, puis décodé, l'attente peut être longue ! Cela prend encore plus de temps si vous voulez que le client crée un tampon de segments pour se protéger contre les interruptions de livraison. Un tampon de lecteur typique pour HLS est constitué de 3 segments :
Les clients peuvent avoir à mettre en tampon trois fragments de 6 secondes, introduisant au moins 18 secondes de latence
Lorsque l’on considère les délais d’encodage, il est facile de comprendre pourquoi la latence de la diffusion en direct sur Internet est généralement d’environ 20 à 30 secondes. Nous pouvons faire mieux.
Latence réduite avec codage de transfert en fragments
Permettre aux lecteurs clients de commencer à jouer les fragments tout en téléchargeant, ou même pendant qu’ils sont en cours de création, est un moyen naturel de résoudre ce problème. Rendre cela possible nécessite une petite coopération intelligente pour coder et livrer les fichiers d'une manière particulière, appelée « codage en fragment ». Cela implique de diviser des segments en morceaux plus petits, de la taille de bouchées ou « fragments ». Le codage par fragments peut généralement ramener la latence réelle à 5 ou 10 secondes.
Sujet à confusion, le mot « fragment » est surchargé car il peut renvoyer à deux choses différentes :
Les fragments CMAF ou HLS, qui sont de petits morceaux d'un segment (généralement des 1) alignés sur des images clés
Les fragments HTTP, qui sont juste un moyen de livrer n'importe quel fichier sur le web
L'encodage par fragment divise les segments en fragments plus courts
Les fragments HTTP sont importants car les clients Web ont une capacité limitée à traiter des flux de données. La plupart des clients ne peuvent utiliser les données qu’une fois qu’ils ont reçu la réponse HTTP complète ou au moins un fragment HTTP complet. En utilisant l'encodage de transfert HTTP par fragment, nous permettons aux lecteurs de vidéos de commencer à analyser et décoder la vidéo plus rapidement.
Les fragments CMAF sont importants pour que les décodeurs puissent réellement lire les bits contenus dans les fragments HTTP. Sans coder soigneusement la vidéo, les décodeurs auraient des bits aléatoires d’un fichier vidéo qui ne peut pas être lu.
Les CDN peuvent introduire une mise en mémoire tampon supplémentaire
Le codage par fragments avec HLS et CMAF est de plus en plus utilisé sur le Web. Ce qui rend cette technique remarquable, c’est en partie le fait que le codage par fragments HTTP est largement pris en charge par les CDN. Il fait partie de la spécification HTTP depuis 20 ans.
La prise en charge de CDN est essentielle car elle permet à la vidéo en direct à faible latence d’augmenter et d’atteindre un public de milliers ou de millions de téléspectateurs au même moment, ce qui est actuellement très difficile à faire avec d’autres protocoles non HTTP.
Malheureusement, même si vous activez la fragmentation pour optimiser la livraison, votre CDN peut fonctionner contre vous en mettant en mémoire tampon le segment entier. Pour comprendre pourquoi prendre en considération ce qui se passe lorsque de nombreuses personnes demandent un segment en direct au même moment :
Si le fichier est déjà en cache, super ! Les CDN font un excellent travail en fournissant des fichiers en cache à un vaste public. Mais que se passe-t-il lorsque le segment n’est pas encore dans le cache ? N'oubliez pas : il s'agit du modèle de demande typique pour la vidéo en direct !
En règle générale, les CDN sont en mesure de « diffuser en continu sur les requêtes de la mémoire cache non satisfaite » à partir de la source. Cela ressemble à ceci :
Mais encore une fois, que se passe-t-il lorsque plusieurs personnes demandent le fichier à la fois ? Les CDN doivent généralement mettre l'intégralité du fichier en cache avant de servir des téléspectateurs supplémentaires :
Un seul téléspectateur peut diffuser de la vidéo, tandis que d'autres clients attendent que le segment soit mis en mémoire tampon sur le CDN
Cela est compréhensible. Les centres de données CDN sont constitués de nombreux serveurs. Pour éviter de surcharger les sources, ces serveurs se coordonnent généralement entre eux à l'aide d'un « verrou de cache » (mutex) qui permet à un seul serveur de demander un fichier particulier à l'origine à un moment donné. L’un des effets secondaires de cette opération est que, même si un fichier est mis en cache, il ne peut être servi à aucun autre utilisateur que le premier qui l’a demandé. Malheureusement, ce verrou de cache va également à l'encontre de l'utilisation de l'encodage par fragments !
Pour récapituler jusqu'à présent :
Le codage par fragments divise les segments vidéo en morceaux plus petits
Cela peut réduire la latence de bout en bout en permettant aux lecteurs d'extraire et de décoder des fragments, même pendant la production de segments sur le serveur source
Certains CDN neutralisent les avantages de l'encodage par fragments en mettant en mémoire tampon des fichiers entiers à l'intérieur du CDN avant qu'ils ne puissent être livrés aux clients
La solution de Cloudflare : Accélération de la diffusion simultanée
Comme vous l'avez peut-être deviné, nous pensons pouvoir faire mieux. En termes simples, nous avons désormais la possibilité de livrer des fichiers n’étant pas mis en cache à plusieurs clients simultanément pendant que nous extrayons le fichier du serveur source.
Cela ressemble à un simple changement mais il faut être assez subtile pour le faire en toute sécurité. En toute discrétion, nous avons profondément modifié notre infrastructure de mise en cache pour supprimer le verrou de cache et permettre à plusieurs clients de pouvoir lire en toute sécurité à partir d’un seul fichier pendant son écriture.
La bonne nouvelle est que l’ensemble de Cloudflare fonctionne maintenant de cette façon ! Il n’est pas nécessaire de s’inscrire, ni même d’effectuer un changement de configuration pour profiter des avantages.
Nous avons lancé cette fonctionnalité il y a quelques mois et nous sommes vraiment satisfaits des résultats obtenus jusqu'à présent. Nous mesurons le succès en fonction du « temps d’attente du verrouillage du cache », c’est-à-dire combien de temps une demande doit attendre d’autres demandes, une composante directe de Time To First Byte. Un client OTT a vu cette métrique chuter de 1,5 seconde sur P99 à près de 0, comme prévu :
Cela se traduit directement par une amélioration de 1,5 seconde de la latence de bout en bout. La vidéo en direct encore plus en direct !
Conclusion
De nouvelles techniques telles que l'encodage par fragment ont révolutionné la diffusion en direct, permettant aux éditeurs de diffuser en direct et à grande échelle des vidéos avec une faible latence. L'accélération de diffusion simultanée vous permet de débrider la puissance de cette technique sur votre CDN, ce qui vous permet d'économiser de précieuses secondes de latence de bout en bout.
Si vous souhaitez utiliser Cloudflare pour la diffusion de vidéos en direct, contactez notre équipe commerciale.
Et si vous souhaitez travailler sur des projets de ce type et nous aider à améliorer la diffusion de vidéos en direct sur Internet, rejoignez notre équipe ingénierie !