Le streaming utilise-t-il la même quantité de bande passante que le téléchargement?

75

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?

stemie
la source
2
Dépend du protocole et du codec: par exemple, téléchargement via http et flux via rtmp ou h264 vs vp6. OMI, cette question est trop large compte tenu du nombre de méthodes de compression et de transmission de données à comparer.
zamnuts
Juste pour clarifier votre question. Par bande passante, vous parlez de débit de données et non de taille de fichier (film)?
Matt H
Un avantage du téléchargement par streaming (ce qui est techniquement un téléchargement mais pour un usage unique) est que vous pouvez consommer le contenu autant de fois que vous le souhaitez sans avoir à dépenser votre bande passante à chaque fois. Certains lecteurs multimédias peuvent même lire des vidéos que vous êtes en train de télécharger (pas complètement téléchargées), ce qui vous donne l'impression de diffuser en continu avec le téléchargement.
ADTC
3
Oui, je parle de débit de données. La raison pour laquelle j'ai posé la question est en désaccord avec ma sœur et lorsque je regarde en ligne, tout ce que je pouvais trouver était des réponses vagues à partir de réponses yahoo. Je me rends compte qu'il y a beaucoup de variables dont cela dépend mais je pensais que ça valait au moins la peine de demander.
stemie
2
"Dans les réseaux et les sciences informatiques, bande passante, bande passante réseau, bande passante de données ou bande passante numérique est une mesure du débit binaire des ressources de communication de données disponibles ou consommées, exprimé en bits par seconde ou en multiples de celui-ci (bit / s, kbit / s , Mbit / s, Gbit / s, etc.) - wikipedia.org/wiki/Bandwidth_(computing) "
mardi

Réponses:

43

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, par la suite, vous n’obtenez que la quantité de bande passante requise pour vous transmettre le contenu en temps réel. Il s’agit là d’une optimisation é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 aucune limitation ni limitation). 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 données 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 observe 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). En outre, 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 MiB / s, tandis qu'un clip vidéo de ce type reste à 200 Ki / 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 en fonction du serveur, le téléchargement consomme plus de bande passante, car la limitation de débit éventuellement appliquée par l'application cliente pendant 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.


  1. Je suis conscient qu'il s'agit d'une sorte de preuve anectodale - j'ai cependant observé ce comportement de manière constante.
