- From: Francois Daoust <fd@w3.org>
- Date: Fri, 12 Jun 2015 12:20:46 +0200
- 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