Blog

Evolution Of Low Latency Streaming

Tech Talk

Encoding

OTT

L'ÉVOLUTION DE LA DIFFUSION VIDÉO EN CONTINU À FAIBLE LATENCE

May 1, 2023

Les essais de systèmes à faible latence dans des conditions réalistes suggèrent que ces technologies ont encore une certaine marge de manœuvre pour arriver à maturité.

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

Video resolution (pixels)

Video codec and profile

Bitrate (kbps)

low

768 x 432

H.264 main

949

mid

1024 x 576

H.264 main

1854

high

1600 x 900

H.264 main

3624

top

1920 x 1080

H.264 main

5166

La figure 1 illustre les flux de travail de nos bancs d'essai de streaming DASH et HLS à faible latence.

Figure 1.Figure 1. System setup used for evaluation of low-latency players.

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.Figure 2. Available bandwidth of emulated LTE mobile networks (Verizon and 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.

Performance statistics – T-Mobile LTE network

Player/Algorithm

Avg. bitrate [kbps]

Avg. height [pixels]

Avg. latency [secs]

Latency
var. [secs]

Speed var. [%]

Number of switches

Buffer events

Buffer ratio [%]

MBs loaded

Objects loaded

DASH.js default

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

Shaka player (dash)

3818

916

4.92

2.06

0

16

5

4.66

360.3

155

THEO player (dash)

4594

993

6.16

0.01

0

27

0

0

418.7

152

HLS.js default 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 default 2023

3971

895

8.93

1.13

0

8

0

0

360.8

613

Shaka player (HLS)

3955

908

7.18

2.23

0

14

7

3.8

230

475

Table 2.Table 2. Performance statistics – T-Mobile LTE network

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é.