Assuming the content is of the same quality (ceteris paribus), does streaming media (i.e. video, audio) use the same amount of bandwidth as downloading it?

Say I was to download an HD movie from Amazon or stream it, would it be the equivalent use of bandwidth?

  • 2
    Depends on the protocol and codec: e.g. download via http and stream via rtmp, or h264 vs vp6. IMO this question is too broad given the amount of compression and data transmission methods to compare.
    – zamnuts
    Oct 8, 2014 at 21:51
  • Just to clarify your question. By bandwidth you are referring to data rate, not file (movie) size?
    – hookenz
    Oct 9, 2014 at 3:16
  • An advantage to downloading over streaming (which is technically downloading but for single use only) is that you can consume the material as many times as you want without having to spend your bandwidth on it each time. Some media players can even play videos that you're currently downloading (not fully downloaded), giving the "feel" of streaming with the advantage of downloading.
    – ADTC
    Oct 9, 2014 at 3:29
  • 3
    Yes I am referring to data rate. The reason I asked is had a disagreement with my sister and when I look online all I could find was vague answers from yahoo answers. I realise there are a lot of variables this depends on but I thought it was at least worth asking.
    – stemie
    Oct 9, 2014 at 7:21
  • 2
    "In computer networking and computer science, bandwidth, network bandwidth, data bandwidth, or digital bandwidth is a measurement of bit-rate of available or consumed data communication resources expressed in bits per second or multiples of it (bit/s, kbit/s, Mbit/s, Gbit/s, etc.) - wikipedia.org/wiki/Bandwidth_(computing)"
    – stemie
    Oct 9, 2014 at 7:34

11 Answers 11


It is often not equivalent.

Streaming providers use protocols, such as DASH, to dynamically adjust the quality of the movie to the users bandwidth availability and quality desires. Then the servers may rate-limit your connection so that you can buffer a certain amount (something like 10 seconds, maybe 30 or a whole minute) and afterwards you only get the amount of bandwidth required to get the content to you in real time. This is an obvious optimization from the point of view of the provider, because it spreads the bandwidth more equally among the users and in addition avoids data to be transferred in vain (e.g. when the user watches a 480p movie for 10 minutes, without ratelimiting and with a common downlink, it is likely that much more than that is already downloaded, but then wasted if the users stops watching the video).

The amount of data transferred is the same. But it may take longer with streaming, because the provider may rate-limit the data transfer to the rate required to deliver the content in a given quality in real time.

Dailymotion is one of the providers which rate-limit the connections. From a server with at least 100 Mbit/s symmetric connection, we see the following behaviour¹:

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

The rate is much below what would be possible (and is achieved with other providers). Also, if you try different material, you’ll find that the rate is highly dependent on the individual video: a fullhd video easily downloads with > 1 MiB/s, while a a music video such as this stays around or below 200 KiB/s.

To sum it all up and clear up some possible misunderstandings: Some providers may rate limit your download while streaming, through their client application (e.g. youtube with their html5 or flash video player) or by server means. If they don’t rate limit you by server means, then downloading will consume more bandwidth, because the rate limiting which is possibly applied by the client application during streaming does not take place. This is the main case when the bandwidth consumed is different with respect to the original question.

  1. I am aware that this is kind of anectodal evidence—I have however observed this behaviour consistently.
  • 3
    @Psycogeek Youtube is one of the examples using DASH (if this comment doesn’t make sense to you, read the introductory part of the article I linked). This implies that the player the client is using must request the sequential chunks of video anyways. Taking the step from there to stop requesting more chunks if the player isn’t running is just natural. Downloaders such as youtube-dl will just continue to request more chunks until the video is fully downloaded. So streaming with DASH incurs a bit more overhead, but it’s probably worth it (for both the user and the provider) and neglectable. Oct 8, 2014 at 11:34
  • 1
    Assuming the same data encoding and and definition are used (see psychogeek comment) downloading will use more total bandwidth. A download of the video will almost certainly be done with TCP, while streaming will be UDP or similar non-guaranteed delivery approach. Thus the TCP will have more acks sent at minimum, and since you probably will lose or corrupt at least a few packets the tcp approach will actually be more downloading as well (as it will fetch the lost packets also). Though the difference is very minor compared to the size of the download, so this is mostly academic.
    – dsollen
    Oct 8, 2014 at 15:09
  • 2
    @dsollen: Unless a UDP sender is going to just let packets flow without caring whether the intended recipient still exists, both UDP and TCP are going to require periodic acknowledgments; in either case, the acknowledgments are going to represent a very small portion of the total traffic. Further, formatting data in such a fashion that each packet can be understood even if the previous packet is not received generally implies a level overhead beyond what would be required for TCP.
    – supercat
    Oct 8, 2014 at 18:32
  • 7
    I'd downvote this answer if I had enough rep: it does not answer the question, the key phrase being "same quality". When a provider drops quality, this is not ceteris paribus.
    – zamnuts
    Oct 8, 2014 at 21:46
  • 1
    @zamnuts, then post a better one and let the community decide. FWIW, its a bit apples and oranges when you consider provider decided quality dips, but I dont think the answer would be complete without it.
    – crthompson
    Oct 8, 2014 at 21:51

