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


En supposant que le contenu est de la même qualité (ceteris paribus), les médias en continu (par exemple, vidéo, audio) utilisent-ils la même quantité de bande passante que le téléchargement?

Disons que je devais télécharger un film HD à partir d'Amazon ou le diffuser, serait-ce l'utilisation équivalente de la bande passante?


74
2017-10-08 09:33


origine


Dépend du protocole et du codec: par ex. télécharger via http et diffuser via rtmp, ou h264 vs vp6. IMO cette question est trop large compte tenu de la quantité de méthodes de compression et de transmission de données à comparer. - zamnuts
Juste pour clarifier votre question. Par bande passante, vous faites référence au débit de données, pas à la taille du fichier (film)? - Matt H
Un avantage du téléchargement par streaming (qui est techniquement téléchargeable mais à usage unique) est que vous pouvez consommer le matériel 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 téléchargez actuellement (non entièrement téléchargées), ce qui donne l'impression de diffuser avec l'avantage du téléchargement. - ADTC
Oui, je fais référence au débit de données. La raison pour laquelle j'ai posé la question est d'avoir un désaccord avec ma soeur et quand je regarde en ligne, tout ce que je pouvais trouver était des réponses vagues de réponses yahoo. Je me rends compte qu'il y a beaucoup de variables dont cela dépend, mais j'ai pensé que c'était au moins une question à poser. - stemie
"Dans les réseaux informatiques et l'informatique, la bande passante, la bande passante réseau, la bande passante ou la bande passante numérique sont des mesures du débit binaire des ressources de communication de données disponibles ou consommées exprimées en bits par seconde ou multiples (bit / s, kbit / s) , Mbit / s, Gbit / s, etc.) - wikipedia.org/wiki/Bandwidth_(computing) " - stemie


Réponses:


Ce n'est souvent pas équivalent.

Les fournisseurs de streaming utilisent des protocoles, tels que TIRET, pour ajuster dynamiquement la qualité du film en fonction de la disponibilité de la bande passante et des souhaits de qualité des utilisateurs. Ensuite, les serveurs peuvent limiter votre connexion afin que vous puissiez mettre en mémoire un certain montant (environ 10 secondes, peut-être 30 ou une minute entière) et ensuite, vous obtenez uniquement la quantité de bande passante nécessaire pour obtenir le contenu en temps réel. Il s’agit là d’une optimisation évidente du point de vue du fournisseur, car il répartit la bande passante de manière plus équitable entre les utilisateurs et évite en outre le transfert de données en vain (par exemple, lorsque l’utilisateur regarde un film de 480p avec une liaison descendante commune, il est probable que beaucoup plus que cela est déjà téléchargé, mais ensuite perdu si les utilisateurs cessent de regarder la vidéo).

La quantité de Les données transféré est le même. Toutefois, le streaming peut prendre plus de temps, car le fournisseur peut limiter le transfert de données au taux requis pour fournir le contenu dans une qualité donnée en temps réel.

