Does streaming use the same amount of bandwidth as downloading?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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)

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.