W3C
Goal is to define a common, multi-device, timing mechanism and a practical programming model for time-sensitive, multi-device Web applications.
(*) sync ≠ instantaneous propagation,
network latency still exists!
A Web app must be able to instruct the user agent to follow an external (*) clock.
(*) from a server, local peer or perhaps media transport stream
... can be achieved in JS (*)
(*) although native support would be better
(and required for UDP-based protocols)
An app must be able to distribute the timeline (*):
At 15:53:29.813
according to the sync clock,
the position is 5.3s
and the playback rate is 1.0
(*) and updates to that timeline, taking into account that
user agents can compute the position on their own:
pos(t) = pos0 + playback_rate * (t - t0)
... can be achieved in JS (*)
(*) typically via a WebSocket connection
Need a way to tell the user agent to use our timeline, and in particular to follow our clock!
... can be somewhat achieved in JS (*)
(*) through skips and continuous adjustments to playbackrate
but support depends on the user agent, codec and platform
and this is more a hack than anything else, right?
playbackrate
was not designed for that
Demos courtesy of Norut / Motion Corporation
interface TimingStateVector {
readonly attribute double position;
readonly attribute double velocity;
readonly attribute double acceleration;
readonly attribute double timestamp;
};
pos(t) = pos0 + velocity * (t - t0) + 1/2 * acceleration * (t - t0)2
Leave the door open to different clock synchronization mechanisms (*)
(*) Provider provides JS library to create TimingProvider
objects.
callback interface TimingProvider {
readonly attribute TimingStateVector vector;
readonly attribute unrestricted double startPosition;
readonly attribute unrestricted double endPosition;
readonly attribute DOMString readyState;
readonly attribute unrestricted double skew;
Promise update(TimingStateVectorUpdate newVector);
};
interface TimingObject : EventTarget {
readonly attribute TimingProvider timingProviderSource;
readonly attribute TimingObjectState readyState;
readonly attribute unrestricted double startPosition;
readonly attribute unrestricted double endPosition;
[attribute EventHandler ...]
TimingStateVector query();
Promise update(TimingStateVectorUpdate newVector);
};
partial interface HTMLMediaElement {
attribute TimingObject timingsrc;
};
When set, the media element would follow the media timeline of the TimingObject
(*) and its associated clock.
(*) real master, no automatic pausing for buffering
var provider = [provider specific];
var timing = new TimingObject(provider);
var video = document.getElementById('vid');
video.timingsrc = timing;
timing.update({ position: 5.0, velocity: 1.0 });
var vec = timing.query();
console.log("pos:" + vec.position + " vel:" + vec.velocity);
interface TimingTextTrack : TextTrack {
attribute TimingObject timingsrc;
};
Same as TextTrack
but no dependency on MediaElement
.
Example at: http://webtiming.github.io/sequencer/
MediaController
?) (*)(*) which may soon be deprecated
... It's complicated
(*) WebRTC-identity-provider-like solution?
(**) although changes are not that huge in practice
... It's complicated
playbackrate
(*) provided the spec is mature enough and the WG created!