Dailymotion est l'un des fournisseurs qui limitent les connexions. Sur un serveur avec une connexion symétrique d'au moins 100 Mbit / s, nous voyons 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 très inférieur à ce qui serait possible (et réalisé avec d'autres fournisseurs). De plus, si vous essayez différents supports, vous constaterez que le taux 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 telle que celle-ci reste autour de 200Ki / s .

Pour résumer le tout et dissiper certains malentendus: Certains fournisseurs peuvent limiter votre téléchargement en streaming, via leur application cliente (par exemple, youtube avec leur lecteur html5 ou flash) ou par des moyens 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 pendant la diffusion n'a pas lieu. C'est le cas principal lorsque la bande passante consommée est différente par rapport à la question d'origine.


  1. Je suis conscient que c'est une sorte de preuve anectodale - j'ai cependant observé ce comportement de manière cohérente.

42
2017-10-08 10:20



@Psycogeek Youtube est l'un des exemples utilisant DASH (si ce commentaire n'a pas de sens pour vous, 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 blocs séquentiels de la vidéo. Faire le pas de là pour arrêter de demander plus de morceaux si le joueur ne court pas est tout simplement naturel. Des téléchargeurs tels que youtube-dl continuera simplement à demander plus de morceaux jusqu'à ce que la vidéo soit entièrement téléchargée. Ainsi, la diffusion en continu avec DASH entraîne un peu plus de frais généraux, mais cela en vaut probablement la peine (pour l'utilisateur et le fournisseur) et négligeable. - Jonas Wielicki
En supposant que le même encodage de données et la même définition soient utilisés (voir commentaire psychogeek) volonté utiliser plus de bande passante totale. Un téléchargement de la vidéo sera presque certainement effectué avec TCP, tandis que le streaming sera UDP ou une approche similaire non garantie. Ainsi, le protocole TCP aura plus de messages envoyés au minimum, et puisque vous perdrez ou corromprez probablement au moins quelques paquets, l’approche TCP sera également plus téléchargée (car elle récupérera également les paquets perdus). Bien que la différence soit très mineure par rapport à la taille du téléchargement, il s’agit donc essentiellement d’un travail académique. - dsollen
@dsollen: À moins qu'un expéditeur UDP ne laisse simplement les paquets circuler sans se soucier de savoir si le destinataire prévu existe toujours, UDP et TCP vont devoir tous deux recevoir des accusés de réception périodiques. Dans les deux cas, les accusés de réception vont représenter une très petite partie du trafic total. En outre, le formatage des données de telle sorte que chaque paquet puisse être compris, même si le paquet précédent n'est pas reçu, implique généralement un surcoût au-delà de ce qui serait requis pour le protocole TCP. - supercat
Je décrirais cette réponse si j'avais assez de rep: ça fait ne pas répondez à la question, la phrase clé étant "même qualité". Lorsqu'un fournisseur baisse la qualité, ce n'est pas toutes choses égales. - zamnuts
@zamnuts, alors postez-en un meilleur et laissez la communauté décider. FWIW, c'est un peu les pommes et les oranges quand on considère que le fournisseur a décidé des trempettes de qualité, mais je ne pense pas que la réponse serait complète sans elle. - paqogomez


En supposant que nous parlions de la même qualité (c.-à-d. Pas de limitation, de saut de trame ou de flux de qualité inférieure), les flux prendraient au mieux la même quantité de bande passante qu'un téléchargement, bien que cela puisse être fait à la fois plus pratique pour le fournisseur. Cela peut également prendre plus de bande passante en fonction de la compression de la vidéo - la plupart du temps, la totalité de l'image n'est pas envoyée, mais uniquement la modification (ou le delta) entre les images. Cela signifie que plus il y a d'historique (c'est-à-dire que cette teinte de bleu est utilisée à partir du pixel X dans l'image Y), moins il faut l'envoyer. Cela ne se déclenche pas normalement, mais lorsqu'un flux est 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 être repris. à la "pause", et a supposé que le récepteur a déjà cette information. La même chose peut être utilisée pour l'audio, en particulier là où il n'y a pas de taux fixe (à savoir FLAC au lieu de mp3)

Sauter (sauter, remonter, etc.) pourrait également affecter l'utilisation - le fait de dépasser le tampon réduirait la quantité de bande passante utilisée par un flux, mais toute réenroulement l'augmenterait. Il y aurait aussi une interruption, ce qui entraînerait une augmentation de l’utilisation (voir ci-dessus), et toute sorte de "prévisualisation de vignettes" comme ce que YouTube et Netflix utiliseraient pour augmenter légèrement la bande passante.

Dernière remarque: la 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 beaucoup à gagner (même si haute résolution / qualité département).


19
2017-10-08 14:21





Le streaming utilisera moins de bande passante, surtout si les conditions du réseau sont mauvaises, mais cela a un prix.

