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

Welcome Multi-device Timing! [via Multi-device Timing Community Group]

From: W3C Community Development Team <team-community-process@w3.org>
Date: Thu, 5 Feb 2015 21:42:48 +0000
To: public-webtiming@w3.org
Message-ID: <d4bf62badb56a3bf21b83117753bed88@www.w3.org>
Thank you all for endorsing and joining the multi-device timing group!

To start out with something a bit inspirational, here is a little demo we made
highlighting one of the more trivial use-cases for multi-device timing -
collaborative video.

The demo shows a chrome browser and a firefox browser playing the same video at
the same time. The demo aims to expose current limitations of timed operations
with HTML5.

You will notice that the video is a screen capture, so the two browsers are in
fact running on a single device. However, there is no local communication going
on. The two browsers are completely ignorant of each other. They are only
connected across the Internet, via Shared Motion, our implementation of
multi-device timing. So, running this demo on multiple devices is only a matter
of opening the link on multiple devices.


Some nerdy details below:

It's a horribly difficult video to synchronise due to all the changes in angles,
flashes and hefty rhythms, but we like a challenge.

The video is 30 frames pr second, while our screen (used for screen recording)
refreshes 60 times pr second. Ideally, the browsers should update the frame
shown on the screen every second refresh of the screen.  But. as our browsers
are not synchronised with the video card, we tend to hit the right frame, but
some times at the wrong time with respect to the video card!  So instead of
having both browsers showing frame X in two frames, one will show it first, then
both, then the last one.  This is surprisingly visible with large blinks, large
movements and so on.

We also focus a bit on reloading, as this is important in the Web domain. The
multi-device timing service gives precise timing info within fractions of a
second, but the video needs to spends more time to adjust. We are using
variablePlaybackrate to adjust slowly, as this generally gives the best user

The multi-device timing service is much more precise than the video though, so a
point to take away is that the HTML5 video element is really the weak point here
with regard to precise timing. This is something we would like this CG to

Another point worth noting is that this kind of precision in multi-device HTML5
playback, though feasible, is by no means easy. Our results depends on the
development of specific technical concepts for synchronisation
(MediaStateVectors) as well as dedicated engineering efforts.

However, it should not be that way. This should be easy! With Web support for
multi-device timing all of this complexity should be encapsulated, and
programmers should only have to connect a video with a multi-device media
controller to make this work. That should be about 3 lines of JavaScript.
Incidentally, that is precisely what you'll find in our demo code :)

Ingar and Njål


This post sent on Multi-device Timing Community Group

'Welcome Multi-device Timing!'


Learn more about the Multi-device Timing Community Group: 

Received on Thursday, 5 February 2015 21:42:50 UTC

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