W3C home > Mailing lists > Public > public-webtiming@w3.org > June 2015

Monotonic clock?

From: Francois Daoust <fd@w3.org>
Date: Fri, 12 Jun 2015 12:20:46 +0200
Message-ID: <557AB27E.9010709@w3.org>
To: public-webtiming@w3.org
Hi all,

Both Media elements and Web animations seem to rely on monotonically 
increasing positions [1] [2], in other words, a clock that is always 
increasing. I wonder whether we should mandate something similar in the 
Timing Object specification, more precisely for the "local timestamp" 
computed for the state vector.

In the online case, the "local timestamp" is computed from the timestamp 
received from the server based on an estimation of the local clock's 
skew against that of the server. When that estimation changes, the 
conversion can return a local timestamp that lies in the past of the 
last one, thus breaking the monotonicity.

Forcing the local timestamp to be monotonic would entail that the 
position of the timing object is also monotonic in the absence of state 
vector updates.

In turn, this could perhaps help integrating the timing object with Web 
Animations and Media Elements.

Note that there are different ways to create a monotonic (I think the 
Media State Vector paper references a couple) and I'm not suggesting to 
mandate a particular mechanism.

Is it needed, useful, too early to tell? I confess I do not know whether 
using a monotonic clock is a must in most cases, a nice-to-have or 
something that is only ever required in specific cases, so apologies if 
the idea is essentially dumb...

Francois.

[1] http://w3c.github.io/web-animations/#global-clock
[2] 
http://www.w3.org/html/wg/drafts/html/master/semantics.html#playing-the-media-resource
Received on Friday, 12 June 2015 10:21:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:25:14 UTC