Les données à envoyer sont en cause. Dans un modèle de téléchargement, toutes les données doivent parvenir au client, le tout dans le bon ordre, peu importe. Si les conditions du réseau sont mauvaises et que certains bits de données n'atteignent pas le client, ils doivent être renvoyés, ce qui augmente l'utilisation de la bande passante. Si certaines données sont hors service, 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, c'est OK si certaines des données ne parviennent pas au client. Si vous diffusez un film en streaming et qu'une image ne s'y trouve pas, vous pouvez simplement l'ignorer et passer à la suite, afin de ne pas utiliser de bande passante supplémentaire lors du renvoi. Si certaines images sont hors d'usage, jouez simplement celles qui sont en avance. un choc momentané n'aura plus 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 ce qui s’est passé sur le 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 le consulter à plusieurs reprises, téléchargez-le pour être sûr de tout avoir. Si vous ne prévoyez pas d'archiver, ou si vous prévoyez de ne consulter les données qu'une seule fois, continuez et diffusez; vous ne remarquerez probablement pas la différence sur une seule visualisation, et si les conditions du réseau sont suffisamment mauvaises pour que vous le remarquiez, alors le téléchargement serait encore pire.


7
2017-10-09 12:55



Voulez-vous dire que les services de streaming utilisent UDP au lieu de TCP pour autoriser intentionnellement les données supprimées? - FreeAsInBeer
@FreeAsInBeer: Oui. TCP intègre de nombreux mécanismes de fiabilité et d'autres fonctionnalités très utiles pour la plupart des applications imaginables. Mais les cas d'utilisation existent là où il y a des choses encore plus importantes que la fiabilité, et le streaming en fait partie: il est plus important de montrer le bon cadre au bon moment que d'afficher chaque image. Le jeu en ligne est un autre exemple où UDP est populaire, pour les mêmes raisons: arrêter l'action pour reconstituer la trace des états des joueurs est pire que devoir corriger pour des problèmes occasionnels. - The Spooniest
En fait, de nombreux systèmes diffusent des données via TCP et un tampon côté client. Pour la diffusion d'un film, la latence n'est pas critique. Il n'y a aucun inconvénient pour l'utilisateur si certaines images se trouvent dans un tampon pendant une minute avant qu'il ne soit temps de les afficher. Mais pour les usages interactifs comme la vidéoconférence, la latence est essentielle. - kasperd
kasperd: Strictement parlant, ce n'est pas la diffusion en continu. D'autres réponses ont mentionné les services téléchargés mais commencent à jouer avant la fin du téléchargement, et c'est ce que font les systèmes que vous décrivez. - The Spooniest
+1 pour la réponse la moins confuse (à ce jour) dans ce fil. - Cosmic Ossifrage


Si vous demandez vraiment de la "bande passante" (octets / s) et non des "données totales" (octets), la question cruciale est la suivante: pendant quelle période de temps? Si nous supposons que l'utilisateur regarde l'intégralité de la vidéo et que le même codec / qualité, etc. est renvoyé, et ignore le petit surcoût de la demande / réponse en continu, 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 terminer le téléchargement. Pour la diffusion en continu, vous devriez voir des pics de bande passante élevée (lorsque le segment suivant est demandé) qui reviennent à zéro pendant que vous observez ce segment jusqu'à la fin du morceau et qu'il y a à 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 passe à zéro dès que la totalité de la vidéo est téléchargée. Si vous arrêtez l'expérience maintenant, la bande passante à télécharger est évidemment plus élevée car elle maximise votre liaison descendante jusqu'à ce qu'elle soit terminée.

  2. Bande passante au moment où la vidéo est regardée. L'heure à laquelle la vidéo est visionnée est la 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. La bande passante étant des 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, tandis que pour le "streaming" il est de 20 au cours des premières unités de temps (pour obtenir un gros bloc initial), puis deux fois 10 pour les deux autres. Notez que tandis que la bande passante est tracée sur l'axe des y, la zone sous chacun des deux graphiques correspond aux données (octets) -si vous intégrer bytes / time over time, vous obtenez des octets.


5
2017-10-09 15:58





Ils ne sont pas comparables.

Pour la première fois, le codage optimal pour la visualisation locale est différent de l'encodage optimal pour la visualisation en flux 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. Cadre intra-codé (I-Frame) - ce sont des images qui sont transférées intégralement, cette image peut être décodée sans connaissance d'aucune autre image. Un cadre intra-codé est essentiellement une image statique. Les encodeurs 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 ne stockent que 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 dernières. Celles-ci sont beaucoup plus efficaces à compresser.

