W3C home > Mailing lists > Public > public-web-and-tv@w3.org > December 2014

Re: Shared Motion - multi-device synchronization and media control for the Web.

From: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
Date: Mon, 15 Dec 2014 23:23:02 +0100
Message-ID: <CAOFBLLo5g2EbJoR4EUgSYNiQ17NoTj2BiiLi6FYWM=+P4b5X-w@mail.gmail.com>
To: Giuseppe Pascale <giuseppep@opera.com>
Cc: public-web-and-tv <public-web-and-tv@w3.org>, Njål Borch <njaal.borch@gmail.com>, Dominique Hazael-Massieux <dom@w3.org>, François Daoust <fd@w3.org>

Indeed, we have been looking closely at the mediacontroller, and it is the
main target for our proposal. I’ll come back to this towards the end.

First, I want to address your concern that, since this already works - it
is not clear why standardization is needed.

It is true that this works, and that Motion Corporation already offers
distributed media control. However, not standardizing this would mean that
future motion providers would design their own similar, but different,
protocols to do essentially the same thing. The result would be that the
ability to synchronize different media would depend on choice of motion
providers. This is an unnecessary dependency, and it would work against
interoperability, extensibility and flexible composition, hallmarks of the

On the other hand, a clear benefit of standardization would be that browser
providers could optimise their implementations of media elements and
controllers thereby actively supporting a wide range of applications
requiring precise, multi-device coordination of linear media. In contrast,
currently multi-device synchronization is a nightmare because browsers all
implement media elements a little differently, and none of them are
appropriately optimised for external media control.

Further evidence to the great value of standardization of media control
comes from the music industry. The MIDI (Musical Instrument Digital
Interface) has served as standard protocol for synchronization during the
last three decades. In this time is has continuously ensured
interoperability between synthesizers, samplers, drum machines, computers,
or even stage lighting and events in theatrical production.

With Shared Motion we are able to escape the great limitation of MIDI -
that it only works for devices in close proximity. This is good for the
music industry, because it means that the Web can now offer global MIDI
(based on Shared Motion). More importantly, it unlocks the value of
interoperability through synchronization and precisely coordinated
execution to the entire Web. This is no small thing.

In short, we think this represents a historic opportunity to define a
common concept of shared media control for the Web, (even before any on the
big ones have started investing in their own concepts). This, we argue,
could secure interoperability of all kinds of linear media and make the Web
into an even greater platform for online media.

Back to the media controller - and what exactly we think is missing.

The media controller is the HTML5 way of synchronizing multiple media
elements. However, crucially, its scope is limited to synchronizing media
elements in the same DOM. We are effectively suggesting to extend this
scope to the Internet, thus enabling multi-device playback, globally.

We have designed Shared Motion specifically with this in mind, to be a
multi-device media controller for Web. Like the current HTML media
controller, Shared Motion does play, pause, rewind etc.  So, in terms of
standardization, our suggestion is (at least conceptually) very simple: we
would like to see the mediacontroller extended with a motion attribute
specifying a source URL for the online synchronization point. Secondly,
we’d suggest standardization of Shared Motion itself, as it has a vast
number of uses that are not related to media elements.

There is a lot more to discuss here, but this short version should work as
a starting point. We are currently laying the finishing touches on a paper
that gives a more complete presentation. We would be happy to share this as
a basis for further discussion.

Best regards,

Ingar Arntzen, Norut & Motion Corporation

2014-12-15 12:22 GMT+01:00 Giuseppe Pascale <giuseppep@opera.com>:
> Hi again,
> to be more specific on my request below, have you looked at this section
> in HTML5? would be good to understand what you think is missing
> http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#synchronising-multiple-media-elements
> On Mon, Dec 15, 2014 at 12:18 PM, Giuseppe Pascale <giuseppep@opera.com>
> wrote:
>> Ingar,
>> thanks for sharing this. As you say, this is already working in browsers
>> without any plugin. Can you expand on what do you think should be
>> standardized and what would be the advantage of standardization VS the
>> library approach you are using today? Have you done an analysis of the
>> HTML5 spec (or other specs) to see what's missing and what would need to be
>> added?
>> cheers,
>> /g
>> On Fri, Dec 12, 2014 at 1:50 PM, Ingar Mæhlum Arntzen <
>> ingar.arntzen@gmail.com> wrote:
>>> Dear IG Members
>>> We would like to present ourselves to this forum, as we share your
>>> interest in improving the Web as a platform for broadcast and multi-device
>>> media, and because we have some contributions which you might find relevant.
>>> My collegue (Njål Borch) and myself (Ingar Arntzen) are researchers
>>> working for NORUT (Northern Research Institute), Tromsø, Norway. Over the
>>> last couple of years we have focused on timing, synchronization and media
>>> control in multi-device media. Currently NORUT is in charge of the
>>> workpackage that deals with this topic in MediaScape, a FP7 EU project
>>> aiming to provide a fundament for multi-device Web applications. The
>>> consortium includes BBC R&D, Vicomtech, IRT, NEC, NORUT, BR and W3C.
>>> To the point: We have invented and developed the concept of  "Shared
>>> Motion", a generic mechanism for synchronization and media control in
>>> time-sensitive, multi-device Web applications. This mechanism has already
>>> been included as fundamental component in the multi-device architecture
>>> explored within the MediaScape project.
>>> To give you a rough idea what this is about:
>>> - Shared Motion synchronizes *globally*, thus multi-device
>>> synchronization is not limited to Intranet or specific network carrier.
>>> - Shared Motion synchronizes across Internet with errors < 10ms, and
>>> works fine even under poor network conditions (e.g. edge - albeit a modest
>>> reduction in precision may be expected)
>>> - Shared Motion works in any modern Web Browser, no plugins required.
>>> - Shared Motion is highly scalable, turning the synchronization of a
>>> million companion devices into a realistic scenario.
>>> - Shared Motion has been made available for public use by start-up
>>> company Motion Corporation. motioncorporation.com
>>> Please find enclosed an internal report documenting that Shared Motion
>>> synchronizes HTML5 Video across Internet, using unmodified Chrome and
>>> Firefox browsers, with end-to-end synchronisation errors in the order of
>>> 10ms (i.e., well below frame-rate).
>>> Note also that the enclosed report includes links to a demo allowing you
>>> to verify this for yourselves.
>>> Concerning our interests:
>>> We have identified the concept of Shared Motion as a huge enabler for a
>>> wide variety of web-based multi-device applications, and we want it
>>> (eventually) to become an open standard and included into the Web as a
>>> principal component in web-based, multi-device applications.
>>> Furthermore, we have identified the WEB+TV IG as a means of bringing
>>> this technology to the attention of the W3C community. The W3C
>>> representatives in MediaScape has recommended this group, and we have also
>>> noted that Shared Motion solves many of the use cases you have already
>>> outlined in this forum.
>>> So, if you deem this relevant for the group, we would be happy to enter
>>> this group and of course discuss this further,
>>> Best regards,
>>> Ingar Arntzen and Njål Borch, Norut and Motion Corporation
Received on Monday, 15 December 2014 22:23:31 UTC

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