DMApp Synchronisation

 In

Revision for “DMApp Synchronisation” created on 8 July 2016 @ 15:44:12

Title
DMApp Synchronisation
Content
The DMApp Synchronisation solution in 2IMMERSE is a collection of services, protocols and components that enable DMApp components on devices participating in an experience to synchronise to a source of timing information representing the progress of the experience.<blockquote>The temporal progress of the experience is represented by a timeline called the <strong>Synchronisation Timeline</strong>.</blockquote>DMApp Synchronisation in 2IMMERSE seeks to support both <strong>intra-home synchronisation</strong> (also called interdevice synchronisation) and <strong>inter-home synchronisation</strong>. Our solution combines standardised mechanisms for synchronisation-in-the-home (such as <a href="https://www.dvb.org/standards/dvb_css" target="_blank">DVB-CSS</a>) with cloud-based services and proposes new protocols to achieve its distributed synchronisation offering.<h2>Intra-Home Synchronisation</h2>Companion devices synchronise their content playback to a master device e.g. a TV playing a broadcast or IP-delivered stream. All devices reside on the same network and each device instructed by the Timeline Service to load a DMApp Component to play a media object as part of the experience. The main screen (usually the TV, here we assume an HbbTV2.0 device) is instructed to play the master media stream i.e. a video stream representing the TV programme.Interdevice synchronisation in the home is achieved using the HbbTV2.0 Media Synchronisation mechanism (HbbTV2.0 specifications can be found <a href="https://www.hbbtv.org/wp-content/uploads/2015/07/HbbTV_specification_2_0.pdf" target="_blank">here</a>).In this particular context, the synchronisation timeline is the timeline of the master device’s content e.g. the timeline of a TV programme. Provided mappings from the Synchronisation timeline and the DMApp media objects’ timelines are available, the companion devices can synchronise their DMApp components to the master TV.More details on the design of the <strong>intra-home synchronisation</strong> solution are available <a href="https://2immerse.eu/wiki/sync/intra-home-media-synchronisation-design/"><strong>here</strong></a>.<h3>Cloud Services</h3>The Timeline Services causes DMappComponents to be loaded onto the TV and the companion device (via the Layout service). The WallClock Sync service uses a web-sockets-based protocol to establish a common time reference for the Timeline Service and the TV. This is required so that the TV can report the progress of the synchronisation timeline (main media object timeline on TV) to the Timeline Service. In this way, the Timeline Service is informed of the experience progress.[table id=6 /]<h3>TV APIs and Components</h3>These are APIs for components and services made available to an HbbTV web App as JS libraries. [table id=7 /]<h3>Companion APIs and Components</h3>These are native and web-based components and APIs that will synchronise the playback of DMApp components based on timeline updates received from the TV via the DVB-CSS suite of protocols.[table id=8 /]<h2>Inter-Home Synchronisation</h2>In this scenario, devices at different locations synchronise their content playback as part of a distributed synchronised experience. The synchronisation timeline can be one of the following:<ol> <ol> <li>the timeline of an elected master device,</li> </ol> </ol>The timeline used for synchronisation comes from a particular DMAppC component on a device e.g. a DMAppC component on a TV in Home1 playing a broadcast stream. This broadcast stream could provide a TEMI and a PTS timeline to be used for synchronisation.<ol> <li> a timeline set by a central coordinator e.g. an experience timeline as set by the Timeline Service</li> </ol>More details on the design of the <strong>inter-home synchronisation</strong> solution are available <strong><a href="https://2immerse.eu/wiki/sync/inter-home-media-synchronisation/">here</a></strong>.<h3>Cloud Services</h3>The Timeline Service causes DMappComponents to be loaded onto the TV and the companion device (via the Layout service). The WallClock Sync service uses a web-sockets-based protocol to establish a common time reference for the Timeline Service and the TV. This is required so that the TV can report the progress of the synchronisation timeline (main media object timeline on TV) to the Timeline Service. In this way, the Timeline Service is informed of the experience progress.[table id=12 /]<h3>TV APIs and Components</h3>These are APIs for components and services made available to an HbbTV web App as JS libraries. [table id=13 /]<h3>Companion APIs and Components</h3>These are native and web-based components and APIs that will synchronise the playback of DMApp components based on timeline updates received from the TV via the DVB-CSS suite of protocols.[table id=8 /]<h3>dump</h3>The receiver of this message is expected to dump (part of) its internal state to its logging output, for debugging purposes.<ol> <ol> <ul> <li><strong>Publisher:</strong> debugging tools</li> <li><strong>Subscriber:</strong> all</li> </ul> </ol> </ol><strong>Example:</strong> <code class="json">{ "message" : "dump" , "what" : "random string that may influence what is dumped", }; </code>
Excerpt
Markdown content
The DMApp Synchronisation solution in 2IMMERSE is a collection of services, protocols and components that enable DMApp components on devices participating in an experience to synchronise to a source of timing information representing the progress of the experience. <blockquote>The temporal progress of the experience is represented by a timeline called the <strong>Synchronisation Timeline</strong>.</blockquote> DMApp Synchronisation in 2IMMERSE seeks to support both <strong>intra-home synchronisation</strong> (also called interdevice synchronisation) and <strong>inter-home synchronisation</strong>. Our solution combines standardised mechanisms for synchronisation-in-the-home (such as <a href="https://www.dvb.org/standards/dvb_css" target="_blank">DVB-CSS</a>) with cloud-based services and proposes new protocols to achieve its distributed synchronisation offering. <h2>Intra-Home Synchronisation</h2> Companion devices synchronise their content playback to a master device e.g. a TV playing a broadcast or IP-delivered stream. All devices reside on the same network and each device instructed by the Timeline Service to load a DMApp Component to play a media object as part of the experience. The main screen (usually the TV, here we assume an HbbTV2.0 device) is instructed to play the master media stream i.e. a video stream representing the TV programme.Interdevice synchronisation in the home is achieved using the HbbTV2.0 Media Synchronisation mechanism (HbbTV2.0 specifications can be found <a href="https://www.hbbtv.org/wp-content/uploads/2015/07/HbbTV_specification_2_0.pdf" target="_blank">here</a>).In this particular context, the synchronisation timeline is the timeline of the master device’s content e.g. the timeline of a TV programme. Provided mappings from the Synchronisation timeline and the DMApp media objects’ timelines are available, the companion devices can synchronise their DMApp components to the master TV.More details on the design of the <strong>intra-home synchronisation</strong> solution are available <a href="https://2immerse.eu/wiki/sync/intra-home-media-synchronisation-design/"><strong>here</strong></a>.<h3>Cloud Services</h3>The Timeline Services causes DMappComponents to be loaded onto the TV and the companion device (via the Layout service). The WallClock Sync service uses a web-sockets-based protocol to establish a common time reference for the Timeline Service and the TV. This is required so that the TV can report the progress of the synchronisation timeline (main media object timeline on TV) to the Timeline Service. In this way, the Timeline Service is informed of the experience progress. [table id=6 /] <h3>TV APIs and Components</h3> These are APIs for components and services made available to an HbbTV web App as JS libraries. [table id=7 /]<h3>Companion APIs and Components</h3> These are native and web-based components and APIs that will synchronise the playback of DMApp components based on timeline updates received from the TV via the DVB-CSS suite of protocols.[table id=8 /]<h2>Inter-Home Synchronisation</h2> In this scenario, devices at different locations synchronise their content playback as part of a distributed synchronised experience. The synchronisation timeline can be one of the following: <ol> <ol> <li>the timeline of an elected master device,</li> </ol> </ol> The timeline used for synchronisation comes from a particular DMAppC component on a device e.g. a DMAppC component on a TV in Home1 playing a broadcast stream. This broadcast stream could provide a TEMI and a PTS timeline to be used for synchronisation. <ol> <li> a timeline set by a central coordinator e.g. an experience timeline as set by the Timeline Service</li> </ol>More details on the design of the <strong>inter-home synchronisation</strong> solution are available <strong><a href="https://2immerse.eu/wiki/sync/inter-home-media-synchronisation/">here</a></strong>.<h3>Cloud Services</h3>The Timeline Service causes DMappComponents to be loaded onto the TV and the companion device (via the Layout service). The WallClock Sync service uses a web-sockets-based protocol to establish a common time reference for the Timeline Service and the TV. This is required so that the TV can report the progress of the synchronisation timeline (main media object timeline on TV) to the Timeline Service. In this way, the Timeline Service is informed of the experience progress. [table id=12 /] <h3>TV APIs and Components</h3> These are APIs for components and services made available to an HbbTV web App as JS libraries. [table id=13 /]<h3>Companion APIs and Components</h3> These are native and web-based components and APIs that will synchronise the playback of DMApp components based on timeline updates received from the TV via the DVB-CSS suite of protocols.[table id=8 /]<h3>dump</h3> The receiver of this message is expected to dump (part of) its internal state to its logging output, for debugging purposes. <ol> <ol> <ul> <li><strong>Publisher:</strong> debugging tools</li> <li><strong>Subscriber:</strong> all</li> </ul> </ol> </ol> <strong>Example:</strong> <code class="json">{ "message" : "dump" , "what" : "random string that may influence what is dumped", }; </code>


