The Difference Between Downloading and Streaming | Hacker News Reader

The Difference Between Downloading and Streaming

danq.me

There could be a #4 "historically, streaming could use protocols with unreliable delivery and with limited or no retransmission" (which is somewhat related to #1 and #2). For example, there have been media streaming protocols built on UDP rather than TCP, so packets that are lost are not automatically retransmitted. The idea is that for a real-time stream transmission, older frames are no longer considered relevant (as they would not be rendered at all if they were received late), so there is typically no benefit in retransmitting a dropped packet.

That means you could get drop-outs when data gets lost in transmission, but the overall data consumption of the protocol wouldn't go up as a result.

Not all that long ago, this prompted lots of debate about QoS and prioritization and paid prioritization and network neutrality and stuff. People were arguing that media streams needed higher priority on the Internet than downloads (and other asynchronous communications). Effectively, different Internet applications were directly competing with one another, yet they had very different degrees of tolerance to delays, packet reordering, and packet loss. Wouldn't ISPs have to intervene to prioritize some applications over others?

I remember reading from Andrew Odlyzko that this controversy was mostly resolved in an unexpected way: faster-than-realtime streams with buffering (as the network was typically faster overall than what was needed for a given level of media quality, you could use TCP to reliably download frames that were still in the future with respect to what would be played, and then buffer those locally). This is indeed the scenario depicted in this article.

What about actual live events? My impression is that Twitch and YouTube livestreaming are using a 10-30 second delay relative to realtime, specifically to allow for significant buffering on the client, and then using reliable TCP faster-than-realtime downloads of the "near future" of the video content. Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live. (I don't understand how this interacts with the typical ability to start watching almost instantly, with no visible buffering delay, though.)

There's a big difference for bidirectional conversation, like phone calls, because there even tiny delays are extremely psychologically noticeable. It appears that Zoom, for instance, is still using unreliable UDP streams for call content, which allows skips or dropouts, but keeps the latency relatively low so that it feels comparatively more like a face-to-face interactive conversation.

> My impression is that Twitch and YouTube livestreaming are using a 10-30 second delay relative to realtime,

Yeah. The rule of thumb with Twitch used to be 11 seconds. You can still measure this because many streams replay the chat in the stream as an overlay for both being able to see when the streamer has seen your message and for archival purposes to preserve the chat in VODs.

> don't understand how this interacts with the typical ability to start watching almost instantly, with no visible buffering delay, though.

There's a buffer on the CDN (which they have anyways because they're recording the VOD) and you start playback at the point t seconds back.

There is a low-latency mode for twitch now that I think is enabled by default. The actual delay is reported in the "stats" view under advanced settings, probably coming from timestamps in the video metadata. There's third-party twitch clients I've used with the option to delay the chat to match the video using this information, which would be useful if you didn't want chat popping off to spoil you.

>Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live.

Plenty of streamers show the chat on screen and talk with people in the chat. This is not true.

Good point. I didn't think of that, but that's right.

I have seen significant delays in that situation, so maybe a better way to say this is "using text rather than voice for feedback makes the delays introduced this way less psychologically noticeable" (because they are noticeable in the situation you mention).

It is still noticeable. When beam.pro rolled their low latency streaming (~100ms) streamers and chatters commented on how much more enjoyable and natural chatting was when things had less latency.

On the grasping hand, sometimes the feed is deliberately delayed, such as when the streamer is showcasing some kind of competitive activity wear their own information could be used against them.

>Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live.

Depending on the delay, this can cause problems when switching from delayed streaming to real life. For example, watching the countdown on a rocket launch via streaming then going outside to watch the actual launch. Usually, for me, a few seconds delay is OK, because I can't see the rocket until about 30 seconds after liftoff due to trees. But when I have a better view of the launch pad the delay can become an issue.

> Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live.

This can be a problem, for example when sports fans receive out-of-band notification of a goal before they see it happen on their "live" stream.

No need for notifications even, you can literally hear latency varying up to 30 seconds by listening for cheers during important game in a block of flats on a warm summer night.

> cheers during important game in a block of flats

Yes, that is what rlpb wrote: soundwaves are richly descriptive out-of-band notifications!

It also makes it impossible to watch a live updating box score without spoilering yourself since it updates before the stream.

> My impression is that Twitch and YouTube livestreaming are using a 10-30 second delay