Jonas Schäfer
la source
3
@Psycogeek Youtube est l’un des exemples utilisant DASH (si ce commentaire n’a pas de sens, lisez la partie introductive de l’article que j'ai lié). Cela implique que le lecteur utilisé par le client doit de toute façon demander les morceaux de vidéo séquentiels. Il est tout à fait naturel de cesser de demander plus de morceaux si le joueur ne tourne pas. Les téléchargeurs tels que youtube-dlcontinueront simplement à demander plus de morceaux jusqu'à ce que la vidéo soit entièrement téléchargée. La diffusion en continu avec DASH implique donc un peu plus de temps système, mais elle en vaut probablement la peine (pour l'utilisateur et le fournisseur) et est négligeable.
Jonas Schäfer
1
En supposant que les mêmes données et le codage et la définition sont utilisés (voir le commentaire psychogeek) téléchargement va utiliser plus de bande passante totale. Le téléchargement de la vidéo se fera presque certainement avec TCP, tandis que la diffusion en continu sera UDP ou une approche similaire de livraison non garantie. Ainsi, TCP aura plus d’acks envoyés au minimum, et puisque vous allez probablement perdre ou corrompre au moins quelques paquets, l’approche TCP sera en réalité plus chargée en téléchargement (car elle récupérera également les paquets perdus). Bien que la différence soit très minime par rapport à la taille du téléchargement, il s’agit donc d’une tâche plutôt académique.
dimanche
2
@dsollen: à moins qu'un expéditeur UDP ne laisse simplement les paquets circuler sans se soucier de savoir si le destinataire souhaité existe toujours, UDP et TCP nécessiteront des accusés de réception périodiques; dans les deux cas, les accusés de réception ne représenteront qu'une très petite partie du trafic total. En outre, le formatage des données de manière à ce que chaque paquet puisse être compris même si le paquet précédent n’est pas reçu implique généralement une surcharge de niveau supérieure à celle qui serait requise pour TCP.
Supercat
7
Si cette réponse était suffisamment répétée, je voterais cette réponse à la baisse: cela ne répond pas à la question, la phrase clé étant "qualité identique". Lorsqu'un fournisseur baisse de qualité, ce n'est pas ceteris paribus .
zamnuts
1
@zamnuts, postez-en un meilleur et laissez la communauté décider. FWIW, c’est un peu les pommes et les oranges lorsque vous considérez que le fournisseur a décidé de faire baisser la qualité, mais je ne pense pas que la réponse serait complète sans elle.
Paqogomez
19

En supposant que nous parlons de la même qualité (c'est-à-dire pas de flux de limitation, de saut de trame ou 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 la 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 destinataire a déjà 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.-à-d. 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é).

utilisateur2813274
la source
7

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 concerne les 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 arrive . 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, afin de 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.

Le Spooniest
la source
Voulez-vous dire que les services de streaming utilisent UDP au lieu de TCP pour autoriser intentionnellement les données perdues?
FreeAsInBeer
1
@FreeAsInBeer: Oui. TCP intègre un ensemble de mécanismes de fiabilité et d’autres fonctionnalités très utiles pour la plupart des applications imaginables. Mais les cas d'utilisation existent où il y a des choses encore plus importantes que la fiabilité, et le streaming en est un: il est plus important de montrer le bon cadre au bon moment que de montrer chaque cadre. Le jeu en ligne est un autre exemple où UDP est populaire, pour les mêmes raisons: arrêter l'action pour reconstruire la trace des états des joueurs est pire que de devoir corriger pour un abandon occasionnel.
Le Spooniest
En réalité, de nombreux systèmes diffusent les données via TCP et dans la mémoire tampon côté client. Pour le streaming d'un film, la latence n'est pas critique. Il n’ya aucun inconvénient pour l’utilisateur si certaines des trames restent dans la mémoire tampon pendant une minute avant de pouvoir les afficher. Mais pour les utilisations interactives telles que la vidéoconférence, la latence est essentielle.
Kasperd
1
kasperd: À proprement parler, ce n'est pas du streaming. D'autres réponses ont mentionné des services qui téléchargent, mais commencent à jouer avant la fin du téléchargement, et c'est ce que font les systèmes que vous décrivez.
Le Spooniest
+1 pour la réponse la moins déroutante (à ce jour) dans ce fil.
Cosmic Ossifrage
5

Si vous demandez réellement "bande passante" (octets / s) et non "données totales" (octets), la question cruciale est la suivante: 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:

  1. Bande passante pendant le temps nécessaire pour que le téléchargement soit terminé. Pour le streaming, vous devriez voir des pointes de bande passante élevée (lorsque 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.

  2. 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 regardent immédiatement. La taille totale des données est la même. Puisque la bande passante est constituée de données par heure, 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 y, la zone sous chacune des deux graphiques correspond aux données (octets) -si vous intégrez octets / heure au fil du temps, vous obtenez octets.

mb21
la source
4

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:

  1. Trame intra-codée (I-Frame) - Il s’agit de trames qui sont intégralement transférées. Cette trame peut être décodée sans qu’aucune autre trame ne soit connue. 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.
  2. 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 le long de la vidéo entière, 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 tel que DASH a un débit adaptatif (ABR), 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.

Tout 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 l'encodage de transfert en bloc pour télécharger l'intégralité du fichier, ce qui entraîne une surcharge 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 une plus grande quantité 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.

Lie Ryan
la source
1

La réponse est "ça dépend".

La réponse est NON, pour les fournisseurs qui hébergent de la vidéo 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, les algorithmes de contrôle du débit TCP 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 tellement vague que je pourrais aussi 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. 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 les premier et deuxième téléchargements 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.

Matt H
la source
"la bande passante entre le premier et le deuxième téléchargement peut varier", mais le téléchargement de la même quantité de données est sûr, même si l'une prend plus de temps que l'autre / les conditions du réseau ont changé.
stemie
@ stemie, ça va être proche. Différents protocoles ajoutent une surcharge de protocole. Mais s'il n'y a pas eu de transcodage ni de changement de qualité / débit pendant le processus de streaming, il devrait en principe être la même quantité de données vidéo.
Matt H
1

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 minimum 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: 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)

Wernfried Domscheit
la source
0

Pour ajouter aux 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 fournisseur de services Internet) ...

La bande passante est généralement définie comme étant size_of_data divisé par total_time. (Techniquement, le terme "correct" est débit , mais je m'éloigne du sujet).

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 peut faire sa propre limitation de débit pour empêcher le débordement de mémoire tampon. Ainsi, son en-tête de requête HTTP peut inclure un champ Range . La bande passante effective depuis la diffusion en continu jusqu'à la fin de la diffusion serait alors d'environ 60 Mo / 2000 secondes = 30 Ko / s = 240 kbps.

Cependant, si vous téléchargez la vidéo pur et simple, vous aurez 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.

Pepoluan
la source
0

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

La réponse est donc que cela dépend absolument de la taille des deux fichiers - diffusés via un lecteur multimédia et téléchargés sur le disque.

utilisateur1306322
la source
0

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 voulez comparer un téléchargement direct à partir de HTTP sur DASH (toujours sur HTTP) par exemple, il vous faudra 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.

MinusFour
la source
-2

Oui c'est l'équivalent. Download = Vous ne le téléchargez qu'une seule fois et il reste sur votre ordinateur. Stream = Vous téléchargez temporairement "quelque chose" sur votre ordinateur.

Tiago Ribeiro
la source
Il existe une différence entre la quantité de données transférées et la bande passante utilisée.
Jonas Schäfer
bien sur mon androïde regarder une vidéo à partir d'un flux ou le télécharger a la même utilisation des données
Tiago Ribeiro
@JonasWielicki Un sage a dit un jour: "La quantité de données transférées est la même". Bien sûr, la quantité de bande passante utilisée varie, en raison du fait que la vitesse de transfert est plus lente dans le temps.
Nenotlep
1
C'est en fait la bonne réponse dans beaucoup de cas. Souvent, dans de nombreux cas, les mêmes ressources et protocoles sont utilisés pour la diffusion et le téléchargement. Si vous souhaitez lire une ressource sur HTTP, le téléchargement est différent du fait que vous le lisez au fur et à mesure de son téléchargement. Bien sûr, il existe des optimisations pour la diffusion en continu et différents protocoles susceptibles de modifier votre débit au fur et à mesure que vous diffusez, mais je ne pense pas que ce soit le cœur de la question posée. (Ils méritent cependant d'être mentionnés.)
Brad Le