Le codage pour la visualisation locale peut tirer parti de la recherche rapide de disques pour utiliser davantage d'images P et B, tandis qu'une vidéo encodée pour une diffusion efficace devra coder une image 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 différents de diffusion en continu. 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, la diffusion en direct d'événements ne peut pas tirer parti des techniques d'encodage avancées qui prennent un temps long ou imprévisible, tandis qu'un flux pré-enregistré peut prendre autant de temps que nécessaire pour encoder.

La vidéo en streaming est aussi généralement codée avec un débit binaire constant (CBR). Pour la 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. À l'inverse, 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), qui est un compromis entre CBR et VBR. ABR permet au spectateur de s'adapter aux modifications de la bande passante du réseau. Étant donné une bande passante constante et constante, ABR est plus ou moins identique à CBR.

Qu'est-ce que tous ces moyens est que étant donné la même qualité et la même expérience visuelle, vous pouvez encoder la vidéo pour une visualisation locale plus efficacement que la vidéo en streaming, et vous pouvez encoder la vidéo pour des flux pré-enregistrés plus efficacement que les flux en direct.

Il y a aussi une surcharge dans le protocole de streaming. Un téléchargement HTTP régulier peut utiliser l'encodage de transfert en bloc pour télécharger l'intégralité du fichier qui présente une surcharge minimale. Un téléchargement en streaming devra négocier le morceau et la qualité du morceau à transférer. Dans l’ensemble, le coût du protocole de transfert est relativement minime.

Dans l'ensemble, pour la même quantité de vidéos visionnées, la vidéo en streaming devrait finir par prendre une plus grande quantité de bande passante. Le principal avantage de la diffusion en continu, en termes d'utilisation de la bande passante, est qu'elle permet aux utilisateurs de télécharger mais ne regarde pas la vidéo en entier, ce qui peut représenter une économie très importante.


4
2017-10-09 00:48





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 effectuent un contrôle de la fréquence 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 5Mbit et avoir l'air tout à fait correct.

Si vous effectuez un téléchargement HTTP, alors les algorithmes de contrôle de la vitesse TCP seront exécutés pour vous assurer que vous saturez une ou les deux extrémités de la connexion ou tout autre élément intermédiaire. Donc, si vous disposiez de 100Mbit, il utilisera tout ce qu'il peut obtenir ou près de 100Mbit.

Cela suppose bien entendu qu’il n’ya pas de QoS 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 est également OUI (avec des hypothèses), les bandes passantes sont identiques. Pour ce faire, déposez simplement le fichier sur votre serveur Web de base et ouvrez-le avec votre navigateur pour qu’un lecteur s’y mette. Ou intégrez la vidéo sur votre serveur Web de base et, à nouveau, dans le navigateur et utilisez une bande passante identique. l'hypothèse suivante ... pas d'autres utilisateurs, personne d'autre ne partageant le réseau avec vous ... aucun autre facteur en jeu susceptible de modifier votre bande passante.

N'oubliez pas que lorsque vous téléchargez un fichier à partir d'un site Web et que vous le téléchargez à nouveau, la bande passante entre le premier et le deuxième téléchargement peut varier. C'est simplement parce que la charge sur le serveur peut changer et que l'encombrement du réseau et des chemins réseau peut changer.

Alors voilà… ça dépend.


1
2017-10-09 03:59



"la bande passante entre le premier et le deuxième téléchargement peut varier", mais elle télécharge sûrement la même quantité de données, même si celle-ci prend plus de temps que les autres / les conditions du réseau ont changé. - stemie
@stemie, ça sera proche. Différents protocoles ajoutent une surcharge de protocole. Mais s'il n'y avait pas de transcodage ou de changement de qualité / débit au cours du processus de diffusion en continu, il devrait en théorie y avoir la même quantité de données vidéo. - Matt H


Du point de vue du réseau, le "téléchargement" et le "streaming" sont des services différents, il est appelé "profil de trafic"