This used to be the case, and may still be for some steamers, but mostly when I watch it's less than a couple seconds delay with the low latency mode enabled in the browser.

When setting up a YouTube livestream I can choose if it has a delay or not.

> What about actual live events? My impression is that Twitch and YouTube livestreaming are using a 10-30 second delay relative to realtime, specifically to allow for significant buffering on the client, and then using reliable TCP faster-than-realtime downloads of the "near future" of the video content. Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live. (I don't understand how this interacts with the typical ability to start watching almost instantly, with no visible buffering delay, though.)

For TV, last I worked on a system like this the clients received data the same way as non-live streams: Http streaming (HLS or Dash), where you fetch playlists and small video files and the player stitches them all together. There's buffering along the pipe, the 30-60s total delay (which you'll notice if you watch sports and chat with someone who has cable and is watching the same thing) is a cumulative thing, so you don't see a 1-min startup delay, you just near-instantly get dropped into something that's already quite a bit behind.

Not sure what Twitch does. The over-the-network video game streaming-console services are obviously completely different from TV land, they couldn't get away with it there; but for TV the expense of better isn't seen worth it.

Twitch is HLS, but they've tightened the buffers and shortened the segments (2s is standard) so that latencies of down to a couple of seconds is common. It's quite impressive, tbh.

  ...you could use TCP to reliably download frames that were still in the future with respect to what would be played, and then buffer those locally)

I was mucking around with my network recently, with Netflix playing in the background. Rebooted the router, and to my utter surprise, the stream continued to play uninterrupted for the entire (30+ seconds) time it takes my network stack to reinitialize. I did not realize how aggressively the providers buffer, but it completely papered over the lack of internet service for the window.

With YouTube on desktop, you can right click and turn on "Stats for Nerds" to watch the buffer health in realtime to see how much buffer it has decided your connection needs and how often it refills it

Netflix has a similar feature, but it's more hidden.

https://blog.sayan.page/netflix-debug-mode/

Netflix appears to download the entire title upfront. I’ve had outages go unnoticed until the end of the episode.

My Chromecast probably doesn't have enough storage to buffer an entire episode.

I remember having countless depressing conversations about this all the way back in the very early 2000s when potential clients wanted us to program a video "streaming" system that did not allow downloading, and fruitlessly trying to convince them that streaming was downloading--there's no meaningful technical difference. People were convinced that "streaming" was some weird distinct mode that the Internet could be converted into, and that you just need to program harder to do it.

Just lie to those people.

On one hand, that will get you plenty of jobs working for those people.

On the other hand, that will get you plenty of job working for those people.

Capitalism: Trickling down agency to the intelligent since Year X

It is not a hard distinction to explain.

Streaming does not by default save to device. There are ways around it; these are pointless to invest too much in fighting. Making streaming good and reasonably priced makes legit customers out of pirates.

You will never defeat piracy through technology, only through economics.

I remember going into local browser cache folders and pulling out YouTube videos in full. Am I remembering wrong or did in fact the #1 video streaming platform simply just download the videos to your hard drive, same as you would have with right click save? Only difference is the default folder it goes to.

I do not recall this specifically with YouTube - but I recall pulling wmv's out of the IE cache in the same way.

absolutely. you would just go to the browser cache folder and look for the file that was increasing in size as the seconds passed. This is why I disagree with the comment above that you can't defeat piracy through technology. I think there are plenty of people like me who routinely kept music/video through tricks like that who are now thwarted by whatever the heck html5 thing browsers started doing in the 2010s.

If you could find a file in the cache folder you are fully capable of typing `yt-dlp URLHERE` in a terminal. I taught my dad how to do that around 2010 or so so he could save his religious music to his computer.

well yt-dlp didnt exist in 2010, so no you didn't. At some point he had to move from youtube-dl or whatever it was called to get the new fork. and looking at yt-dlp's github I see how often its tricks get shut down by google, and old releases don't work. Every few months. That inconvenience alone will discourage many pirates and save a lot of money for content providers. Just as there are many users users will at the margin economically there are many at the margin of competence or drive.

I've been running a YT-DLP build for a year now, no issues. Even I am surprised.

People who use tricks like this will always be in the minority. This is harder than going to TPB.

You might defeat piracy through draconian laws though.

They are already and nobody cares because there are enough technical ways to dodge them.

There are plenty of less-technical ways to dodge them as well.

Older stuff doesn't see much enforcement. Unless it's Nintendo or Game of Thrones, basically.

