Reported by n...@wlonk.com, Jan 9 2012
Support MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH), a new industry-supported standard that has been ratified as ISO/IEC 23009-1. DASH has several advantages over other streaming platforms (such as Apple’s HTTP Live Streaming, Microsoft’s Smooth Streaming, and Adobe’s HTTP Dynamic Streaming). Some observers expect the future HTTP streaming landscape to consist primarily of HLS and DASH. Allowed container formats are MP4 and MPEG-2. The standard is codec-agnostic, so webm streams are possible. More: The DASH Promoters Group (http://dashpg.com/?page_id=25) Related: Issue 54198 - Support HTTP Live Streaming (WontFix) Related: Issue 25573 - Add RTSP support to Chrome (WontFix)
Jan 9 2012,
Jan 9 2012,
Feb 11 2012,
Hello. I am curious if there is any update on the DASH example? I'm mostly interested in how the duration information in a DASH initialization segment would be communicated to either Chromium or the video pipeline so that seeking, etc works in a live ondemand feed (something like on-demand transcoding where segments are streaming but the overall duration is known).
Feb 17 2012,
Jul 20 2012,
I also saw an example use of DASH with MediaSource at: http://www-itec.uni-klu.ac.at/dash/?page_id=746
Sep 8 2012,
YouTube MPEG-DASH / ISO BMFF / Media Source demo: http://dash-mse-test.appspot.com/
Sep 10 2012,
Nice demo (comment #6). If the bandwidth is not sufficient for real-time video, it does not wait till the video loads but keeps playing audio. Once the video segments load the video seems to play catch up with audio showing a hurried video - speedier than 1x. Might be a feature of AV sync logic of Chrome. On comment #2, probably this is the demo: http://html5-demos.appspot.com/static/media-source.html. This demo works with webm and with ISO BMFF (with modifications). But still not sure of one thing: If I try playing from the middle by skipping the first few segments (by setting var i = 3 say on line#162), it still plays the entire webm file! I also tried with ISO BMFF the same experiment: loaded the initial segment but skipped few segments after it. It does not play at all. What does the media source API draft (http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html) say about ISO BMFF live feeds and random access? The draft (and DASH standard) seem to mandate initialization segment. Then, I should be able to skip to a random media segment after loading the initialization segment (for random access and also when a new web-client joins an ongoing live session). But as mentioned above this case does not seem to be working in Chrome yet. May be I should read the standard again on how to generate WebM/ISO BMFF segments compatible with Chrome for live streams.
Jan 24 2013,
(comment #7) Were you able to implement a live feed and random access? I'm also interested in allowing a client to join a live session by getting the initialization segment and then some out of order segments.
Jan 24 2013,
(In reply to comment #8) After the initialization segment is apppended, media segments should be appended after compensating for the time stamp offsets. Media Source API provides timestampOffset attribute of SourceBuffer interface for this purpose. The java script should somehow get to know the presentation time (say PTS)of the current media segment and then set the timestampOffset accordingly (timestampOffset = -PTS) before appending. This is one time operation. There appears to be another way also: Instead of compensating the time stamp offset, you can set the currentTime attribute of video element to match with the PTS of current media segment. I did not read the ever-updating MSE draft in recent days. I might have missed the latest changes to the above API.
Mar 10 2013,
Apr 6 2013,
Jul 23 2013,
Jul 23 2013,
Feb 28 2014,
Oct 7 2014,
MPEG DASH JS is implemented and supported in Chrome since <= M37. Example page: http://dash-mse-test.appspot.com/dash-player.html The MSE spec has largely stabilized, and implementation of most of it is complete in Chrome. Remaining major pieces for compliance are support for SourceBuffer.*Tracks and TrackDefaults, as well as allowing sequence appendMode without requiring --enable-experimental-web-platform-features. (Inband TextTrack implementation refactoring will be left as a follow-up issue; it may not fully comply with MSE spec.)
Sign in to add a comment