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.
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.