Pour le service de streaming, le réseau doit fournir un débit constant minimum (techniquement, la "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 le débit réseau maximal, le délai ou la latence n'est pas critique.

Du point de vue de l'utilisateur final, cela signifie que la vidéo doit fonctionner sans interférences ni suppressions. Peu importe si la vidéo commence quelques secondes plus tôt ou plus tard.

Le "téléchargement" nécessite généralement le débit réseau maximal possible, le téléchargement doit être effectué aussi rapidement que possible. Les retards, les interruptions et la gigue ne sont pas critiques.

Un réseau peut fournir plus de profils de trafic complètement différents. Par exemple, les services vocaux (appel téléphonique simple) requièrent un débit très faible mais sont très sensibles aux retards (moins de 200 ms)


1
2017-10-11 17:47





Pour ajouter d'autres réponses, ma réponse est la suivante: Pas nécessairement.

Maintenant, en supposant que tout est égal (pas de sélection automatique de la qualité, pas de limitation du serveur et / ou du FAI) ...

Bande passante est généralement défini comme étant size_of_data divisé par total_time. (Techniquement, le terme «propre» est débit, mais je digresse).

Supposons que vous allez diffuser une vidéo de 2000 secondes de 60 Mo.

Avec le streaming, le programme de diffusion pourrait faire son propre taux de limitation pour empêcher le débordement de tampon. Ainsi, son en-tête de requête HTTP pourrait inclure un champ Range. le efficace bande passante puisque le streaming commence jusqu'à ce que le streaming se termine serait alors ~ 60 Mo / 2000 secondes = 30 Ko / s = 240 kbps.

Cependant, si vous téléchargez la vidéo, vous obtiendrez Jusqu'à la bande passante maximale de votre service Internet. En fonction des autres utilisations en même temps, bien sûr. Ainsi, en supposant un service Internet de 6 Mbps, avec une bande passante disponible de 50%, vous obtiendrez une bande passante de 3 Mbps pour le téléchargement de vidéos.


0
2017-10-09 07:46





Le streaming est vraiment un moyen de téléchargement.

Lorsque vous regardez un film diffusé en continu, votre lecteur multimédia en télécharge des parties, vous les montre et supprime les parties du fichier affichées à la volée.

En règle générale, lorsque vous téléchargez un fichier, vous attendez la fin du téléchargement, puis vous commencez à le regarder. Mais il existe des lecteurs multimédias capables de vous montrer la partie téléchargée du fichier et de faire une pause et d’attendre que certains soient téléchargés. Un peu comme le streaming, mais sans jeter le fichier.

Techniquement, lorsque le problème concerne la quantité totale de données transférées, peu importe la manière dont vous le téléchargez, 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. Ils peuvent être les mêmes fichiers exacts, et cela signifie la même bande passante dans les deux cas.

Les sites de diffusion en continu encodent généralement leur contenu pour avoir un débit binaire inférieur à celui d’un disque acheté en magasin. Mais vous pouvez regarder un film depuis votre ordinateur de bureau sur un ordinateur portable via WiFi en utilisant la fonction de partage de fichiers de votre système d’exploitation, et cela prendra presque la même quantité de trafic que si vous le regardiez sur le bureau. conduire). Techniquement, il serait diffusé en continu pendant que vous regardez un film pendant que des parties de celui-ci sont continuellement téléchargées et supprimées.

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


0
2017-10-09 22:55





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 ne pouvez télécharger que la quantité de téléchargement possible et disponible. Ainsi, si vous souhaitez comparer un téléchargement direct depuis HTTP par rapport à DASH (encore HTTP), vous devrez vérifier le nombre de téléchargements que vous effectuez.

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 du taux qu'ils vous servent.


0
2017-10-10 00:56





Oui c'est l'équivalent. Télécharger = 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.


-2
2017-10-08 09:50



Il existe une différence entre la quantité de données transférées et la bande passante utilisée. - Jonas Wielicki
bien sur mon Android 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 homme 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, car en raison de la mise en mémoire tampon, la vitesse de transfert est plus lente avec le temps. - Nenotlep
C'est en fait la bonne réponse dans beaucoup de cas. Souvent, dans de nombreux cas, la même ressource et le même protocole sont utilisés pour le streaming et le téléchargement. Si vous souhaitez lire une ressource via HTTP, cela ne diffère pas de le télécharger autrement que de le lire lors de son téléchargement. Bien sûr, il existe des optimisations pour la diffusion en continu et différents protocoles qui peuvent changer votre débit lorsque 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