Ultra-High-Definition Quality Experience with MPEG-DASH Streaming | Hacker News Reader

Ultra-High-Definition Quality Experience with MPEG-DASH Streaming

bitmovin.net

10 pointsslederer23 comments

DASH is cool in terms of technology and cost saving, but as end-user experience, it's super bad. I just wanna constant quality, full length video buffered to my local and after that I start watching uninterrupted! Who the fuck want to watch a 720p video and then BOOOOOM 240p. It's really frustrating.

Some people would prefer scaled down quality instead of stuttering when watching eg. live streams or on-demand movies (and not have to wait for download to finish).

For live streams, yes, DASH might be super useful.

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.

DASH is just a format, you can use it however you like, e.g. prebuffering parts or the whole movie ... that's the flexibility of an open standard. there are a lot of open source players or also commercial ones such as www.dash-player.com, which exactly enable this flexibility.

and other people live outside of third world US internet bubble and have access to modern networks with no data caps and decent speeds.

That's not streaming, that's a download.

Watch a partially downloaded video while downloading is called streaming.

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

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.

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.

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.

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.

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

I didn't mean bit like "bit", I meant a piece. (I thought I fixed that before I posted, oops.) I just double-checked and that's exactly how it works. Each representation is divided into media segments, essentially the chunks of data that all HTTP-based adaptive streaming technologies use. Data chunks can be presented in discrete files, as in HLS, or as byte ranges in a single media file. http://www.streamingmedia.com/Articles/ReadArticle.aspx?Arti...

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.

The vast majority of the time HTTP runs over TCP so there not exactly unrelated. Yes, most programmers tend to ignore things below a given level of abstraction, but that's hardly safe. However, you see the same thing on several different protocols and it was really just used as a simplified example.

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.

afaik nothing stops you just downloading highest quality DASH stream, I do it with YT everyday.

If you use a good player with a good adaptation algorithm, it will not switch from 720p to 240p ... of course poor players will do that. But a good player implementation will rather switch from 720p @ 3 Mbps to 720p @ 1.5 Mbps if the bandwidth decreases ... so the quality difference is really limited but the video continues to play without a problem. we've a lot of demos where you can try it out yourself at http://www.dash-player.com/demo as well as http://www.bitcodin.com/live-streaming/

Is it better than Pied Piper, which is lossless?

A more relevant comparison would be HLS, Apple's HTTP Live Streaming tech, which works really well but is not very widely supported.

There are over 800 million devices that support it.

Works really well, yes, but it has considerable latency for real time video.

Apple's HLS and MPEG-DASH share the same design principles. One big benefit of MPEG-DASH is that it is supported natively within HTML5 using the HTML5 Media Source Extentions. However, today HLS and MPEG-DASH are used in common.

DASH is more a protocol to make many quality levels available in a single stream in a standard way. You could add a Pied Piper track to a DASH stream easily.

Reply on news.ycombinator.com