>Streaming does not by default save to device

But that's not accurate. It does download the content to the device but only stores it in the browser cache as chunks or otherwise you could not buffer or replay.

In gaming Denuvo (a technology) has essentially defeated piracy. Also the last two xboxes

Denuvo is crackable, but there's low demand for it outside of a few big budget singleplayer games. Not to mention gamers are spoiled for choice. There are literally thousands of free or cheap games to play instead of new releases... why muck with piracy when you can grab a grey market month of gamepass for less than a sandwich?

I remember a line from the 2002 movie Big Fat Liar involving a school assignment, that went something like, "And don't even think about downloading something from the internet; I want that essay hand-written".

One reason I remember it is the implicit assumption that one couldn't transcribe a digital essay onto physical paper.

The other reason is because it seemed strange to call it "downloading" when I was imagining a web page. Aside from the possibility that it was downloading a non-HTML document file, "downloading" didn't feel right for "visiting a web page", even though of course it is downloading in a more technical sense.

Like "streaming", downloading a web page into your browser's memory isn't saving it to long term storage.

Downloading is life.

Sailing the high seas since Napster.

I give thanks to:

BitTorrent - Private trackers - Subsonic API - Navidrome - invidious - yt-dlp - Infuse - mpv

Do you ever pay for new content to be created?

The answer is yes.

Large CD-collection, large DVD/BD collection. I go to the cinema etc.

Problem is a lot of media is missing in the mainstream, much of the less popular stuff is kept alive on the private trackers. My philosophy nowadays is that it's become an archival endeavor that I want to contribute to.

I wish we could all pay an internet fee for free access to all media like proposed by Stallman in Free Software, Free Society but we're going backwards towards fragmentation like cable tv back in the 90s with ever increasing prices (watch Black Mirror S07E01 common people for an ironic take on this).

I seem to remember Stallman suggesting a busking model where you could watch/listen all you want but there's a button you can press to give some "internet bucks" directly to the artist.

The problem with a flat rate is how to distribute it. If you split it evenly amongst all contributors then you just get a lot of shite generated by everyone who wants a slice. But if you do it "per listen" like Spotify then it's massively unfair to newer artists while artists like the Eagles keep raking it in even though you've probably paid for Hotel California about ten times over at this point.

I agree it’s a hurdle for new artists, but don’t think it’s unfair per-se.

If the Beatles, Eagles, Led Zeppelin, or others have content that continues to provide enjoyment, why shouldn’t they continue to benefit financially for that fact? I don’t care how long it took to write and perform a song; I get benefit from being entertained not the work that went into it.

I do, but still routinely resort to high seas. Many reasons:

Forcing me to download 1080p but 4K is stream only (how does that make sense, esp when your CDN is too far to effectively stream 4K)

Downloads that expire after few weeks

Sad lack of localized subtitles (Netflix is the worst offender here and Apple is best. While there are some third party browser plugins for this, it obviously doesn't work on TVs)

Can't add multiple subtitles (i.e. watching same movie with parents who don't understand neither movies original language, nor english subtitles)

Free national content that's only accessible locally. As an expat who spends quite a bit with our tiny community abroad - I find it ridiculous we can't easily access content my kids could watch and learn my language. Such a simple step.

Cherry on a cake - how come pirate sites are even better at search + filtering?

> Do you ever pay for new content to be created?

One can always subscribe to all major video and audio platforms, visit cinema's and concerts, buy merchandise, but still sail the high seas..

People willing to put in an effort to acquire and lovingly conserve the media of interest to them are often the people who really care about that media. They are often the most eager to support the creators of different media.

Which is extremely logical and obvious, if one can quickly lift one's head up above the "anti-piracy" propaganda of the major copyright-wielding creativity-killing companies spewing out the same drivel year after year.

Conversely, I have found that the same people who will happily equate "having a spotify subscription" to "supporting artists", who do things like attack people who jailbreak their kindle or whatever, these people are often the greatest thoughtless vibers when it comes to media. Try asking someone like that to name a piano player, or a bassist, or a drummer. Ask them to name three directors.

They'll know celebrities, not musicians or actors. They'll know to attack "pirates" on cue, but have no conception where their money goes every month when their subscriptions are billed.

I'm caricaturing, but these are my experiences.

(For music etc, the difference is licensing. It’s not a technical distinction, it’s a business one.)