OldNewDate CreatedAuthorActions
8 July 2016 @ 15:44:12Rajiv Ramdhany
8 July 2016 @ 15:06:38Rajiv Ramdhany
8 July 2016 @ 14:57:12Rajiv Ramdhany
8 July 2016 @ 14:56:55 [Autosave]Rajiv Ramdhany
8 July 2016 @ 14:45:21Rajiv Ramdhany
7 July 2016 @ 23:10:47Rajiv Ramdhany
7 July 2016 @ 23:08:58Rajiv Ramdhany
7 July 2016 @ 22:54:52Rajiv Ramdhany
7 July 2016 @ 21:33:17Rajiv Ramdhany
7 July 2016 @ 21:30:00Rajiv Ramdhany
7 July 2016 @ 19:49:34Rajiv Ramdhany
7 July 2016 @ 19:47:07Rajiv Ramdhany
7 July 2016 @ 19:02:18Rajiv Ramdhany
7 July 2016 @ 18:55:29Rajiv Ramdhany
7 July 2016 @ 17:34:56Rajiv Ramdhany
7 July 2016 @ 17:24:45Rajiv Ramdhany
7 July 2016 @ 17:17:56Rajiv Ramdhany
7 July 2016 @ 17:11:17Rajiv Ramdhany
7 July 2016 @ 16:46:09Rajiv Ramdhany
7 July 2016 @ 16:37:44Rajiv Ramdhany
7 July 2016 @ 16:33:11Rajiv Ramdhany
7 July 2016 @ 16:25:56Rajiv Ramdhany
7 July 2016 @ 16:16:33Rajiv Ramdhany
7 July 2016 @ 16:09:57Rajiv Ramdhany
7 July 2016 @ 16:04:12Rajiv Ramdhany
7 July 2016 @ 16:00:55Rajiv Ramdhany
7 July 2016 @ 16:00:27Rajiv Ramdhany
7 July 2016 @ 15:56:29Rajiv Ramdhany
7 July 2016 @ 15:40:06Rajiv Ramdhany
7 July 2016 @ 15:09:23Rajiv Ramdhany
7 July 2016 @ 14:59:02Rajiv Ramdhany
18 April 2016 @ 00:42:40Ian Kegel
Recent Posts
Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search