Follow up with ATSC

Dear all,

I am preparing a reply to ATSC to follow up their response to our liaison [1]. Do you have any comments or feedback on the following e-mail? I'd like to send the reply in the next few days if possible.

Thank you all for your input.

Kind regards,

Chris

[1] https://lists.w3.org/Archives/Public/public-tvcontrol/2017Feb/0020.html

---

Dear Mike,

Many thanks for your reply. I am keen to keep an ongoing dialog with ATSC.

I'd like to consider the specific points you made in turn.

> The ATSC group chartered to work on this is TG3/S34-4, drafting ATSC 
> Standard A/344. In a recent meeting, it discussed your liaison and the work of the WG.
> ATSC has so far been a bit reluctant to engage in the activity since:
>
> * The TV Control interface is based on a different architecture which, 
> specifically, does not include a notion of distributed receiver 
> components, and as a result, our use of the Web RPC over WebSocket is 
> architecturally disjoint from the W3C approach.

It's true that we have focused on a single receiver/player architecture rather than a distributed approach. Our goal so far has been to work on closer integration of broadcast content with the video support in HTML. We believe this reduces the need for custom browser APIs to support media playback control, as used in some other TV device standards.

The W3C's Technical Architecture Group also raised a similar point about using a RPC mechanism (https://github.com/w3c/tvcontrol-api/issues/24). We have not followed this approach so far, partially because this is a different goal to the one we started with, but (more importantly) that the active participants in the Working Group have not advocated for so far.

The Working Group is certainly open to working on distributed receivers, and we can change our approach based on member requirements and contributions.. It may be that the two approaches are not incompatible: an RPC mechanism could be implemented on top of the TV Control API, or indeed the TV Control API could be designed directly using an RPC mechanism.

> * ATSC has carefully considered the time gap between acquisition of 
> the broadcast channel and the launch of the application, and has come 
> up with a solution to avoid unnecessary delay in rendering the TV 
> signal by specifying the receiver media player (RMP).  This has been 
> accomplished while still adhering to W3C standards, and avoids "dead air"..

This is an issue that has not been fully considered yet in the W3C group, but I believe it could be also achieved in the TV Control API.

> * The Receiver Media Player (RMP) concept arises from the fact that TV 
> receivers capable of supporting interactive content also render audio 
> and video independently from any broadcaster application, and not all 
> digital services will have accompanying applications. Furthermore, TV 
> receivers utilize advanced video signal processing silicon to enhance 
> picture quality and perform operations such as frame rate doubling and resolution up-scaling.
> While this works for broadcast video, current receiver architectures 
> do not typically offer the same enhancements to video rendered by the browser.
> Generally, the RMP is the preferred video rendering engine.

W3C would be interested in discussing how to bring these advanced video processing capabilities to the Web, to enhance the support for TV content through the browser video engine.

The group identified three types of applications that could make use of the TV Control API (https://www.w3.org/wiki/TV_Control/Application_Types). For rendering of the main video, the TV Control API could be used to control a full-screen video element, and broadcasters would be presented in a separate browsing context.

> * The ATSC runtime has been defined so that either an RMP or an 
> application media player (AMP) such as one that incorporates the 
> DASH.js library would be able to allow for application-directed 
> customized content (usually based on media-timed triggers).

The TV Control API includes a TVTriggerCue interface to support media-timed triggers. These would be exposed through the TextTracks associated with a media element. This area of the specification needs more work, certainly.

> Any standardized API would need to support the above requirements.
>
> Additionally, there are some non-technical concerns:
>
> * The ATSC runtime environment has been defined with the goal of using 
> popular commercial web runtime engines with preferably no modifications.
> As such we would be anxious to learn of multiple interoperable browser 
> implementations of the TV Control API, preferably in an open-source 
> web runtime engine.  Having to extend or modify the commercial web 
> runtime engines would defeat the benefits of embracing a common API.

At present there are no open-source implementations, but we believe W3C is the right forum in which to influence the major Web runtime engines, and hope that this could be achieved with industry support.

At W3C we are interested in developing a solution that works globally, therefore across different broadcast systems. We have also started a discussion with HbbTV and are open to other industry groups.

I understand the desire to minimise the changes that need to be made to web runtime engines, and recognise that the approach we've taken would require closer integration between the browser and the native video rendering.

However, as I already mentioned, the group is open to other industry requirements and considering different approaches, and so we are keen to encourage wider participation in the Working Group.

> * ATSC A/344 is currently an ATSC Candidate Standard (CS is roughly 
> equivalent to the W3C document state of the same name) and is targeted 
> to go to Proposed Standard (PS) perhaps as early as April 2017. It is 
> publicly available at [1]. Our understanding is that the W3C TV 
> Control is just getting started on the Recommendation track. ATSC 
> would need a stable published specification in the April 2017 timeframe.

You're right that the TV Control API will not be at the level of stability needed by ATSC in that time. We would need contribution and input from ATSC members to move the work forwards.

We have just issued a call for review to W3C members of an updated charter to continue work on the TV Control API, and we would like to those ATSC members who are also W3C members to show support for re-chartering of the group, and also become active contributors. Without this, our group is unlikely to be able to re-charter.

> In general, commercially popular, standardized W3C technology is the 
> foundation of our runtime environment and ATSC is very interested in 
> keeping an open dialog with W3C. ATSC would be interested in engaging 
> in a dialog to discuss the above points if you are open to that.

Thank you. I'd like to invite you to our next regular conference call, on 4th April at 13:00 UTC [1], or we could arrange another time to suit.

Kind regards,

Chris (Chair, W3C TV Control Working Group)

[1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=TV-Control-API&iso=20170404T13&ah=1

Received on Thursday, 23 March 2017 14:17:00 UTC