Re: TV developer meetup notes (Tokyo)

[CC-ing MultiDevice Timing CG due to common interests]

Hi Daniel and all,

Excellent to see lots of interesting discussions, some of which are of
course very much related to timing issues.  I'd like to address some of
these here, and suggest that anyone interested take a closer look at the
web timing group: https://www.w3.org/community/webtiming/

The notes mention that "HTML5 lacks a built-in cue system/task scheduler
with a high degree of precision that can accept triggers from a variety of
sources."  We have built something we call a "scheduler" (a.k.a.
MovingCursor), which is basically a sort of generic track element connected
to an HTMLTimingObject suggested by the webtiming group.  It provides a
fully dynamic way to trigger events or spans (data having a non-zero
range).  The dataset is fully dynamic and can be changed at any time.  It
emits "enter" and "leave" events with millisecond precision, and is fully
written in JavaScript.  When the HTMLTimingObject changes or the dataset
changes, "enter" and "leave" events are provided to ensure a consistent
view.  In other words, the programmer needs only handle these two event
types regardless of playback, skips, pauses etc.  To see a brand new, fresh
demonstration (both a video for your convenience and links to the actual
running version), see:
https://www.w3.org/community/webtiming/2015/04/08/timed-data-and-multi-device-playback/

The HTMLTimingObject should solve most other timing issues mentioned - it
is a fairly simple construction only tasked with correct timing.  It is of
course also designed to integrate with Shared Motion, to ensure native
multi-device support.  We have just published the first draft of the
HTMLTimingObject, so any feedback and participation in discussions is
highly welcome!
https://www.w3.org/community/webtiming/2015/03/27/draft-htmltimingobject/
An implementation of Shared Motion and necessary support infrastructure is
also available by the MotionCorp, so if anyone wants to test it, please
feel free at http://dev.mcorp.no/

It is important to understand that the HTMLTimingObject only addresses
timing - so you could envision multiple ways to use it in a
broadcast/hybrid broadcast scenario.  One would be to support some
buffering and timed playback on the clients and synchronize them to a
"broadcast motion".  We have demonstrated this for live radio on
https://www.w3.org/community/webtiming/2015/03/11/35/

A different approach would be to get some sort of timing information from a
broadcast stream (e.g.a trigger or Audio Fingerprint), then use that
information to set the client's personal position in the stream, i.e. set a
personal Shared Motion based on the broadcast stream.  This would allow
high precision synchronization of all second screens (or any additional
stream or timed data) that can be controlled.  The precision will be
limited to the precision of the extracted timing information.

We did a report on our implementation of Shared Motions, showing that the
precision for HTML5 audio (multi-device, running Chrome on Linux, different
network technologies) to be at around a single ms.  For video, using Chrome
and Firefox, still multi-device, we're at about 7ms.  On Android (Firefox),
we are around 7ms, even when using the 3G network.    Report avilable here:
http://mcorp.no/publications/dist_html5_sync_2014.pdf

We hope any interested parties join the Multi-Device Timing CG, as it
addresses both single and multi-device timing issues.  And of course,
developers getting first hand knowledge will be even better at providing
feedback, so we also suggest testing it!

Best regards,
Njål Borch


---
Dr. Njål Borch
Senior researcher
Norut Tromsø, Norway

On 31 March 2015 at 11:16, Daniel Davis <ddavis@w3.org> wrote:

> [CC-ing Web and TV IG because of wider relevancy]
>
> Hi all,
>
> As mentioned on the last TV API conference call, earlier this month we
> had a TV developer meetup here in Tokyo and our group spent a day going
> through the requirements of the TV Control API, comparing them with
> other specifications. In the case of Japan, this was mostly a comparison
> with Hybridcast and HbbTV.
>
> The notes from that discussion are here and thanks to Yosuke for the
> clean-up:
> https://www.w3.org/2011/webtv/wiki/DevMeetupTokyo/Standards_for_TV
>
> Most of the points we've already discussed in the call but feel free to
> comment on or ask about anything on the mailing list.
>
> With regards,
> Daniel Davis
> W3C
>
>