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

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

From: Ryoichi \ <roy.kawada@w3.org>
Date: Fri, 06 Feb 2015 14:48:07 +0900
Message-ID: <54D45597.40209@w3.org>
To: public-webtiming@w3.org
Hi Ingar,

Thank you very much for this impressive demo !

So is it possible with this technology to synchronize motion pictures on
multiple web-based signage displays ?

If it is possible, I think digital signage systems like this one <
http://www.signs-d.ne.jp/trendeyes/236.html > can be realized with
web-base, not native application.
Is my understanding is correct?


On 2015/02/06 6:42, W3C Community Development Team wrote:
> 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
> experience.
> 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
> address.
> 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!'
> http://www.w3.org/community/webtiming/2015/02/05/welcome-multi-device-timing/
> Learn more about the Multi-device Timing Community Group:
> http://www.w3.org/community/webtiming

Ryoichi "Roy" Kawada, Dr.Eng.
W3C Fellow from KDDI
Senior Visiting Researcher
Keio Research Institute at SFC
Phone:  +81 3 3516 2504
Fax:    +81 3 3516 0617
Mobile: +81 80 5943 9606
E-mail: kawada@sfc.keio.ac.jp
Received on Friday, 6 February 2015 05:48:43 UTC

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