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

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

From: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
Date: Fri, 6 Feb 2015 09:06:42 +0100
Message-ID: <CAOFBLLpHgDwQ-d6NAddtmwr5wpW-pNwy1cGKGxPQ1mnyHvq3XA@mail.gmail.com>
To: Ryoichi Roy Kawada <roy.kawada@w3.org>
Cc: public-webtiming@w3.org
Hi Roy.

Thanks!

You are indeed correct.

Furthermore, if a system for digital signage is based on web-based
multi-device timing - there are ample opportunity for further innovation.

- it's not only video that can be remote controlled with ms precision -
anything web - including timed announcements, photos, maps, animations and
what not.

- interaction can be added to it - e.g. allowing by-passers to remote
control the signage in some way - URLs for controls can be transferred by
QR code or similar.

- you can start to exploit precise timing in the design of signage content
for effect such as this https://www.youtube.com/watch?v=tdQgsmYKxLM, or
maybe ensure a specific timing pattern between nearby signage.

- you can have different signage variants (different screen sizes or touch
support or similar) but have them share the temporal cues

- you may update/author the signage live from a authoring web page without
disrupting the presentation (change spelling error or update prices or
whatever)

- if you want to go crazy - you could even have the visual signage follow
the beat of some music delivered by a web-enabled PA system or similar.


By the way. We are using multi-device timing regularly as a basis for
web-based multi-device slide-showing - which from a technological point of
view is exactly the same as controlling such a multi-device web-based
digital signage system. We'll probably make use of that once we get around
to do a first telco in this community group.

Best, Ingar



2015-02-06 6:48 GMT+01:00 Ryoichi "Roy" Kawada <roy.kawada@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?
>
> Best,
> Roy
>
>
>
> 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
>        roy.kawada@w3.org
> -------------------------------------
>
>
Received on Friday, 6 February 2015 08:09:27 UTC

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