(Music) Streaming being a "rented" download is the analogy I used to use back in the day.

e.g. the "rented" downloads can be removed from file system at any time by the service you've "rented" from, while a "purchased" or "owned" download is only removed by the person who purchased it.

On capable devices actual downloading is even supported as an USP by most providers for offline/travel scenarios.

Besides that there are even more externalities that differentiate them:

Client and User requirements and targeted devices, therefore mass adoption and market penetration.

Downloading requires quite expensive hardware by comparison in usually quite complicated setups for a TV/like experience, it requires the user to do active file management, (which includes deleting files at some point, or buy more expensive local infrastructure) to become a mass market consumer thing, this needs to be externalized.

A streaming client is way cheaper to build and market, since doesn't need any relevant amount of non/volatile memory to speak off, that the user experience easier to sell is also quite obvious as witnessed by the golden last decade, it's only now getting tainted by encroaching advertising and platform proliferation etc.

Streaming is different concept than Downloading.

Streaming:

1) In remote, The server will provide chunks of data. Each chunk has predefined length.

Even in Text format you have to identify each chunks to process. `Transfer-Encoding: chunked` HTTP header for example.

> No local streaming in remote computer.

2) In local storage system you can stream any length of data from Storage Drive to RAM

Downloading:

1) In remote, The client will request chunks of data. You can request any length.

You don't need to identify the chunks. You can append the downloaded data without any process.

> There is Local streaming. The remote computer actually streams data from it's storage to RAM.

2) In local copying from peripheral device is also called Downloading. I've seen Downloading label in micro-controller burner.

Presenting, Storing or Deleting the either one data is your choice. Not only stream; also you can watch, listen, read the downloaded content also without storing it into actual drive or without finishing the download. It's all actions nothing to do with techniques behind the terms.

At Koofr[1] one of the most requested features was an option to prevent downloading files from public links. We didn't want to lie to our users so we added a "Hide download button" option because that's the only thing you can do. You can hide the download button but you can never really prevent the download.

[1] https://koofr.eu

>> rights holders have engaged in a fundamentally-doomed arms race of implementing copy-protection strategies

Not entirely true. They simply haven't succeeded in created an industry-standard secure pipeline to the pixels on the display. Aside from the "analogue hole", eventually all of the gaps will be plugged, the same way we use secure sockets today. All media devices (including home HDTV/8K/etc) will extend the chain of trust farther into the pipeline. A set of signed apps and hardware will be required to watch any DRM films on HDTV, with each stage using authenticated encryption completely annihilating any MITM siphoning of the video.

So, its not doomed, just moving slowly, but it absolutely WILL arrive. I know, because I'm working on secure embedded video codec hardware, and our customers are targeting this..

At some point you hit the pixel driver with a bunch of bits, unless your pipeline involves digital signing of copyrights in everyone's future cyber eyeballs, it will always be possible to get the video if you have hardware access.

And the article goes over how there is already an industry standard for the encryption pipeline that goes all the way to monitors and television sets themselves and how you can get a cheap device which just pretends to be a TV and passes on an unencrypted HDMI out.

The end goal is end-to-end protection with online verification. As far as I can tell, we are already halfway there. The highest level of Widevine protection in use today essentially involves the streaming server having a private encrypted conversation directly with your GPU. That includes a certificate that can expire due to age and be revoked due to suspicion of tampering. If anything is not up to snuff, you'll get downgraded content at best and a ban at worst.

The next logical step is to extend this process down the chain to include every device from the GPU to the display.

In order to make a fake TV work, you'd likely need to take a real TV and hack it. That's going to get increasingly difficult and various watermarking techniques will likely allow it to be identified and blacklisted anyway.

I loved these series of CCC talks

- https://media.ccc.de/v/37c3-12296-full_aacsess_exposing_and_...

- https://sgx.fail/ and I'm sorry I'm not currently having good luck finding the talk that went along with it

I think that physical media is already known as the weakest link in the chain today and is thus being phased out. While the studios were reticent to adopt streaming initially, I think they've realized it is actually easier to secure, and to keep secure over time.

I don't know if there are exploits against GPUs like those against SGX. It's much easier to update GPU firmware than BIOS/UEFI.

I see more pirated media sourced from streaming services than physical media nowadays.

I've dug into this a bit more, and it seems I got some wires crossed somewhere.

Widevine L1 (the highest level of protection) is still expecting a "trusted execution environment" that is separate from the GPU. This leaves two major paths for exploitation: against the TEE itself, and against the path between the TEE and the GPU. There seem to be published exploits for the former, at least.

Also, Widevine L1 is only really used for "high-value" content, so it's often possible to obtain relatively high-quality streams at lower protection levels, which I'd assume are even easier to break.

Not to put too fine of a point on it, but the crytography behind DRM seems consistently amateurish. They ought to be doing what I said, but maybe for compatibility reasons they can't. I think the gist of what I said remains, though: online streaming is superior to physical media from a DRM perspective because it can use online verfication natively. A physical disk cannot change after it is stamped, but a streaming service can implement tighter rules over time, even for its back catalogue.

I’m sceptical this could ever work politically.

There are still people watching television on 1980’s hardware. Full HD televisions have been essentially feature complete for over 20 years and should remain relevant for another 20 years, since the vast majority of broadcasts are still 480p and 720p. There are now hundreds of millions of 4k and 8k televisions and projectors with expected service life and lifecycles extending into 2050s.

Bricking those devices en masse is a PR disaster and invites legal scrutiny from regulators, and any individual service suddenly requiring special hardware is shooting itself in the face financially.

> since the vast majority of broadcasts are still 480p and 720p.

I don’t think I’ve seen anything below 1080p on Xfinity cable in the USA for at least 10 years. Even older content is typically upscaled at the broadcast source (e.g. Seinfeld reruns)

Are you referring to over-the-air broadcasts? Or cable/satellite broadcasts?

Implementation depends on the country and the broadcasters. I know nothing about US and Canadian broadcasting standards.

In Europe TV is in most countries sent over DVB-T2 (DVB-C2 in urban areas) which supports SD, HD and FullHD. The older standards, DVB-T and DVB-C, are still used in some countries and not everyone even plans to transition to DVB-T2. There are countries and broadcasters sticking with SD and 720p HD.[1]

The resolution of video content (SD, 720p or 1080p) is only approximately correlated with quality (there are numerous resources online comparing different resolutions at different bit rates and bit depths). I'm not a big broadcast TV user, but from eyeing various EU countries' TV broadcasts at hotels and the occasional sports bar while traveling, for the majority of your every day programming the quality corresponds to YouTube's 720p format (~2 MB/s), even if for example German TV is nominally 1080p50 H.265.

As an example, in most of the EU the 2024 Olympics were broadcast in 1080p. There was no 4K option available to purchase in many countries. The 1080p broadcast, however, had a very low bitrate, making it effectively equivalent to YouTube 480p/360p/240p. Many sports involving fast moving landscapes and water looked worse than in the 80s and 90s. Footage of water, in particular, compresses very poorly at constant bitrates because of the constant subtle motion of waves and reflections on its surface.

[1] https://en.wikipedia.org/wiki/DVB-T2

All it takes is one person to figure out how to get the bits out, and then the only other potential solution would be to make devices that cannot play unencrypted content.

>I know, because I'm working on secure embedded video codec hardware, and our customers are targeting this..

Why? Or more specifically, why you, doing that?

You can say no, you know. To solve your problem, you're making for some of the least scrupulous people on the planet, (Hollywood types), the primitives to a guaranteed technologically enforceable tyranny. Remember that just because someone says they won't do something with a thing, doesn't mean the heel turn isn't coming. Sometimes you just don't build things because people can't be trusted with them.

So, why are you doing it?

You might think it's just harmless bits now... But today's harmless bits are tomorrow's chain links. Seriously asking. Might help me out of a mental hang up I'm trying to work through.

This is another one of those little technical debates we all like to have. Most of it comes down to the intent of what it we're trying to achieve and how we place language around it.

If I want to stream something, it traditionally means I want to watch it in (near) real time as it is being downloaded, without necessarily having to store the entire thing. If I am downloading, I want the whole thing first before I watch it and I want to keep all of it.

Depending on the intent, will depend on the technical solution put in place to do that thing well, as there are technical differences. So yes, to watch a movie it requires downloading it in some way shape or form.

Something that doesn't need as much discussion as it gets. One of those "well technically it is..." type of arguments.

>Like all these technologies, HDCP was cracked almost immediately and every subsequent version that’s seen widespread rollout has similarly been broken by clever hacker types

Is there proof HDCP 2.3 has been cracked?

