Report from presentations at W3C TPAC 2015

Hi all,

As planned, I presented the TimingObject specification to different groups at W3C's TPAC last week in Sapporo:

Web and TV IG:
- slides: https://www.w3.org/2015/Talks/fd-timing-tpac-webandtv/
- minutes: http://www.w3.org/2015/10/25-webtv-minutes.html#item16

Breakout session on cross-device synchronization:
- slides: https://www.w3.org/2015/Talks/fd-timing-tpac-breakout/
- minutes: http://www.w3.org/2015/10/28-sync-minutes.html

Digital Signage Business Group:
- slides: same as for Web and TV IG
- minutes: http://www.w3.org/2015/10/29-websigns-minutes.html#item11

I also raised the topic in side discussions with a few people whom I thought might be willing to have a look at the spec.

Overall, the topic is of interest for a number of persons from different horizons (audio, media, accessibility, digital signage, connected objects/sensors), which is a good thing. Feedback I received was either positive or constructive.

The main concern I heard was around the difficulty to harness the media renderer in user agent implementations in practice. Depending on the codec and platform, that rendering may be done directly by the hardware, following its own clock, or handled by some third-party code, not directly running in the same context as the rest of the code. Also, regardless of who developed the code, it seems some implementations struggle to preserve the timeline and clock across process boundaries.

Now, while perhaps imperfect, native support can only do better than what we already manage to achieve in JavaScript, which should be enough for all use cases considered. Also, the same sort of issue arises for Web Audio API implementers as they consider the possibility to output audio to two different sound cards at once (on a single device), each sound card following its own clock.


Here are the main questions/suggestions/comments that were raised during discussions (and that I remember), in no particular order:

1. Why not expose NTP to Web apps? In particular, the Digital Signage Business Group is considering the development of an NTP Client API.

2. The TimingProvider object could perhaps benefit from being split into two: one part that handles the clock synchronization and the other part that handles the state vector. This would make it possible to connect to two third-parties for both services or to rely on some existing clock synchronization mechanism, typically NTP. This would also be consistent with e.g. the way the DVB TM-CSS group separated the Wall-Clock (WC) protocol and the Timeline (TS) one.

3. Some use cases will want UI responsiveness to take precedence over synchronization: when the user clicks on "pause", the app will want the action to occur right away on the local device, no matter if the update takes some time to reach other connected devices. In practice, devices would not necessarily pause at the exact same time, but would be able to resume on sync (or to synchronize themselves gradually).

4. Similarly, it may be acceptable in some cases for a device to get out of sync for a few seconds while buffering occurs and to recover gradually over time. Spec-wise, this would probably require a way to pass a few parameters to characterize the association between a MediaElement and a TimingObject.

5. The possible overlap with MediaController was not a big concern. MediaController should soon be deprecated in practice [1]. Of course, this begs the question as to whether the TimingObject spec can succeed where MediaController fails.

6. I heard people mentioning the need to get down to <1ms for audio speakers on a local network to play correctly. I'm not sure that we can get down to that level of sync in practice.

7. The spec is not clear right now how media buffering is going to work, in particular for live streams that may need to be delayed a bit for synchronization. 

8. Video walls were mentioned several times. That seems like a good use case to add to the list. I don't think it introduces additional requirements.


Thanks,
Francois.

[1] https://github.com/whatwg/html/issues/192

Received on Tuesday, 3 November 2015 15:55:03 UTC