Qu’est-ce que la bande passante vidéo ?

La bande passante vidéo est la capacité de transfert réseau nécessaire ou consommée pour diffuser de la vidéo au fil du temps. Ce besoin dépend du débit binaire encodé, du surcoût des protocoles, des flux simultanés et des variations du débit effectif disponible.

Le terme recouvre deux grandeurs différentes, dont la confusion cause la plupart des erreurs de planification. La première correspond aux besoins d’un flux : le nombre de bits par seconde nécessaire à un rendu, soit son débit binaire vidéo encodé auquel s’ajoutent l’audio et le surcoût du conteneur. La seconde correspond à ce que fournit une connexion : le débit effectif que le réseau du spectateur peut maintenir, qui varie à chaque instant. Les formats de diffusion en continu publient la première pour que les lecteurs puissent la comparer à leur propre mesure de la seconde. En HLS, chaque variante de la liste de lecture multivariante (principale) comporte un attribut obligatoire BANDWIDTH en bits par seconde, défini comme le débit binaire maximal des segments, et un attribut facultatif AVERAGE-BANDWIDTH ; les deux incluent le surcoût du conteneur, mais pas celui de HTTP, TCP ou IP. En MPEG-DASH, chaque Representation comporte une valeur @bandwidth, que les recommandations du DASH-IF expliquent à l’aide d’un modèle de seau percé, conjointement avec la durée minimale de mise en mémoire tampon. Un lecteur estime le débit effectif à partir de ses téléchargements récents de segments et sélectionne un rendu dont le débit déclaré respecte cette estimation. Pour un opérateur, ces mêmes chiffres par flux, multipliés par le nombre de spectateurs simultanés, donnent le débit effectif global de diffusion en périphérie du réseau, et ce débit multiplié par la durée de visionnage donne le volume de diffusion.

Quelle valeur faut-il inscrire dans la liste de lecture, la moyenne ou le maximum ? En HLS, BANDWIDTH est le maximum : pour une variante avec une seule liste de lecture média, il s’agit du débit binaire le plus élevé de toute séquence de segments contigus durant entre 0,5 et 1,5 fois la durée cible. AVERAGE-BANDWIDTH correspond à la taille totale des segments divisée par la durée de la liste de lecture. Lorsque l’audio ou d’autres rendus sont conditionnés séparément, la RFC 8216 exige que chaque valeur soit la somme la plus élevée parmi les combinaisons de rendus lisibles ; mesurer uniquement la liste de lecture vidéo sous-déclare donc la variante. Ces mesures nécessitent des segments terminés. Lorsque la liste de lecture est publiée avant que tous les segments soient encodés, comme lors d’un événement en direct, la RFC indique d’utiliser la valeur d’une période représentative de contenu similaire encodé avec les mêmes réglages. Elle avertit également qu’une valeur inexacte peut provoquer des interruptions de lecture ou empêcher les clients de lire la variante. Avec un encodage à débit variable, les deux valeurs divergent : pour le contenu à la demande, la spécification de création d’Apple recommande que le maximum ne dépasse pas 200 % de la moyenne et exige que le maximum mesuré ne s’écarte pas de plus de 10 % de la valeur déclarée pour BANDWIDTH. Le réglage du débit binaire vidéo d’un encodeur ne correspond à aucune de ces valeurs, car celles de la liste de lecture sont calculées à partir des segments conditionnés et incluent l’audio et le surcoût du conteneur.
De combien le débit de connexion d’un spectateur doit-il dépasser celui d’un rendu ? Il doit le dépasser de la marge de sécurité du lecteur, et non simplement l’égaler. hls.js, par exemple, documente deux facteurs par défaut : sa vérification normale de sélection du niveau actuel ou d’un niveau inférieur exige que 0,95 fois son estimation de bande passante dépasse le débit binaire du niveau, et il ne passe à un niveau supérieur que si 0,7 fois l’estimation dépasse le débit binaire de ce niveau supérieur. Pour un niveau comparé à 5 Mbit/s, le passage au niveau supérieur exige une estimation supérieure à environ 7,1 Mbit/s. Le débit binaire comparé dépend du tampon : par défaut, le code source de hls.js utilise AVERAGE-BANDWIDTH, lorsque la liste de lecture le déclare, si au moins deux durées de segment sont en mémoire tampon et qu’aucune remise en mémoire tampon n’est prévue, et BANDWIDTH dans les autres cas. Il applique aussi d’autres vérifications, comme le temps prévu pour récupérer un segment. L’estimation est une moyenne mobile des téléchargements récents ; elle réagit donc avec retard à un réseau qui vient de se rétablir. Considérez ce résultat comme une condition sur l’estimation du lecteur, et non comme une vitesse de connexion garantie. Les facteurs sont les valeurs de configuration par défaut abrBandWidthFactor et abrBandWidthUpFactor ; les autres lecteurs appliquent leurs propres règles, alors vérifiez celles du lecteur que vous déployez.
Comment estimer le volume de diffusion pour un public ? Multipliez le débit binaire moyen de chaque rendu par le nombre de spectateurs qui le regardent pour obtenir le débit effectif, puis par la durée de visionnage pour obtenir le volume ; utilisez les valeurs maximales pour dimensionner la capacité face aux pointes. Par exemple, 1 000 spectateurs simultanés d’un rendu dont le débit moyen est de 3 Mbit/s nécessitent environ 3 Gbit/s de débit effectif en périphérie, soit environ 1,35 TB par heure. Ce chiffre décrit ce que les serveurs en périphérie envoient aux spectateurs. Il ne décrit pas le trafic de l’origine, qui dépend du nombre de requêtes auxquelles le CDN répond depuis son cache, et il exclut le surcoût de HTTP, TCP et IP, absent des définitions du débit binaire HLS. Les spectateurs se répartissent aussi entre les niveaux de l’échelle de rendus ; la part de chaque rendu issue des statistiques du lecteur donne donc un chiffre plus précis que l’hypothèse où tout le monde regarde le rendu le plus élevé.
Jusqu’où faut-il abaisser le débit du rendu le plus bas ? Pour iOS, la spécification de création HLS d’Apple exige qu’une liste de lecture multivariante diffusée sur les réseaux mobiles contienne une variante dont le débit maximal BANDWIDTH est inférieur ou égal à 192 kbit/s. Incluez une telle variante de secours pour les spectateurs sur réseau mobile utilisant des appareils iOS ; la spécification n’en fait pas une règle générale pour les autres plateformes.

Estimez la bande passante globale lorsque vous dimensionnez la capacité du CDN et construisez une échelle de rendus adaptative. Les rendus dont le débit dépasse le débit effectif disponible des spectateurs provoquent des interruptions, tandis que des débits trop prudents réduisent la qualité.

Transloadit produit les rendus et les listes de lecture que décrivent ces chiffres. Le Robot /video/encode encode un rendu par Step, avec les préréglages hls/ et dash/ à résolutions fixes, et le Robot /video/adaptive regroupe ces Steps dans une sortie HLS, MPEG-DASH ou CMAF et génère les fichiers de manifeste et de liste de lecture. Votre échelle de rendus correspond donc à l’ensemble des Steps utilisant /video/encode que vous transmettez à /video/adaptive. Tout réglage d’un préréglage, y compris le débit binaire, peut être remplacé au moyen du paramètre ffmpeg, et le paramètre segment_duration du Robot /video/adaptive définit la durée des segments.

Le tableau des préréglages indique VBR pour les préréglages hls/ et dash/, sans valeur de débit binaire, et les pages des Robots ne précisent pas comment sont calculés les attributs de bande passante dans la liste de lecture générée. Examinez la liste de lecture générée pour relever les valeurs déclarées et vérifiez-les par rapport aux tailles des segments avant de les utiliser dans vos estimations de capacité.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que la bande passante vidéo ?

Comment fonctionne la bande passante vidéo

Points clés

Quand la bande passante vidéo est importante

Comment Transloadit aide à gérer la bande passante vidéo

Références

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