3 ms·

Watch a partially downloaded video while downloading is called streaming.

by est 11y ago

sp332 11y ago
Streaming is real-time. A download is to watch later. The main difference in use is that you want a stream to have very low latency, while for a download it doesn't matter much. YouTube in particular has been working on time-to-first-frame and reducing stutter. If it takes 5 minutes to start watching a YouTube video, or to skip around in a video, people will leave and do something else because that is super frustrating. YouTube will use the highest video quality that your connection can handle in real-time. Edited first bit for clarity
- Retric 11y ago
  Streaming does not need low latency connections. 1 second is huge latency, but a trivial wait time. Second, buffering full HD quality for 30+ minutes while watching HD video is well within most users’ internet connection capability. Streaming services rarely do this to save money when a user stops watching mid video. But, at a technical level your connection should get saturated until the video is fully downloaded instead of micro managing a tiny buffer. Finally, for services like Netflix with limited catalogs and the ability to predict what a user is going to watch they can easily download 1 minute and in HD from the most popular videos ahead of time or a smaller buffer for every video. This would create a fairly massive buffer to start with, but again nobody does this. PS: Hulu apps can even go further and pre download commercials.
  - sp332 11y ago
    Why download more than you need? If your connection can handle real-time HD video then it won't stutter. est is talking about when you force YouTube to playback a higher resolution (under the gear icon) and then it doesn't buffer enough to keep up when you play.
    - Retric 11y ago
      Internet connections are not stable. If you try to send exactly 1Mbps on a 30Mbps you will end up with less than 1Mbps of data. If you flood a 30Mbps connection you might get 10-30Mbps, but that's so far above the 1Mbps you’re looking for it's not an issue. Edit: Another factor with large buffers, if you replay a second there is no need to re download that data, but the vast majority of services force you to download again. PS: I have seen 100Mbps connections that can sustain 80+Mbps download just fine fail to keep a low latency 25kbps connection. The solution as odd as this sounds was to simply flood multiple copies of the same data.
      - sp332 11y ago
        If you try to send exactly 1Mbps on a 30Mbps you will end up with less than 1Mbps of data. Doesn't DASH completely fix this? You download one bit [edit: piece, not "bit"] of a video at max speed, then it just waits a bit and then grabs the next bit [piece] at max speed. So the average is maintained at "real-time" speed. Edit: anyway this is irrelevant to est's case.
        Retric 11y ago
        DASH? No. Anyway, a bit is a fraction of a packet, so the download speed is more or less irrelevant. For TCP/IP you want several sets of ACK packets, which can be a fair amount of data, before you try and guess a line speed. You can do Quick Start etc., but the protocol is designed around maximizing transmission speeds not a steady download rate. You don’t need to stick with TCP/IP, but that opens up a huge can of worms which is more often than not handled poorly. PS: To simplify; a lot of things are designed around maximizing total bandwidth. Clever buffering strategies are really important to pulling this off and many of those strategy's fail when someone is slow to fill up a buffer. A simplified example: You send a 3k, packet the network is designed for 2k packet’s so it breaks that 3k packet up sends 2k, buffers 1k and waits for your next packet. Your client on the other end expects 3k of data, that times out and it asks for you to resend... network gets 3k so it sends the last 1k and 1k of redundant data. Meanwhile the client things it must have a really slow connection even though requesting more data would speed things up. Note: There are a lot of ways this example could go. The network might give up on getting more data and send a 1k packet which adds high latency to your connection as you always need to wait for that timeout. Consider, Wi-Fi connection > local network > home router > cable system > cable network > ...

Watch a partially downloaded video while downloading is called streaming.

by est 11y ago

Watch a partially downloaded video while downloading is called streaming.

sp332 11y ago

Streaming is real-time. A download is to watch later. The main difference in use is that you want a stream to have very low latency, while for a download it doesn't matter much. YouTube in particular has been working on time-to-first-frame and reducing stutter. If it takes 5 minutes to start watching a YouTube video, or to skip around in a video, people will leave and do something else because that is super frustrating. YouTube will use the highest video quality that your connection can handle in real-time. Edited first bit for clarity

Retric 11y ago
Streaming does not need low latency connections. 1 second is huge latency, but a trivial wait time. Second, buffering full HD quality for 30+ minutes while watching HD video is well within most users’ internet connection capability. Streaming services rarely do this to save money when a user stops watching mid video. But, at a technical level your connection should get saturated until the video is fully downloaded instead of micro managing a tiny buffer. Finally, for services like Netflix with limited catalogs and the ability to predict what a user is going to watch they can easily download 1 minute and in HD from the most popular videos ahead of time or a smaller buffer for every video. This would create a fairly massive buffer to start with, but again nobody does this. PS: Hulu apps can even go further and pre download commercials.
- sp332 11y ago
  Why download more than you need? If your connection can handle real-time HD video then it won't stutter. est is talking about when you force YouTube to playback a higher resolution (under the gear icon) and then it doesn't buffer enough to keep up when you play.
  - Retric 11y ago
    Internet connections are not stable. If you try to send exactly 1Mbps on a 30Mbps you will end up with less than 1Mbps of data. If you flood a 30Mbps connection you might get 10-30Mbps, but that's so far above the 1Mbps you’re looking for it's not an issue. Edit: Another factor with large buffers, if you replay a second there is no need to re download that data, but the vast majority of services force you to download again. PS: I have seen 100Mbps connections that can sustain 80+Mbps download just fine fail to keep a low latency 25kbps connection. The solution as odd as this sounds was to simply flood multiple copies of the same data.
    - sp332 11y ago
      If you try to send exactly 1Mbps on a 30Mbps you will end up with less than 1Mbps of data. Doesn't DASH completely fix this? You download one bit [edit: piece, not "bit"] of a video at max speed, then it just waits a bit and then grabs the next bit [piece] at max speed. So the average is maintained at "real-time" speed. Edit: anyway this is irrelevant to est's case.
      - Retric 11y ago
        DASH? No. Anyway, a bit is a fraction of a packet, so the download speed is more or less irrelevant. For TCP/IP you want several sets of ACK packets, which can be a fair amount of data, before you try and guess a line speed. You can do Quick Start etc., but the protocol is designed around maximizing transmission speeds not a steady download rate. You don’t need to stick with TCP/IP, but that opens up a huge can of worms which is more often than not handled poorly. PS: To simplify; a lot of things are designed around maximizing total bandwidth. Clever buffering strategies are really important to pulling this off and many of those strategy's fail when someone is slow to fill up a buffer. A simplified example: You send a 3k, packet the network is designed for 2k packet’s so it breaks that 3k packet up sends 2k, buffers 1k and waits for your next packet. Your client on the other end expects 3k of data, that times out and it asks for you to resend... network gets 3k so it sends the last 1k and 1k of redundant data. Meanwhile the client things it must have a really slow connection even though requesting more data would speed things up. Note: There are a lot of ways this example could go. The network might give up on getting more data and send a 1k packet which adds high latency to your connection as you always need to wait for that timeout. Consider, Wi-Fi connection > local network > home router > cable system > cable network > ...