Supposons que le contenu soit de la même qualité (ceteris paribus), le streaming de médias (c'est-à-dire vidéo, audio) utilise-t-il la même quantité de bande passante que le téléchargement ?
Imaginons que je télécharge un film HD sur Amazon ou que je le streame, serait-ce une utilisation équivalente de la bande passante ?
Il est souvent pas équivalent.
Les fournisseurs de streaming utilisent des protocoles, tels que DASH, pour ajuster dynamiquement la qualité du film en fonction de la disponibilité de la bande passante des utilisateurs et de leurs préférences en matière de qualité. Ensuite, les serveurs peuvent limiter le débit de votre connexion de sorte que vous puissiez mettre en mémoire tampon une certaine quantité (quelque chose comme 10 secondes, peut-être 30 ou une minute entière) et ensuite vous ne recevez que le débit nécessaire pour vous transmettre le contenu en temps réel. Il s'agit d'une optimisation évidente du point de vue du fournisseur, car elle répartit plus équitablement la bande passante entre les utilisateurs et évite en outre que des données soient transférées en vain (par exemple, lorsque l'utilisateur regarde un film en 480p pendant 10 minutes, sans limitation de débit et avec un débit descendant commun, il est probable que beaucoup plus a déjà été téléchargé, mais ensuite gaspillé si l'utilisateur arrête de regarder la vidéo).
La quantité de données transférées est la même. Mais cela peut prendre plus de temps avec le streaming, car le fournisseur peut limiter le débit des données avec le taux nécessaire pour fournir le contenu dans une qualité donnée en temps réel.
Dailymotion est l'un des fournisseurs qui limitent les connexions. À partir d'un serveur avec une connexion symétrique d'au moins 100Mbit/s, nous observons le comportement suivant¹:
youtube-dl http://www.dailymotion.com/video/xhc3zz_long-distance-calling-into-the-black-wide-open_music
[dailymotion] xhc3zz: Téléchargement de la page web
[dailymotion] xhc3zz: Extraction des informations
[dailymotion] xhc3zz: Téléchargement de la page d'intégration
[téléchargement] Destination: LONG DISTANCE CALLING - ' Into The Black Wide Open '-xhc3zz.mp4
[téléchargement] 5.8% de 51.99MiB à 203.89KiB/s ETA 04:06Le débit est bien en dessous de ce qui serait possible (et est atteint avec d'autres fournisseurs). De plus, si vous essayez différents contenus, vous constaterez que le débit dépend fortement de la vidéo individuelle : une vidéo fullhd se télécharge facilement avec > 1MiB/s, tandis qu'une vidéo musicale comme celle-ci reste autour ou en dessous de 200KiB/s.
Pour résumer et dissiper certains malentendus possibles : Certains fournisseurs peuvent limiter le débit de téléchargement pendant le streaming, par le biais de leur application cliente (par exemple youtube avec leur lecteur vidéo html5 ou flash) ou par des moyens serveur. S'ils ne vous limitent pas par des moyens serveur, le téléchargement consommera alors plus de bande passante, car la limitation de débit appliquée éventuellement par l'application cliente pendant le streaming ne se produit pas. C'est le cas principal lorsque la consommation de bande passante est différente par rapport à la question initiale.
En supposant que nous parlons de la même qualité (c'est-à-dire pas de limitation, de saut d'images ou de flux de moindre qualité), alors au mieux les flux prendront la même quantité de bande passante qu'un téléchargement, bien que cela pourrait être fait à un moment/tarif plus pratique pour le fournisseur. Cela pourrait également nécessiter plus de bande passante en fonction de la compression vidéo - la plupart du temps, l'image entière n'est pas envoyée, mais simplement le changement (ou delta) entre les images. Cela signifie que plus il y a d'historique (c'est-à-dire utiliser cette nuance de bleu du pixel X dans l'image Y), moins il y a besoin d'envoyer. Cela ne se produit normalement pas fréquemment, mais lorsque qu'un flux est mis en pause/interrompu pour une raison quelconque, cet "historique" est perdu et devra être retransmis, augmentant ainsi la bande passante, tandis qu'avec un téléchargement, il peut reprendre à l'endroit de la "pause", et on peut supposer que le récepteur possède déjà cette information. Cela peut aussi être utilisé pour l'audio, surtout là où il n'y a pas de taux fixe (c'est-à-dire FLAC au lieu de mp3)
Le fait de sauter (avancer rapidement, rembobiner, etc.) pourrait également affecter l'utilisation - avancer au-delà du tampon réduirait la quantité de bande passante utilisée par un flux, mais tout rembobinage l'augmenterait. De plus, il y aurait une interruption, ce qui causerait une utilisation accrue (voir ci-dessus), et tout type de "prévisualisation miniature" comme celui que youtube et netflix utilisent augmenterait également légèrement la bande passante.
Dernière remarque : compression : cela pourrait être fait pour les téléchargements, mais pas autant pour les flux - la réserve étant que la plupart des vidéos sont déjà compressées, donc il n'y aurait pas grand chose à gagner ici (bien qu'il pourrait y avoir de la place pour des gains dans le département de l'ultra-haute résolution/qualité).
Le streaming utilisera moins de bande passante, surtout si les conditions réseau sont mauvaises, mais cela a un prix.
La question porte sur les données à envoyer. Dans un modèle de téléchargement, toutes les données doivent parvenir au client, toutes dans le bon ordre, peu importe quoi. Si les conditions réseau sont mauvaises et que certaines parties des données n'atteignent pas le client, elles doivent être renvoyées, ce qui augmente l'utilisation de la bande passante. Si certaines données arrivent dans le désordre, elles doivent être remises en ordre avant d'être présentées, ce qui diminue la réactivité.
Dans un modèle de streaming, ce n'est pas grave si certaines données n'atteignent pas le client. Si vous regardez un film en streaming et qu'une image n'arrive pas, vous pouvez simplement la sauter et continuer, donc vous n'utilisez pas de bande passante supplémentaire pour les renvois. Si certaines images arrivent dans le désordre, il suffit de jouer celles qui avancent; un moment d'interruption n'aura pas d'importance, ce qui accroît la réactivité. Cependant, cela signifie également que vous n'obtenez pas nécessairement toutes les données : ce que vous voyez est ce qui est arrivé du premier coup.
Si vous devez choisir entre les modèles, choisissez en fonction de ce que vous voulez faire avec les données. Si vous voulez les archiver et/ou les consulter plusieurs fois, téléchargez-les pour être sûr de tout obtenir. Si vous n'avez pas l'intention de les archiver, ou que vous prévoyez de consulter les données une seule fois, alors allez-y en streaming; vous ne remarquerez probablement pas la différence lors d'une seule visualisation, et si les conditions réseau sont assez mauvaises pour le remarquer, alors le téléchargement serait encore pire.
Si vous demandez vraiment la "bande passante" (octets/seconde) et non les "données totales" (octets), la question cruciale est la suivante : pendant quelle période de temps ? En supposant que l'utilisateur regarde l'intégralité de la vidéo et que le même codec/qualité etc. est renvoyé, en ignorant le léger surdébit des requêtes/réponses de streaming, alors les données totales renvoyées sont égales.
Maintenant, quelle est la bande passante ? Il y a deux façons de comprendre votre question :
Bande passante pendant le temps nécessaire jusqu'à ce que le téléchargement soit terminé. Pour le streaming, vous devriez voir des pics de bande passante élevés (lorsque le prochain morceau est demandé) qui retournent à zéro pendant que vous regardez ce morceau jusqu'à ce que vous approchiez de la fin du morceau et qu'il y ait à nouveau un pic de bande passante. Pour le téléchargement, vous devriez voir une bande passante très élevée pendant, disons, 10 minutes qui retombe à zéro dès que la vidéo entière est téléchargée. Si vous arrêtez l'expérience à ce stade, la bande passante pour le téléchargement est évidemment plus élevée car elle atteint le débit maximal de téléchargement jusqu'à la fin.
Bande passante pendant le temps où la vidéo est regardée. Le temps pendant lequel la vidéo est regardée est le même pour le streaming et le téléchargement, en supposant que les deux commencent à regarder immédiatement. La taille totale des données est également la même. Comme la bande passante est la quantité de données par unité de temps, elle est la même pour les deux scénarios.
Dans l'exemple ci-dessous, il y a toujours un total de 40 (unités de données) téléchargées. Mais pour le "téléchargement", c'est 40 lors de la première unité de temps, alors que pour le "streaming", c'est 20 pendant les premières unités de temps (pour obtenir un gros chunk initial) puis deux fois 10 pour les deux morceaux supplémentaires. Notez que tandis que la bande passante est représentée sur l'axe des y, la surface sous chacun des deux graphiques correspond aux données (octets) - si vous intégrez les octets/temps sur le temps, vous obtenez des octets.
Ils ne sont pas comparables.
Pour la première instance, le codage optimal pour une visualisation locale est différent du codage optimal pour une visualisation en streaming.
Parlons de l'encodage vidéo.
Dans la plupart des formats d'encodage vidéo, il y a généralement deux types de cadres :
L'encodage pour une visualisation locale peut profiter des recherches rapides sur le disque pour utiliser plus de cadres P et B, tandis qu'une vidéo encodée pour un streaming efficace devra encoder plus de cadres I redondants tout au long de la vidéo même en l'absence de transitions soudaines pour accommoder un déplacement aléatoire.
De plus, il existe deux types différents de streaming. Vous pouvez avoir le streaming d'un flux préenregistré (la plupart des vidéos Youtube) et les flux d'événements en direct (par exemple Youtube Live). En raison du besoin de latence, le streaming d'événements en direct ne peut pas profiter des techniques d'encodage avancées qui prennent beaucoup de temps ou un temps imprévisible, tandis qu'un flux préenregistré peut prendre le temps nécessaire pour s'encoder.
La vidéo diffusée est généralement encodée en débit binaire constant (CBR). Pour la même taille cible, une vidéo en débit binaire variable (VBR) aura généralement une qualité supérieure à une vidéo en CBR. Inversement, une vidéo VBR est plus petite pour la même qualité qu'une vidéo CBR. Un protocole de streaming adaptatif comme DASH a un débit binaire adaptatif (ABR), qui est un compromis entre CBR et VBR. L'ABR permet au spectateur de s'adapter aux changements de la bande passante du réseau. Avec une bande passante constante et cohérente, l'ABR est plus ou moins similaire au CBR.
Tout cela signifie que avec la même qualité et la même expérience de visionnage, vous pouvez encoder une vidéo pour une visualisation locale de manière plus efficace que pour une vidéo en streaming, et vous pouvez encoder une vidéo pour des flux préenregistrés de manière plus efficace que pour des flux en direct.
Ensuite, il y a aussi une surcharge dans le protocole de streaming. Un téléchargement HTTP régulier peut utiliser un encodage de transfert par morceaux pour télécharger le fichier entier, ce qui présente une surcharge très minimale. Un téléchargement en streaming devra négocier le morceau et la qualité du morceau à transférer. Dans l'ensemble, la surcharge du protocole de transfert est relativement mineure.
En général, pour la même quantité de vidéo regardée, la vidéo diffusée devrait finir par consommer une plus grande quantité de bande passante. L'avantage principal du streaming, en termes d'utilisation de la bande passante, est qu'il peut économiser de la bande passante pour les personnes qui téléchargent mais ne regardent pas la vidéo en entier, ce qui peut représenter une économie très significative.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
