Qu’est-ce que le streaming à débit binaire adaptatif ?

Le streaming à débit binaire adaptatif propose plusieurs variantes encodées du même contenu. Le lecteur passe de l’une à l’autre selon la bande passante, l’état du tampon et les capacités de l’appareil pendant la lecture.

Une vidéo source

Échelle de variantes, segmentées et répertoriées dans un manifeste

Le lecteur demande une variante par segment

L’échelle est encodée et conditionnée avant que ses segments ne soient demandés. Pendant la lecture, le lecteur choisit une variante pour chaque requête de segment à partir de ses propres mesures : le serveur ne transcode donc pas pour chaque spectateur.

Le streaming adaptatif divise les variantes alignées dans le temps en segments multimédias adressables et les décrit dans un manifeste : une liste de lecture en HLS, un document XML appelé MPD en MPEG-DASH. Le lecteur choisit une variante pour les prochaines requêtes de segments à partir d’indicateurs tels que le débit mesuré et les médias en mémoire tampon. Le changement de variante est donc une décision de diffusion côté client, plutôt qu’un transcodage côté serveur en cours de flux. Les deux protocoles peuvent transporter des segments MP4 fragmentés, ce qui permet au conditionnement CMAF de servir un même ensemble de fichiers multimédias sous les deux manifestes.

La fluidité des changements de variante se prépare lors de l’encodage et du conditionnement. La RFC 8216 exige que les contenus correspondants de chaque variante HLS portent des horodatages identiques, et la spécification de création d’Apple exige que chaque segment vidéo commence par une image IDR et recommande de placer les limites des segments aux mêmes instants dans toutes les variantes. Le profil d’interopérabilité DASH-IF fait également commencer chaque segment par un point d’accès de type IDR et aligne les limites des segments au sein d’un Adaptation Set.
L’algorithme de changement de variante relève du lecteur, et non du protocole : la RFC 8216 l’exclut de son périmètre, si bien qu’un même flux peut se comporter différemment selon les lecteurs. Dans hls.js, par exemple, les paramètres par défaut exigent une marge de bande passante plus importante pour passer au niveau supérieur (abrBandWidthUpFactor) que pour maintenir ou réduire le niveau (abrBandWidthFactor), et la limitation de la qualité aux dimensions de l’élément vidéo ou la réaction aux images perdues ne s’appliquent que lorsque capLevelToPlayerSize ou capLevelOnFPSDrop est activé ; les deux sont désactivés par défaut.
La qualité au démarrage dépend de l’ordre de la liste de lecture et des paramètres du lecteur. La spécification d’Apple considère la première variante répertoriée dans la liste de lecture multivariante, au sein de chaque groupe de variantes dont l’audio est compatible, comme la variante par défaut de ce groupe. Dans hls.js, laisser startLevel non défini ne fixe pas la lecture au premier niveau répertorié, même si certaines parties de sa documentation d’API l’affirment : le code source de la version v1.6.13 choisit le niveau de démarrage à partir d’une estimation de la bande passante, que le débit binaire de la première variante répertoriée peut relever. L’ordre de la liste de lecture influence donc le démarrage sans le déterminer. Lorsque startLevel est défini sur -1, hls.js télécharge par défaut un fragment du niveau le plus bas pour estimer la bande passante avant de choisir.
L’espacement des niveaux de l’échelle dépend du contenu, et les débits déclarés doivent être exacts. Apple présente ses tableaux de débits binaires comme des cibles de départ à évaluer avec votre propre contenu, et les travaux de Netflix sur l’encodage par titre ont montré qu’une échelle fixe consomme plus de bits que nécessaire pour les titres simples tout en laissant des artefacts dans les titres complexes. Son objectif déclaré est d’espacer les niveaux adjacents d’environ une différence juste perceptible, afin de maintenir des transitions fluides avec le moins de variantes possible. En HLS, la RFC 8216 avertit qu’une valeur BANDWIDTH inexacte peut provoquer des interruptions ou empêcher la lecture d’une variante.

Proposez une échelle de débits binaires lorsque les variations des conditions réseau provoqueraient autrement des interruptions. Des variantes mal espacées peuvent gaspiller du stockage ou imposer des baisses de qualité visibles sans améliorer sensiblement la continuité de lecture.

Le Robot /video/adaptive de Transloadit conditionne les variantes encodées en sorties HLS, MPEG-DASH ou CMAF et génère les fichiers de listes de lecture et de manifestes ; lorsque technique est défini sur cmaf, les manifestes DASH et HLS font référence aux mêmes segments fMP4. Les variantes proviennent normalement de Steps utilisant le Robot /video/encode avec les préréglages hls/ ou dash/, et sont regroupées dans un seul Step utilisant le Robot /video/adaptive.

Transloadit prépare les fichiers ; le choix d’une variante pendant la lecture est effectué par le lecteur que vous utilisez. La documentation du Robot décrit aussi comment imposer des images clés correspondantes dans chaque Step utilisant le Robot /video/encode afin d’aligner les segments entre les variantes, les en-têtes CORS à configurer sur votre serveur de fichiers (nécessaires lorsque le lecteur charge les fichiers depuis une autre origine), ainsi que les métadonnées relative_path à utiliser lors du stockage des segments pour que les références des listes de lecture soient résolues.

Explorer les possibilités de diffusion en continu de Transloadit

Qu’est-ce que le streaming à débit binaire adaptatif ?

Fonctionnement du streaming à débit binaire adaptatif

Points clés

Quand le streaming à débit binaire adaptatif est utile

Comment Transloadit vous aide avec le streaming à débit binaire adaptatif

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle