[HN Gopher] The Difference Between Downloading and Streaming
___________________________________________________________________
The Difference Between Downloading and Streaming
Author : kruemmelspalter
Score : 59 points
Date : 2025-05-26 19:56 UTC (3 hours ago)
(HTM) web link (danq.me)
(TXT) w3m dump (danq.me)
| schoen wrote:
| 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.
| treyd wrote:
| > 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.
| charcircuit wrote:
| >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.
| schoen wrote:
| 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).
| charcircuit wrote:
| 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.
| Terr_ wrote:
| 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.
| svggrfgovgf wrote:
| >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.
| rlpb wrote:
| > 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.
| pashky wrote:
| 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.
| wood_spirit wrote:
| (For music etc, the difference is licensing. It's not a technical
| distinction, it's a business one.)
| dijksterhuis wrote:
| (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.
| mxfh wrote:
| 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.
| charcircuit wrote:
| >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?
| haiku2077 wrote:
| Does it matter? 4K content only requires 2.2 and there isn't
| really enough native 8K content to justify buying gear for 8K.
| charcircuit wrote:
| 2.2 hasn't been cracked either.
| kevincox wrote:
| 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.
| ryandrake wrote:
| 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.
| wmf wrote:
| Just lie to those people.
| marcosdumay wrote:
| 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_.
| yapyap wrote:
| TLDR: streaming goes into cache downloading into storage
| Animats wrote:
| 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.
| slt2021 wrote:
| 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...
| voilavilla wrote:
| That's why MPEG defines "I", "B", and "P" frames (well, one of
| the reasons).
| voilavilla wrote:
| >> 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..
| SpaceNugget wrote:
| 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.
| lukax wrote:
| 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
| haddr wrote:
| Is there actually any browser that could store streaming content
| before displaying it, after all decoding etc?
___________________________________________________________________
(page generated 2025-05-26 23:00 UTC)