Assuming we are talking about the same quality (i.e. no throttling, frame-skipping, or lower-quality streams), then at best the streams will take the same amount of bandwidth as a download, although it could be done at a time/rate more convenient to the provider. It could also take more bandwidth depending on how the video is compressed - most of the time the entire image is not sent, rather just the change (or delta) between the frames. This means that the more history there is (i.e. use that hue of blue from pixel X in frame Y), the less there needs to be sent. This normally doesn't pop up much, but when a stream is paused/interrupted for whatever reason, this "history" is lost and will need to be re-transmitted, thus increasing the bandwidth, while with a download, it can be resumed at the "break", and assumed that the receiver already has this information. The same can be used for audio, especially where there isn't a fixed rate (i.e. FLAC instead of mp3)

Jumping around (skipping, re-winding, etc.) could also affect the usage - going forward past the buffer would reduce the amount of bandwidth used by a stream, but any re-winding would increase it. Also there would be an interrupt, which will cause increased usage (see above), and any sort of "thumbnail preview" like what youtube and netflix use would also slightly increase the bandwidth.

Last note: compression: this could be done for downloads, but not so much for streams - the caveat being that most videos are already compressed, so there wouldn't be much gained here (although there could be room for gains in the ultra-high resolution/quality department).


Streaming will use less bandwidth, especially if network conditions are bad, but this comes at a price.

At issue is the data that needs to be sent. In a download model, all of the data must reach the customer, all in the right order, no matter what. If network conditions are bad and some bits of the data don't reach the client, they must be resent, and this increases bandwidth usage. If some data gets there out of order, it must be put back into order before being presented, and this decreases responsiveness.

In a streaming model, it's OK if some of the data doesn't reach the client. If you're streaming a movie and a frame doesn't get there, you can just skip it and move on, so you don't use additional bandwidth on resends. If some frames get there out of order, just play the ones that go forward; a momentary blip won't matter, and so this increases responsiveness. However, it also means that you don't necessarily get the full data: whatever you see is whatever got there on the first shot.

If you have to choose between the models, choose based on what you want to do with the data. If you want to archive it and/or possibly view it many times, then download it so that you're sure to get everything. If you don't plan on archiving, or only plan on viewing the data once, then go ahead and stream; you probably won't notice the difference on a single viewing, and if network conditions are bad enough that you do notice, then downloading would be even worse.

  • Are you saying that streaming services use UDP instead of TCP to intentionally allow dropped data? Oct 9, 2014 at 17:51
  • 1
    @FreeAsInBeer: Yes. TCP builds in a bunch of reliability mechanisms and other features that are very useful for most imaginable applications. But use cases DO exist where there are things even more important than reliability, and streaming is one of them: it's more important to show the right frame at the right moment than to show every single frame. Online gaming is another example where UDP is popular, for the same reasons: stopping the action to reconstruct the trail of player states is worse than having to correct for the occasional dropped state. Oct 9, 2014 at 18:02
  • Actually many systems stream data over TCP and buffer on the client side. For streaming a movie, latency is not critical. There is no inconvenience to the user if some of the frames happens to be sitting in a buffer for a minute before it is time to display them. But for interactive usages like video conferencing, latency is critical.
    – kasperd
    Oct 11, 2014 at 8:45
  • 1
    kasperd: Strictly speaking, that isn't streaming. Other answers have mentioned services that download but start playing before the download is finished, and that's what the systems you describe are doing. Oct 11, 2014 at 11:26
  • +1 for the least confusing answer (to date) in this thread. Oct 12, 2014 at 21:30

If you're really asking for "bandwidth" (bytes/sec) and not "total data" (bytes), the crucial question is: during what period of time? If we're assuming that the user watches the entire video and that the same codec/quality etc. is returned, and ignore the small overhead of streaming request/responses, then the total data returned is equal.

