RE: ATSC liaison reply

Dear all,

Michael has kindly allowed me to share the reply on our public mailing list.. I'm keen to hear your views on this reply.

I'd like to discuss this, as well as the current status of rechartering of our WG, on our next conference call on 7th March, so I would like to encourage all WG members to join the call at this important time.

Topics to consider in our conversation with ATSC include:

* The possibility of aligning the TV Control API to meet their requirements
* The architectural approach with regard the RMP and web runtime engines
* How ATSC regards the integration with HTMLMediaElement, one of the key features of the TV Control API
* Whether W3C should standardise an RPC over WebSocket API (and protocol) to support distributed receiver components

Best regards,

Chris (WG Chair)

--

From: Michael Dolan [mike@dolan.tv]
Sent: 08 February 2017 18:24
Subject: RE: W3C TV Control Working Group

Dear Chris,

Thank you for your liaison email of 16-December from the W3C TV Control WG, and your continued interest in ATSC's work on an interactive runtime environment built on HTML5. Apologies for the delayed reply between the holidays, CES, etc.

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.

*       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".

*       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.

*       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).

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.

*       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.

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.

Sincerely,

        Mike Dolan
        W3C ATSC Liaison

[1] http://atsc.org/candidate-standard/a344-atsc-candidate-standard-atsc-3-0-interactive-content/

________________________________________
From: Chris Needham
Sent: 21 February 2017 14:32
To: public-tvcontrol@w3.org
Subject: ATSC liaison reply

Dear all,

We have received the following reply from ATSC to our liaison [1] (member-only link).

Although we won't meet the required timescale for inclusion in ATSC, I think we should follow up the discussion with them.

I'll include this on our agenda for our next call on 7th March; but please do share your comments in the meantime.

Best regards,

Chris

[1] https://lists.w3.org/Archives/Member/w3c-archive/2017Feb/0753.html

Received on Thursday, 23 February 2017 17:34:03 UTC