For on-demand movies, I'd like to it to buffer in advance to a sufficient time length, but don't stutter anymore after that!
Hell I would rather lag for 1 minute for live videos instead of DASH.
I think it boils down to personal habits, would you endure constant small problems with quicker progress, or would rather suffer at the start and enjoy a smooth ride afterwards.
Edited first bit for clarity
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.
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.
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.
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 > ...
TCP is on Layer 4 of the OSI stack, DASH is HTTP which is up on layer 7. Nothing to do with ACKs or Quick Start or fragmentation.
Anyway, for a more detailed answer, DASH is more or less unrelated to the issue. A service that uses DASH and is willing to give clients a huge buffer which is filled up as soon as possible is going to have far fewer issues than a service that uses DASA and tiny buffers.
PS: For a real word example, having a tiny battery and recharging it three times a day vs once would save the company some manufacturing costs. A Roomba is automated so this might not seem like a big deal. But, while it might work most of the time just fine, it still significantly increase the risks it runs out of power.
In the end when watching a streaming service I have gigabytes of ram just sitting there... use them.