[timingobject] Timestamps on update requests

ingararntzen has just created a new issue for 
https://github.com/webtiming/timingobject:

== Timestamps on update requests ==
In section 7 the spec defines TimingStateVectorUpdate as parameter for
 the update method and for constructor of the timing object. This 
parameter includes position, velocity and acceleration, but not a 
timestamp. The implied semantic is *update now/asap*, leaving it to 
the timing object or the timing provider to supply the exact 
timestamp. This is fine for interactive usage, such as *pause now* or 
*play now*. 

However, there are some cases where we want to let the application 
provide the timestamp.

A typical scenario is master-slave media synchronisation, where slave 
devices (e.g. smart phone) are supposed to be synchronised to a master
 media player (e.g. video on STB/smart TV). The timing object supports
 this scenario. The master will essentially control the timing object 
(i.e. updating playback position on the timing object - or adjust 
velocity) whereas slave components will slave to the same timing 
object (i.e. read-only). In this situation, synchronisation with the 
master will be much better if the master can supply a timestamp with 
the vector.

Another way to think about the update timestamp is as a scheduling 
target. For instance, by assigning a timestamp in the future, the 
application may have a simple mechanism for delayed updates - provided
 this is supported by the timing provider. This is an elegant way of 
masking latency differences in interactive commands. For instance, 
start playing from position 0 in 0.7 seconds. All client devices that 
receive the command in time will start playback exactly at the same 
time. Those that didn't get the command in time will join in as soon 
as they get it.

It is also possible to back-date update commands. For instance, start 
playing from position 0 in -1.0 seconds. This simply means that at the
 time the command was issued you will already be about 1 second into 
the specified motion.

In short, timestamps on updates are important and should be included. 
Still, the timestamp should be optional.

Please view or discuss this issue at 
https://github.com/webtiming/timingobject/issues/19 using your GitHub 
account

Received on Tuesday, 23 February 2016 20:02:55 UTC