Maybe I'm naïve or not seeing something here but DASH looks like something you can do by storing a couple of files somewhere and setting a MIME type [0]?
What's special about DASH that CDNs need to specially support it? Or are you talking about services that handle transcoding video and such as well?
From what I understood, CDN is needed to lift the heavy load from the source servers. Without them you'd be hammered by heavy traffic, and not only that, the route to the end user will be most likely longer.
DASH is adaptive streaming, and as such, when you select some stream from the client, CDN should support that in their infrastructure (including codecs and etc.). I don't know the details exactly, but it's far from trivial. May be someone can explain what the difficulty is in detail.
Currently CDNs support HLS and Adobe's adaptive streaming, both of which aren't open standards and aren't part of HTML5 video.
Without DASH support in CDN, you can't scale your service, and to get rid of Flash and Adobe's adaptive streaming you need DASH + MSE. That's how I understood it at least.
> CDN should support that in their infrastructure (including codecs and etc.)
This makes sense if the CDN is transcoding the video for you but if you do that yourself I don't think a special CDN is necessary.
From Mozilla [0]:
> DASH works via HTTP, so as long as your HTTP server supports byte range requests, and it's set up to serve .mpd files with mimetype="application/dash+xml", then you're all set.
And from encoding.com [1]:
> To play the content, the DASH client first obtains the MPD. The MPD can be delivered using HTTP [...]
> Using this information, the DASH client selects the appropriate encoded alternative and starts streaming the content by fetching the segments using HTTP GET requests.
This definitely sounds like it doesn't need any special support from the server. As long as it can serve files over HTTP, the only special thing is the transcoding and setting up the manifest, which doesn't need to be done by the CDN.
I have a feeling CDNs advertise support for HLS and Adobe's streaming because they require additional support.
> DASH is adaptive streaming, and as such, when you select some stream from the client, CDN should support that in their infrastructure
Adaptive streaming is essentially a client side technology, all the CDN needs to do is ensure that it serves up files with the right mime type (not actually a hard requirement, but many players choke if you don't).
Which segment to play next is decided by the player based on current playback conditions and a manifest of available segments and bitrates; it then requests the relevant segment from the CDN, which delivers it as it would a normal file. (A segment is just a very short video file).
The CDN is not expected to keep state for each connected client, which it would need to in order to be able to make the relevant decisions on which file to serve.
For live, you also have the complication that you need to keep adding files, and updating the manifest to indicate where these new files are (The payer checks back every couple of seconds to see if the manifest has changed). Any latency at all in this means that a client may get back a stale manifest, and then not know where the next video segment is supposed to come from, causing stalling. (Numerous ways to work around this, but it is the real hurdle to easy adaptive live streaming).
This is all a gross simplification, but at its most base level, that is how it works.
You can (theoretically) do MPEG-DASH from a normal MP4 file, but that does require CDN support (and possibly a single pass to add more info at segment boundaries).
> Currently CDNs support HLS and Adobe's adaptive streaming, both of which aren't open standards and aren't part of HTML5 video.
HLS is an open standard[0], though not defined by a standards body; more Apple have documented how they do it and others have adopted it as a defacto standard.
And that is the biggest hurdle for DASH adoption - Apple devices.
As a content provider, I have* to support HLS if I want to support adaptive streaming in iOS. Transcoding to another standard (one which is still in its infancy) is just asking for non essential costs and headaches.
*Yes, it is possible to use MPEG-DASH, but not natively supported by Apple, so you are on your own.
Until Apple support MPEG-DASH you still need to provide a HLS stream.
DASH is a sprawling standard, and in theory you can use DASH with existing HLS segments (MPEG-2 .ts files), but no-one supports it (or likely ever will). DASH264 [1] is an attempt to keep it simple, and tie it down to a smaller subset of codecs (x264/5 and the like), and seems to be making headway.
It's early days for MPEG-DASH, and it is gaining traction, helped by the fact it has been learnt a lot of lessons from the likes of Flash and HLS.
Twitch definitely offers HLS as well; it makes sense to support the current generation of devices, but re-use the tech stack for future standards. Clever peeps.
> As a content provider, I have to support HLS if I want to support adaptive streaming in iOS.
I see. Safari on iOS is still missing MSE? Is Apple doing it to slow down DASH adoption?
The other expected problem is codecs. Apple are being sleazy and refuse to support free codecs like VP9 and Opus. So making DASH serving those won't work with Apple too (unless you'll use pure JavaScript decoder which is very not optimal).
May be Daala / Thor will eventually break their nasty behavior, especially if it will be adopted as mandatory for WebRTC.
> DASH264 is an attempt to keep it simple, and tie it down to a smaller subset of codecs (x264/5 and the like), and seems to be making headway.
Tying DASH to a set of proprietary codecs to propose a standard sounds like a very bad idea. I don't see it going anywhere.
> Apple are being sleazy and refuse to support free codecs like VP9 and Opus.
> May be Daala / Thor will eventually break their nasty behavior, especially if it will be adopted as mandatory for WebRTC.
I think AV1 (Alliance for Open Media's codec) is likely to be the video codec Apple joins in on, unless it tries to push HEVC. With Intel, AMD and ARM in the group, basically every computing device is going to have hardware support for it so Apple would have to actively cripple it in their hardware to go without.
As for audio, Opus is great for low latency and low bitrate but AAC is widely available and supported and performs better than Opus at high bitrates (which I suspect are more important to Apple than low bitrates). Maybe if Opus becomes part of a telecom spec for VoIP or something Apple will pick it up but I think it's unlikely otherwise.
AV1 is the new codename for Daala + Thor? They used to call it NetVC. I hope they'll come up with better name than something that sounds like a virus :)
> As for audio, Opus is great for low latency and low bitrate but AAC is widely available and supported and performs better than Opus at high bitrates
Opus beats AAC even for music from what I saw and provides same quality at lower bitrates. I.e. it has lower transparency level, which means it's simply better overall. See http://listening-test.coresv.net/results.htm
No, AV1 is the name of the codec the Alliance for Open Media is producing. The Alliance for Open Media is a coalition formed by Amazon, AMD, ARM, Cisco, Google, Intel, Ittiam, Microsoft, Mozilla, Netflix and NVIDIA [0]. I don't believe Daala is involved.
> Opus beats AAC even for music from what I saw and provides same quality at lower bitrates.
That test notably omits the proprietary Fraunhofer AAC codec, which may outperform the others.
It also produces results differing from the SoundExpert ratings [1], which show Opus and AAC both achieving transparency around 128K, but with AAC doing it by a more comfortable margin.
> Plus AAC is not free.
Freedom isn't relevant to what will be adopted. The parties in control aren't motivated by freedom.
> Freedom isn't relevant to what will be adopted. The parties in control aren't motivated by freedom.
Oh, they are. It's only the matter of scale and who owns the non-free options. If those who have adopt some codecs need to pay tons of money for non-free ones they start caring about
freedom quite a bit ;)
That's exactly why HEVC shot itself in the foot and will eventually die miserably.
