W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2018

[media-and-entertainment] Globally synchronized playback

From: Jamie Stackhouse via GitHub <sysbot+gh@w3.org>
Date: Tue, 19 Jun 2018 18:29:07 +0000
To: public-web-and-tv@w3.org
Message-ID: <issues.opened-333787945-1529432947-sysbot+gh@w3.org>
itsjamie has just created a new issue for https://github.com/w3c/media-and-entertainment:

== Globally synchronized playback ==
When playing media from a stream source like RTMP, you can more easily get synchronized playback between multiple viewers, however, the infrastructure cost can make these "active" socket streaming technologies cost prohibitive. More and more, we're seeing the CDN networks move away from RTMP, and towards the adaptive HTTP models such as DASH or HLS.

This makes a "room synchronized" playback cost prohibitive, or require a slightly different approach. 

There is an interest we're seeing in the ability to synchronize playback of content in the <video> element based off timing sources like the HLS `#EXT-X-PROGRAM-DATE-TIME`, or DASH's `AvailabilityStartTime`. I had a brief conversation with @chrisn on this, and we discussed which portions could be part of a specification, and what couldn't due to the current playback state for these formats and the reliance on MSE (which is great!).

I thought a little on it, and I think that almost the entire thing could be standardized if the video element added the concept of a `TimeSource`. It could be used to provide a fallback for the wall-clock implementation based on information presented from external sources like hls.js or dash.js. This `TimeSource` could then be used alongside the PTS information available to the <video> element to synchronize playback to a wall-clock.

For example (psuedo code):
video.timeSource = { 
    // converts video currentTime to a wall-clock Date value to return for MSE implementations
    getCurrentDate: function(currentTime) { return dash.wallClock(currentTime) } 
    getTime: function() { return Date.now() } 
    returns the wallclock implementation for DateTime, could be a NTP implementation, 
    or extrapolate from the information in the Dash or HLS stream to return the live edge 
    date, or use something like <UTCTiming> from Dash. 

This would attempt to always bring clients to playing content three seconds from the live edge. There are various techniques that could be applied like varying the playback speed in small increments to bring the user into the time range, but not so much they can hear or see it happening.

Thank you!

Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/5 using your GitHub account
Received on Tuesday, 19 June 2018 18:29:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 19 June 2018 18:29:11 UTC