Does it matter? 4K content only requires 2.2 and there isn't really enough native 8K content to justify buying gear for 8K.

2.2 hasn't been cracked either.

IIUC it doesn't matter much if HDCP is cracked because the licenced chips (or knock-offs from the same factory) end up in stripping devices (or devices that are marketed as having another function like display cloning but also effectively strip the HDCP).

On top of that most pirates prefer to crack the encryption much earlier. Ideally the video stream is captured before the video is decoded. This avoids quality loss that would occur when re-encoding the video.

So cracking HDCP is only "interesting" if you don't want to buy the (very available) hardware and are not going to re-encode or are ok with the generation loss.

>IIUC it doesn't matter much if HDCP is cracked

I'd prefer people have this opinion than parade around the idea that HDCP is useless because it's broken.

>end up in stripping devices

Which should get their keys blacklisted.

> Which should get their keys blacklisted.

And yet, it does not.

Downloading and streaming may look the same from the sending side.

What you cannot say is that saving and streaming are not the same.

Streaming UI uses "download" as a synonym of "save to local file". That particular semantics of "download' is not the same as "stream".

There are some "streaming" systems that just download clips of a few seconds, which Javascript in the client reassembles into a longer video. This allows moving forwards and backwards in the video stream while using standard HTTPS.

HLS and MPEG-DASH, the most popular streaming formats.

https://en.wikipedia.org/wiki/HTTP_Live_Streaming

https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_ove...

That's why MPEG defines "I", "B", and "P" frames (well, one of the reasons).

Downloading is more reliable than streaming

Storage space has become so inexpensive. Memory, too. I have enough RAM to store anything I download for the short term.

I will always prefer downloading

Is there actually any browser that could store streaming content before displaying it, after all decoding etc?

Well, there is yt-dlp, if you count that as a browser. It has hacks for downloading from nearly every website that has weak DRM. It also has a fallback for guessing how to download from arbitrary websites.

"after all decoding" isn't desirable because then you have to re-encode it, incurring generation loss.

If you mean drm'd content, I think that's hopeless now, the security is at the hypervisor level nowadays. I can't even play that content on my old vga monitors. For the average youtube video, I don't see why not in principle.

This had to be said?

Shouldn't it've been said?

Lovely article, when discussing streaming and downloading, we should ignore the transport, it's not relevant to the definition.

Downloading is a superset of streaming.

Low-level streaming is the process of transferring data, between CPU and RAM, between RAM, controller and mass storage device, between machines connected to the internet.. The data is streamed, it's sent serially, it's a stream of data.. (the width of the lake does not matter, if the entire thing does not arrive at once, it's streaming).

Low-level loading is the process of loading something down to a computer, meaning, something is loaded, if it's loaded, it's stored _SOMEWHERE_, it could be stored simply in RAM (the LOAD instructions in the cpu place a value into a storage location, a high-level use of the word could be LOAD command in BASIC which streams data from somewhere into some location in RAM for medium-term usage).

When you're viewing a video without saving it to file, we call it streaming, it fits the metaphor, even if _chunks_ of the video are DOWNLOADED into temporary storage, the entire video is not (intentionally at least, but if it's small it might be) stored as a whole before being presented, so from a high-level perspective, the video is streamed. If the data is not persisted, it's streamed.

High-level use of the word streaming fits the low-level metaphor, the process is: Stream data from content provider to client, client loads enough data to start presenting, client presents loaded data while new data is streaming into it, that data is immediately loaded in buffers, after data has been presented, it is discarded.

Downloading is a different word from loading, but it historically fits the metaphor, when a computer requests data from another computer, it pulls the data "down" from the other computer (as opposed to "up" from mass storage), and into some medium-term storage location, often RAM (when you browse a website your browser downloads the data into memory, the medium means it can't automatically discard after presenting, because it does not know when presentation is done, it may even cache some of the data it downloaded on mass storage).

The newer use of download is a slight misnomer, but only slight, the intention is to keep the file for long-term use, so it is streamed into memory buffers before being saved to disk.. "Saving" would be a more appropriate term, the distinction where it is saved FROM is not as important anymore as people used to think.

tldr:

Low-level streaming: Transfer data sequentially. High-level streaming: Transfer data sequentially, present as needed, reclaim storage.

Downloading: low-level streaming into long-term storage.

TLDR: streaming goes into cache downloading into storage

Reply on news.ycombinator.com