Now, what is the bandwidth? There are two ways to understand your question:

  1. Bandwidth during the time it takes until the download is complete. For streaming you should see spikes of high bandwidth (when the next chunk is requested) that go back to zero while you're watching that chunk until you near the end of the chunk and there's a spike in bandwidth again. For downloading, you should see a very high bandwidth for, say, 10min which goes down to zero as soon as the entire video is downloaded. If you stop the experiment now, the bandwidth for downloading is obviously higher since it maxes out your downlink until it's done.

  2. Bandwidth during the time the video is watched. The time the video is being watched is the same for both streaming and download, assuming both start watching immediately. The total data size is the same as well. Since bandwidth is data per time, it is the same for both scenarios.

In the example below, there's always a total of 40 (units of data) downloaded. But for "downloading", it's 40 in the first unit of time, while for "streaming" it's 20 during the first units of time (to get a big initial chunk) and then twice 10 for the two additional chunks. Note that while bandwidth is plotted on the y-axis, the area under each of the two graphs corresponds to the data (bytes)—if you integrate bytes/time over time, you get bytes.


They are not comparable.

For the first instance, the optimal encoding for local viewing is different than the optima encoding for streamed viewing.

Let's talk about video encoding.

In most video encoding format, there are usually two types of frames:

  1. Intra-coded frame (I-Frame) - these are frames that is transferred in full, this frame can be decoded without knowledge of any other frame. An Intra-coded frame is essentially a static image. Encoders would generate these during sudden transitions. These are less efficient to compress.
  2. Predicted frame (P-Frame) or Bi-predicted frame (B-Frame) - these are frames that stores only the differences between frames, it can only be decoded if the viewer also knows the previous and/or latter frames. These are much more efficient to compress.

Encoding for local viewing can take advantage of fast disk seeks to make use of more P and B frames, while a video encoded for efficient streaming will have to encode more redundant I-Frame along the entire video even when there is no sudden transitions to accommodate random seeking.

Also, there are two different type of streaming. You can have streaming of a pre-recorded stream (most Youtube videos) and live event streams (e.g. Youtube Live). Due to the latency need, streaming live event cannot take advantage of advanced encoding techniques that takes a long or unpredictable amount of time, while a pre-recorded stream can take as much time as it needs to encode.

Streamed video also is usually encoded with constant bit-rate (CBR). For the same target size, a variable-bit rate (VBR) video will typically have a higher quality than a CBR video. Conversely, a VBR video is smaller for the same quality of a CBR video. An adaptive streaming protocol like DASH has an adaptive bitrate (ABR), which is a compromise between CBR and VBR. ABR allows the viewer to adapt to changes in the network bandwidth. Given a constant, consistent bandwidth, ABR is more or less the same as CBR.

What all these means is that given the same quality and viewing experience, you can encode video for local viewing more efficiently than streamed video, and you can encode video for pre-recorded streams more efficiently than live streams.

Then there is also an overhead in the streaming protocol. A regular HTTP download can use chunked transfer encoding to download the entire file which has very minimal overhead. A streamed download will have to negotiate the chunk and quality of the chunk to transfer. In the grand scheme of things, the overhead of the transfer protocol is relatively minor.

Overall, for the same amount of video watched, streamed video should end up taking a larger amount of bandwidth. The primary advantage of streaming, in terms of bandwidth usage, is that it can save by people that download but doesn't watch the video in full, which can be a very significant saving.


The answer is "It depends".

The answer is NO, for providers that host video in general. Half decent providers that stream video do rate control so as to ensure smooth playback and optimal bandwidth for as many people as possible. So even though you may have lots of bandwidth, it may decide to give you only 5Mbit and look still quite decent.

If you do an HTTP download then TCP rate control algorithms will kick in to ensure that you saturate one or both ends of the connection or anything in between. So if you had 100Mbit available, it'll use all it can get or near 100Mbit.

That of course assumes there is no QoS happening anywhere in between the client and server.

Your question is so loose that I could also make it so that in some naive setups the answer is also YES (with assumptions), the bandwidths are identical. To do that, simply drop the file onto your basic web server and open it with your browser so that a viewer kicks in. Or embed the video on your basic web server and again, it'll play in the browser and use identical bandwidth with the following assumption... no other users, no one else sharing the network with you... no other factors at play that may alter your bandwidth.

