Le streaming utilise-t-il la même quantité de bande passante que le téléchargement?
En supposant que le contenu soit de la même qualité (ceteris paribus), le contenu multimédia en continu (c'est-à-dire la vidéo, l'audio) utilise-t-il la même quantité de bande passante que son téléchargement?
Disons que je devais télécharger un film HD d'Amazon ou le diffuser, s'agirait-il d'une utilisation équivalente de la bande passante?
Ce n'est souvent pas équivalent.
Les fournisseurs de streaming utilisent des protocoles, tels que DASH , pour ajuster de manière dynamique la qualité du film à la disponibilité de la bande passante de l'utilisateur et à la qualité souhaitée. Ensuite, les serveurs peuvent limiter votre connexion afin que vous puissiez mettre en mémoire tampon une certaine quantité (environ 10 secondes, peut-être 30 ou une minute) et que vous n'obteniez ensuite que la quantité de bande passante requise pour vous transmettre le contenu en temps réel. L’optimisation est évidente du point de vue du fournisseur, car elle répartit la bande passante plus équitablement entre les utilisateurs et évite en outre que les données soient transférées en vain (par exemple, lorsque l’utilisateur regarde un film 480p pendant 10 minutes, sans limitation de durée et avec une liaison descendante commune, il est probable que beaucoup plus que ce qui est déjà téléchargé, mais ensuite gaspillé si les utilisateurs arrêtent de regarder la vidéo).
La quantité de data transférée est la même. Toutefois, la transmission en continu peut prendre plus de temps, car le fournisseur peut limiter le transfert de données au débit requis pour fournir le contenu avec une qualité donnée en temps réel.
Dailymotion est l’un des fournisseurs qui limite les connexions. Depuis un serveur avec une connexion symétrique d’au moins 100 Mbit/s, on constate le comportement suivant¹:
youtube-dl http://www.dailymotion.com/video/xhc3zz_long-distance-calling-into-the-black-wide-open_music
[dailymotion] xhc3zz: Downloading webpage
[dailymotion] xhc3zz: Extracting information
[dailymotion] xhc3zz: Downloading embed page
[download] Destination: LONG DISTANCE CALLING - ' Into The Black Wide Open '-xhc3zz.mp4
[download] 5.8% of 51.99MiB at 203.89KiB/s ETA 04:06
Le taux est bien inférieur à ce qui serait possible (et est atteint avec d'autres fournisseurs). De plus, si vous essayez différents supports, vous constaterez que le débit dépend fortement de la vidéo individuelle: une vidéo fullhd se télécharge facilement avec> 1 Mo/s, tandis qu'un clip vidéo de ce type reste autour de 200 Ko/s ou moins. .
Pour résumer le tout et dissiper certaines incompréhensions éventuelles: Certains fournisseurs peuvent limiter le téléchargement en streaming, via leur application cliente (par exemple, youtube avec leur lecteur html5 ou vidéo flash) ou par serveur. S'ils ne vous limitent pas par serveur, le téléchargement consomme plus de bande passante, car la limitation de débit éventuellement appliquée par l'application cliente lors de la lecture en continu n'a pas lieu. C'est le cas principal lorsque la bande passante consommée est différente de la question d'origine.
- Je suis conscient que c'est une sorte de preuve anectodale - j'ai cependant observé ce comportement de manière constante.
En supposant que nous parlons de la même qualité (sans limitation, saut de trame ou flux de qualité inférieure), alors, au mieux, les flux utiliseront la même quantité de bande passante qu'un téléchargement, bien que cela puisse être fait à un moment/à un débit plus pratique pour le fournisseur. Cela pourrait également prendre plus de bande passante en fonction de la compression de la vidéo - la plupart du temps, l’ensemble de l’image n’est pas envoyé, mais simplement le changement (ou delta) entre les images. Cela signifie que plus il y a d'histoire (c'est-à-dire que vous utilisez cette teinte de bleu du pixel X dans l'image Y), moins il faut en envoyer. Normalement, cela ne s'affiche pas beaucoup, mais lorsqu'un flux est suspendu/interrompu pour une raison quelconque, cet "historique" est perdu et doit être retransmis, ce qui augmente la bande passante, alors qu'il peut être repris avec un téléchargement. à la "pause", et supposons que le récepteur dispose déjà de cette information. La même chose peut être utilisée pour l'audio, en particulier lorsqu'il n'y a pas de tarif fixe (c'est-à-dire FLAC au lieu de mp3)
Sauter (sauter, remonter, etc.) pourrait également affecter l'utilisation - passer au-delà de la mémoire tampon réduirait la quantité de bande passante utilisée par un flux, mais toute remontée l'augmenterait. De plus, il y aurait une interruption, ce qui entraînerait une utilisation accrue (voir ci-dessus), et toute sorte d'aperçu miniature tel que ce que l'utilisation de youtube et de Netflix augmenterait également légèrement la bande passante.
Dernière remarque: compression: cela pourrait être fait pour les téléchargements, mais pas tellement pour les flux - la mise en garde étant que la plupart des vidéos sont déjà compressées, il n'y aurait donc pas grand chose à gagner ici (même si des gains pourraient être réalisés dans le format ultra). haute résolution/département qualité).
Le streaming utilise moins de bande passante, surtout si les conditions du réseau sont mauvaises, mais cela a un prix .
La question en litige est celle des données à envoyer. Dans un modèle de téléchargement, toutes les données doivent parvenir au client, dans le bon ordre, quoi qu'il en soit . Si les conditions du réseau sont mauvaises et que certaines données ne parviennent pas au client, elles doivent être renvoyées, ce qui augmente l'utilisation de la bande passante. Si certaines données arrivent en panne, elles doivent être remises en ordre avant d'être présentées, ce qui diminue la réactivité.
Dans un modèle de diffusion en continu, il est acceptable que certaines données ne parviennent pas au client . Si vous diffusez un film en streaming et qu’une image n’y parvient pas, vous pouvez simplement l’ignorer et passer à autre chose, pour ne pas utiliser de bande passante supplémentaire lors des renvois. Si certains cadres arrivent en panne, ne jouez que ceux qui avancent; un blip momentané n'aura pas d'importance, ce qui augmente la réactivité. Cependant, cela signifie également que vous ne recevez pas nécessairement toutes les données: tout ce que vous voyez est celui qui est arrivé au 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 souhaitez l’archiver et/ou éventuellement l’afficher plusieurs fois, téléchargez-le afin d’obtenir tout. Si vous ne prévoyez pas d'archiver ou si vous ne prévoyez que de consulter les données une fois, continuez et diffusez en continu. vous ne remarquerez probablement pas la différence lors d'une seule visualisation, et si le réseau est suffisamment dégradé pour que vous le remarquiez, le téléchargement serait encore pire.
Si vous demandez vraiment "bande passante" (octets/s) et non "données totales" (octets), la question cruciale est: pendant quelle période de temps? Si nous supposons que l'utilisateur regarde la vidéo en entier et que le même codec/qualité, etc. est renvoyé, et ignore le petit temps système des demandes/réponses en streaming, le total des données renvoyées est égal.
Maintenant, quelle est la bande passante? Il y a deux façons de comprendre votre question:
Bande passante pendant le temps nécessaire au téléchargement. Pour le streaming, vous devriez voir des pointes de bande passante élevée (quand le prochain bloc est demandé) qui reviennent à zéro pendant que vous regardez ce morceau jusqu'à ce que vous soyez presque à 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 pour, disons, 10 minutes, qui descend à zéro dès que la vidéo entière est téléchargée. Si vous arrêtez le test maintenant, la bande passante pour le téléchargement est évidemment plus élevée car elle limite votre liaison descendante jusqu'à la fin.
Bande passante pendant le visionnage de la vidéo. La durée de visionnage de la vidéo est la même pour le streaming et le téléchargement, à condition que les deux commencent à regarder immédiatement. La taille totale des données est la même. Comme la bande passante est constituée de données à la fois, il en va de 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", il est de 40 dans la première unité de temps, alors que pour le "streaming", il est de 20 pendant les premières unités de temps (pour obtenir un gros morceau initial) et ensuite deux fois 10 pour les deux morceaux supplémentaires. Notez que si la bande passante est tracée sur l'axe des ordonnées, la zone située sous chacun des deux graphiques correspond aux données (octets). Si vous intégrez octets/durée, vous obtenez des octets.
Ils ne sont pas comparables.
Pour la première instance, l'encodage optimal pour l'affichage local est différent de l'encodage optimal pour l'affichage en continu.
Parlons de l'encodage vidéo.
Dans la plupart des formats de codage vidéo, il existe généralement deux types d’images:
- Trame intra-codée (I-Frame) - ce sont des trames intégralement transférées. Cette trame peut être décodée sans connaître la moindre trame. Un cadre intra-codé est essentiellement une image statique. Les codeurs les généreraient lors de transitions soudaines. Celles-ci sont moins efficaces à compresser.
- Image prédite (image P) ou image bi-prédite (image B) - Il s'agit d'images qui stockent uniquement les différences entre les images. Elles ne peuvent être décodées que si le téléspectateur connaît également les images précédentes et/ou ultérieures. Ce sont beaucoup plus efficaces pour compresser.
Le codage pour la visualisation locale peut tirer parti du fait que le disque rapide cherche à utiliser davantage de trames P et B, tandis qu'une vidéo codée pour une diffusion en continu efficace doit coder une trame I plus redondante tout au long de la vidéo, même en l'absence de transitions soudaines. recherche aléatoire.
En outre, il existe deux types de diffusion en continu. Vous pouvez diffuser en continu un flux pré-enregistré (la plupart des vidéos Youtube) et des flux d'événements en direct (par exemple, Youtube Live). En raison de la latence requise, la diffusion en direct d'événements en direct ne peut tirer parti des techniques d'encodage avancées qui prennent un temps long ou imprévisible, alors qu'un flux préenregistré peut prendre autant de temps que nécessaire.
La vidéo en streaming est également généralement codée avec un débit binaire constant (CBR). Pour une même taille cible, une vidéo à débit binaire variable (VBR) aura généralement une qualité supérieure à celle d'une vidéo CBR. Inversement, une vidéo VBR est plus petite pour la même qualité d’une vidéo CBR. Un protocole de streaming adaptatif comme DASH a un débit adaptatif (ABR), qui est un compromis entre CBR et VBR. ABR permet au spectateur de s’adapter aux changements de la bande passante du réseau. Avec une bande passante constante et constante, ABR est plus ou moins la même chose que CBR.
Cela signifie que avec la même qualité et la même expérience de visionnage , vous pouvez coder la vidéo pour une visualisation locale plus efficacement que la vidéo en streaming, et vous pouvez coder une vidéo pour des flux préenregistrés plus efficacement que les flux en direct.
Ensuite, il y a aussi une surcharge dans le protocole de streaming. Un téléchargement HTTP normal peut utiliser un codage de transfert fragmenté pour télécharger le fichier entier avec un temps système très minime. Un téléchargement en streaming devra négocier le morceau et la qualité du morceau à transférer. Dans le grand schéma des choses, la surcharge du protocole de transfert est relativement mineure.
Globalement, pour la même quantité de vidéo visionnée, la vidéo en streaming devrait prendre plus de bande passante. Le principal avantage du streaming, en termes d'utilisation de la bande passante, est qu'il peut être économisé par les personnes qui téléchargent mais ne regardent pas la vidéo en entier, ce qui peut représenter une économie très importante.
La réponse est "ça dépend".
La réponse est NON, pour les fournisseurs qui hébergent des vidéos en général. Les fournisseurs à moitié décents qui diffusent de la vidéo en continu contrôlent le taux afin de garantir une lecture fluide et une bande passante optimale pour le plus grand nombre de personnes possible. Donc, même si vous avez beaucoup de bande passante, il peut décider de ne vous donner que 5 Mbit et avoir l’air tout à fait décent.
Si vous effectuez un téléchargement HTTP, alors TCP algorithmes de contrôle du débit entrent en jeu pour vous assurer de saturer l'une ou les deux extrémités de la connexion ou tout autre élément intermédiaire. Donc, si vous aviez 100 Mbits disponibles, il utilisera tout ce que vous pouvez obtenir ou près de 100 Mbits.
Cela suppose bien entendu qu’aucune qualité de service ne se produit entre le client et le serveur.
Votre question est si vague que je pourrais également faire en sorte que, dans certaines configurations naïves, la réponse soit également OUI (avec hypothèses), les largeurs de bande sont identiques. Pour ce faire, déposez simplement le fichier sur votre serveur Web de base et ouvrez-le avec votre navigateur de sorte qu'un spectateur se mette au travail. Ou bien, intégrez la vidéo sur votre serveur Web de base et jouez-la dans le navigateur et utilisez une bande passante identique avec l'hypothèse suivante ... aucun autre utilisateur, personne d'autre ne partageant le réseau avec vous ... aucun autre facteur en jeu susceptible d'altérer votre bande passante.
Gardez à l'esprit que lorsque vous téléchargez un fichier à partir d'un site Web, puis que vous le téléchargez à nouveau, la bande passante entre le premier et le deuxième téléchargement peut varier. Cela est simplement dû au fait que la charge sur le serveur peut changer et que la congestion sur le réseau et les chemins réseau peuvent changer.
Donc là vous l'avez ... ça dépend.
Du point de vue du réseau, le "téléchargement" et le "streaming" sont des services différents, cela s'appelle "profil de trafic"
Pour le service de diffusion en continu, le réseau doit fournir un débit minimal constant (techniquement, "bande passante" signifie quelque chose de différent), le service de diffusion en continu est sensible aux interruptions et à la gigue. Il ne nécessite pas que le débit réseau maximal, le délai ou la latence ne soit pas critique.
Du point de vue de l'utilisateur final, cela signifie que: La vidéo doit être fluide, sans interruption ni interruption. Peu importe que la vidéo commence quelques secondes plus tôt ou plus tard.
Le "téléchargement" nécessite généralement le débit maximum du réseau, le téléchargement doit être terminé aussi rapidement que possible. Les retards, les interruptions et la gigue ne sont pas critiques.
Un réseau peut fournir davantage de profils de trafic complètement différents. Par exemple, les services vocaux (appel téléphonique simple) nécessitent un débit très faible mais sont très sensibles aux retards (moins de 200 ms)
Le streaming utilise votre débit de téléchargement, vous pouvez donc le considérer comme un téléchargement. Votre question est un peu ambiguë quant à ce que vous considérez comme un téléchargement. Vous pouvez uniquement télécharger autant de téléchargements qu’ils peuvent et sont disposés à offrir. Donc, au final, si vous souhaitez comparer un téléchargement direct à partir de HTTP sur DASH (toujours HTTP), vous devez vérifier combien de téléchargements vous effectuez de chacun.
Donc, je suppose que la réponse est que cela pourrait utiliser le même montant ... ou moins ... ou plus. en fonction des serveurs et de la vitesse à laquelle ils vous servent.
Pour ajouter à d’autres réponses, ma réponse est: pas nécessairement .
Maintenant, en supposant que tout soit égal (pas de sélection automatique de la qualité, pas de limitation du serveur et/ou du FAI) ...
Bandwidth est généralement défini comme étant size_of_data divisé par total_time. (Techniquement, le terme "correct" est débit , mais je digresse).
Supposons que vous allez diffuser une vidéo de 2 000 secondes d'une taille de 60 Mo.
Avec la diffusion en continu, le programme de diffusion pourrait faire sa propre limitation de débit pour éviter le débordement de mémoire tampon. Ainsi, son en-tête de requête HTTP pourrait inclure un champ Range . La bande passante effective depuis le début du streaming jusqu'à la fin du streaming serait alors d'environ 60 Mo/2000 secondes = 30 Ko/s = 240 kbps.
Toutefois, si vous téléchargez la vidéo directement, vous obtenez jusqu'à la bande passante maximale de votre service Internet. En fonction d'autres utilisations au même moment, bien sûr. Ainsi, en supposant un service Internet de 6 Mbps, avec 50% de bande passante disponible, vous obtiendrez une bande passante de 3 Mbps pour le téléchargement de vidéos.
Le streaming est vraiment une façon de télécharger.
Lorsque vous regardez un film en streaming, votre lecteur multimédia en télécharge des parties, vous les montre et supprime les parties affichées du fichier à la volée.
Généralement, lorsque vous téléchargez un fichier, vous attendez la fin du téléchargement et commencez seulement à le regarder. Mais il existe des lecteurs multimédias capables de vous montrer la partie téléchargée du fichier et de mettre automatiquement en pause et d’attendre que d’autres fichiers soient téléchargés. Un peu comme la diffusion en continu, mais sans supprimer le fichier.
Techniquement, lorsque l’important est la quantité totale de données transférées, le mode de téléchargement n’importe pas, mais la différence entre le fichier que vous téléchargez et le fichier que votre lecteur multimédia télécharge pour vous en tant que flux. Il peut s’agir des mêmes fichiers, ce qui signifie la même bande passante dans les deux cas.
Les sites de média en continu codent généralement le contenu de leur contenu pour obtenir un débit binaire inférieur à celui d'un disque acheté en magasin. Mais vous pouvez regarder un film de votre ordinateur de bureau sur un ordinateur portable via un réseau Wi-Fi en utilisant la fonction de partage de fichiers de votre système d’exploitation. Le volume de trafic utilisé sera pratiquement identique à celui du visionnage sur le bureau (en lecture, en octets). conduire). Techniquement, il s'agirait d'une diffusion en continu, car vous regardez un film alors que certaines parties sont en permanence téléchargées et ignorées.
Donc, la réponse est cela dépend absolument de la taille des deux fichiers - diffusés via le lecteur multimédia et téléchargés sur le disque.