Does streaming use the same amount of bandwidth as downloading?

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

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