Bare in mind that when you download a file from a website, and then download it again the bandwidth between the first and second download can vary. This is simply because load on the server can change and congestion on the network and network paths can change.

So there you have it... it depends.

  • "the bandwidth between the first and second download can vary" but surely it is downloading the same amount of data in the end, even if the one takes longer than the other/the network conditions have changed.
    – stemie
    Oct 9, 2014 at 7:33
  • @stemie, It'll be close. Different protocols add protocol overhead. But if there was no transcoding or quality/rate change during the streaming process then it should be the same amount of video data in theory.
    – hookenz
    Oct 9, 2014 at 18:15

From network point-of-view "downloading" and "streaming" are different services, it is called "traffic profile"

For streaming service the network has to provide a minimum constant throughput (technically "bandwidth" means something different), the streaming service is sensitive for interruptions and jitter. It does not require the maximum network throughput, delay or latency is not critical.

From end-user perspective it means: The video shall run smoothly without interrupptions or drops. It does not matter if the video begins a few seconds earlier or later.

"Downloading" usually require the maximum possible network throughput, the download shall be finihsed as quick as possible. Delays, interruptions and jitter are not critical.

A network may provide more traffic profiles which are completely different. For example voice services (simple phone call) requrie very low throughput but are very sensitive for delays (less than 200 ms)


To add to other answers, my answer is: Not necessarily.

Now, assuming that everything is equal (no automatic quality selection, no throttling from server and/or ISP)...

Bandwidth is usually defined as size_of_data divided by total_time. (Technically, the 'proper' term is throughput, but I digress).

Let's assume you're going to stream a 2000-second video sized 60 MB.

With streaming, the streamer program might do its own rate-limiting to prevent buffer overflow. So, its HTTP request header might include a Range field. The effective bandwidth since streaming begins until streaming ends would then be ~ 60 MB / 2000 seconds = 30 KB/s = 240 kbps.

However, if you download the video outright, you'll get up to the maximum bandwidth of your Internet service. Depending on other usage at the same time, of course. So, assuming an Internet service of 6 Mbps, with 50% available bandwidth, you'll get 3 Mbps bandwidth for video downloading.


Streaming is really a way of downloading.

When you watch a streamed movie, your media player will download parts of it, show them to you, and discard the shown parts of the file on the fly.

Typically, when you download a file, you wait for the download to finish, and only then start watching it. But there are media players that are capable of showing you the downloaded part of the file and automatically pause and wait for some more to be downloaded. Kinda like streaming, but without discarding the file.

Technically, when the concern is total amount of data transfered, it doesn't matter how you download it, but the difference between the file that you download and the file that your media player downloads for you as a stream. They may be the same exact files, and it will mean the same bandwidth in both cases.

Streaming media sites usually encode their content to have lower bitrate than a store-bought disc. But you can watch a movie from your desktop PC on a notebook via WiFi using the file sharing function of your OS, and it will take up almost the same amount of traffic as if you were watching it on the desktop (as read bytes from hard drive). Technically it would be streaming, as you watch a movie while parts of it are being continuously downloaded and discarded.

So the answer is it absolutely depends on the size of the two files − streamed via media player and downloaded to the disk.


Streaming does use your download throughput hence you can consider it as download. Your question is a little bit ambiguous as to what you consider a download. You can only download as much upload they can and are willing to offer. So in the end if you want to compare a straight download from HTTP over DASH (still HTTP) for example, you'd have to check how much downloading are you doing from each.

So I guess the answer is that it could be using the same amount... or less... or more. depending on the servers and the rate they are serving you.


Yes it is the equivalent. Download= You download it only one time and it stays on your computer. Stream= You temporarily download "something" to your computer.

  • There is a difference between the amount of data transferred and the bandwidth used. Oct 8, 2014 at 10:25
  • well on my android watching a video from a stream or download it has the same data usage Oct 8, 2014 at 10:55
  • @JonasWielicki A wise man once said: "The amount of data transferred is the same". Sure the amount of bandwidth used varies, in that due to buffering the speed of transfer is slower over time. Oct 8, 2014 at 12:26
  • 1
    This is actually the right answer in a lot of cases. Often times in a lot of cases, the exact same resource and protocol is used for streaming and download. If you want to play a resource over HTTP, it's no different than downloading it other than that you are playing it back as it is being downloaded. Sure, there are optimizations for streaming, and different protocols which may change your bitrate as you stream, but I don't think that's the core of the question being asked. (They do deserve mention however.)
    – Brad
    Oct 9, 2014 at 2:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .