5 ms·

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'

• shmerl 10y ago
  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. See https://en.wikipedia.org/wiki/Adaptive_bitrate_streaming#Adobe_HTTP_Dynamic_Streaming https://en.wikipedia.org/wiki/Adaptive_bitrate_streaming#Ado... 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.
  • Veratyr 10y ago
    > 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. [0]: https://developer.mozilla.org/en-US/docs/Web/HTML/DASH_Adaptive_Streaming_for_HTML_5_Video https://developer.mozilla.org/en-US/docs/Web/HTML/DASH_Adapt... [1]: https://www.encoding.com/mpeg-dash/ https://www.encoding.com/mpeg-dash/
    • shmerl 10y ago
      I see. If that's so trivial however, then why such services like Twitch and others have so many problems switching to HTML5?
      • Veratyr 10y ago
        Twitch needs very low latency streams. For them Flash and something like RTMP might work better. Not sure about others.
  • _puk 10y ago
    > 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. 0: https://tools.ietf.org/html/draft-pantos-http-live-streaming-19 https://tools.ietf.org/html/draft-pantos-http-live-streaming... 1: http://dashif.org/wp-content/uploads/2015/04/DASH-IF-IOP-v3.0.pdf http://dashif.org/wp-content/uploads/2015/04/DASH-IF-IOP-v3....