Au cours des dernières années, le secteur de la diffusion vidéo en continu a connu un intérêt considérable pour les protocoles de diffusion vidéo en continu à faible latence. L'intérêt porte essentiellement sur la diffusion de vidéos avec un délai inférieur à cinq secondes, ce qui les rend comparables aux délais des systèmes de télédiffusion en direct. L'obtention d'un délai aussi faible est essentielle pour la diffusion en continu de sports en direct, de jeux, d'apprentissage en ligne, d'applications vidéo interactives, etc.
DÉVELOPPER LA TECHNOLOGIE DE DIFFUSION EN CONTINU À FAIBLE LATENCE
Les délais des technologies classiques de diffusion en direct OTT, telles que HLS et DASH, sont beaucoup plus longs. Ils sont dus à des segments relativement longs (4 à 10 secondes) et à un modèle de diffusion basé sur les segments, qui exige la diffusion complète de chaque segment de média avant la lecture. Combiné aux stratégies de mise en mémoire tampon utilisées par les clients de diffusion en continu HLS ou DASH, cela produit généralement des retards de 10 à 30 secondes, voire plus.
Pour lutter contre les retards, les évolutions récentes des normes HLS et DASH, connues sous le nom de Low-Latency HLS (LL-HLS) et Low-Latency DASH (LL-DASH), ont introduit deux outils clés :
- Encodage vidéo par morceaux. Il s'agit d'une stratégie de codage qui produit des segments vidéo structurés comme des séquences de sous-segments ou de morceaux beaucoup plus courts.
- Transfert de segments groupés. Il s'agit d'un mode de transfert HTTP qui permet la transmission de morceaux vidéo plus courts aux clients de diffusion en continu dès qu'ils sont générés.
Un client de diffusion en continu peut rejoindre un flux en direct à faible latence à partir de n'importe quel point d'accès au flux (SAP) mis à disposition par le transcodeur en direct à la limite des segments ou des morceaux. Une fois qu'il a rejoint le flux, le lecteur n'a plus qu'à mettre en mémoire tampon le dernier bloc vidéo généré par l'encodeur avant de le décoder et de le restituer. Étant donné que chaque segment peut être divisé en plusieurs morceaux (généralement de 4 à 10), le délai est considérablement réduit.
Plusieurs implémentations libres et propriétaires de serveurs et de lecteurs à faible latence sont actuellement disponibles sur le marché, y compris celle de Brightcove. Nombre d'entre eux ont démontré qu'ils réduisaient le délai de diffusion en continu lorsqu'un flux à un seul débit est utilisé et lorsqu'ils diffusent en continu sur des connexions réseau à haut débit. Toutefois, leurs performances dans des environnements de déploiement plus complexes et réalistes n'ont pas été bien étudiées.
TESTER LES PERFORMANCES DE LA DIFFUSION EN CONTINU À FAIBLE LATENCE
Dans notre article publié dans ACM Mile-High-Video 2023 (lien à venir) ainsi que dans une présentation à Facebook@Scale, nous avons rapporté certains résultats après avoir testé les performances des systèmes vidéo à faible latence.
Tout d'abord, nous avons développé un banc d'essai d'évaluation pour les systèmes LL-HLS et LL-DASH. Nous avons ensuite évalué divers lecteurs à faible latence à l'aide de ce banc d'essai, notamment Dash.js, HLS.js, Shaka player et Theo player. Nous avons également évalué plusieurs des derniers algorithmes d'adaptation du débit avec des optimisations pour les lecteurs en direct à faible latence. L'évaluation s'est basée sur une série d'expériences de streaming en direct. Ces expériences ont été répétées en utilisant un contenu vidéo, des profils d'encodage et des conditions de réseau identiques (émulés en utilisant des traces de réseaux réels).
Le tableau 1 présente nos profils d'encodage vidéo en direct pour générer le flux DASH/HLS à plusieurs débits et à faible latence.
| Rendition | Résolution vidéo (pixels) | Codec et profil vidéo | Débit binaire (kbps) |
|---|---|---|---|
| faible | 768 x 432 | H.264 principal | 949 |
| moyen | 1024 x 576 | H.264 principal | 1854 |
| élevé | 1600 x 900 | H.264 principal | 3624 |
| sommet | 1920 x 1080 | H.264 principal | 5166 |
Tableau 1. Profils d'encodage de la vidéo en direct
La figure 1 illustre les flux de travail de nos bancs d'essai de streaming DASH et HLS à faible latence.
Figure 1. Configuration du système utilisé pour l'évaluation des lecteurs à faible latence.
La figure 2 montre la bande passante disponible de notre réseau mobile LTE émulé. La bande passante de téléchargement des lecteurs à faible latence est contrôlée par notre outil d'émulation de réseau et les traces de réseau.
Figure 2. Largeur de bande disponible des réseaux mobiles LTE émulés (Verizon et T-Mobile)
Diverses mesures des performances du système (débit binaire moyen, quantité de données multimédia téléchargées, temps de latence de la diffusion en continu) ainsi que des statistiques sur la mise en mémoire tampon et la commutation de flux ont été saisies et rapportées dans nos expériences.
Ces résultats ont ensuite été utilisés pour décrire les différences observées dans la performance des lecteurs et systèmes LL-HLS et LL-DASH.
Quelques graphiques de notre étude sont présentés dans les figures ci-dessous.
Figure 3. Dynamique des changements de débit signalés par les acteurs LL-HLS et LL-DASH.
Figure 4. Comparaison des variations de latence signalées par les lecteurs LL-HLS et LL-DASH.
Statistiques de performance - Réseau LTE de T-Mobile
| Joueur/Algorithme | Débit moyen [kbps] | Hauteur moyenne [pixels] | Temps de latence moyen [secondes] | Temps de latence var. [secs] | Var. de vitesse [%] | Nombre de commutateurs | Événements de la mémoire tampon | Taux de tampon [%] | MBs chargés | Objets chargés |
|---|---|---|---|---|---|---|---|---|---|---|
| DASH.js par défaut | 2770 | 726 | 3.06 | 0.21 | 10.4 | 93 | 38 | 7.99 | 352.2 | 256 |
| DASH.js LolP | 3496 | 853 | 5.65 | 4.59 | 22.7 | 70 | 53 | 21.96 | 369.4 | 210 |
| DASH.js L2all | 3699 | 908 | 4.14 | 3.18 | 19.9 | 5 | 19 | 7.99 | 368 | 147 |
| Joueur Shaka (dash) | 3818 | 916 | 4.92 | 2.06 | 0 | 16 | 5 | 4.66 | 360.3 | 155 |
| Joueur THEO (tiret) | 4594 | 993 | 6.16 | 0.01 | 0 | 27 | 0 | 0 | 418.7 | 152 |
| HLS.js par défaut 2020 | 1763 | 562 | 10.08 | 10.91 | 8.1 | 26 | 2 | 9.8 | 130.7 | 589 |
| HLS.js LolP 2020 | 1756 | 560 | 5.97 | 0.2 | 6.1 | 24 | 0 | 0 | 148.1 | 688 |
| HLS.js L2all 2020 | 1752 | 560 | 6 | 0.23 | 5.9 | 34 | 0 | 0 | 133.1 | 686 |
| HLS.js par défaut 2023 | 3971 | 895 | 8.93 | 1.13 | 0 | 8 | 0 | 0 | 360.8 | 613 |
| Joueur Shaka (HLS) | 3955 | 908 | 7.18 | 2.23 | 0 | 14 | 7 | 3.8 | 230 | 475 |
Tableau 2. Statistiques de performance - Réseau LTE de T-Mobile
L'ÉVALUATION DES PERFORMANCES DE LA DIFFUSION EN CONTINU À FAIBLE LATENCE
Alors que LL-HLS et LL-DASH ont bien fonctionné dans des environnements de réseau sans contraintes, ils ont eu du mal dans les réseaux à faible bande passante ou à forte variabilité (qui sont typiques des déploiements mobiles). Les effets observés comprennent des retards très variables, l'incapacité d'empêcher la mise en mémoire tampon et des changements fréquents de bande passante ou l'incapacité d'utiliser la bande passante disponible du réseau. Certains joueurs ont tout simplement opté pour une diffusion en continu sans faible latence dans des conditions de réseau aussi difficiles.
Aussi prometteuses que soient les technologies LL-HLS ou LL-DASH en théorie, elles ont encore une certaine marge de manœuvre pour arriver à maturité.
Chez Brightcove, nous continuons à travailler sur les meilleures implémentations d'algorithmes pour les clients de diffusion en continu à faible latence, ainsi que sur les optimisations de l'encodeur et du serveur. Nous avons l'intention de rendre notre prise en charge de la diffusion en continu à faible latence hautement évolutive, fiable et totalement prête pour le prime time.
Ce blog a été initialement rédigé par Yuriy Reznik en 2021 et a été mis à jour dans un souci d'exactitude et d'exhaustivité.
