RE: ATSC liaison reply

> From: Chris Needham [mailto:chris.needham@bbc.co.uk]
> Sent: Thursday, February 23, 2017 6:33 PM
> 
> 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

I note we somewhat envisioned the possibility to design the spec using an RPC mechanism following feedback from the TAG. This is what I called the "external source-centric" model:
https://github.com/w3c/tvcontrol-api/issues/24#issuecomment-261918951

Agreement on an RPC mechanism and alignment with the one proposed in ATSC 3.0 sounds doable to some extent technically speaking, provided there's industry interest for it. I agree that the main difference in approach between ATSC and the TV Control WG is that we want to integrate with HTMLMediaElement, so that only one media player remains in the end, and thus we want to - or rather we need to - touch the browser codebase.

This is where the alignment might be more difficult. In ATSC, the goal is to control the video pane that underlies the web page. In the TV Control WG, that video pane does not exist and the goal is to get a handle to an audio/video stream and to render that stream in a media element. As such, commands such as "resize and move the video pane", needed in the ATSC spec, would not make sense in the TV Control spec, where the position and size of the media player is inherently an HTML/CSS issue.

Also, in the TV Control API, we need a way to represent and expose the "handle" to the media stream, something that is not needed in the RMP scenario in ATSC 3.0 where commands are sent directly to the remote media player. Right now, the handle is a MediaStream in the TV Control API. It could be a stream retrieved through a local WebSockets server or through an XHR mechanism (both of which seem doable in ATSC 3.0) but this is not very efficient for local media playback. Or it could be a URI with a specific scheme if an RPC mechanism is used. That triggers a number of questions on how to name broadcast channels. I note an old IETF document named "URIs for TV Broadcasts" (Mark Vickers is one of the authors):
https://tools.ietf.org/html/rfc2838

The distributed requirement seems doable as well. It could be achieved on top of the TV Control API in its present form: an RPC mechanism can easily be implemented on top of the TV Control API. Or indeed the TV Control API could be designed directly using an RPC mechanism.

Both approaches might co-exist. For instance, on top of my head, one idea to create the concept of a video pane with a broadcast application on the web could be to have the Remote Media Player be a default web application that renders the broadcast video stream (using the TV Control API) and an <iframe> overlay on top of it that runs the broadcast application. The RPC mechanism could be used to communicate between the application and the Remote Media Player, exactly as envisioned in ATSC 3.0. Iframe access restrictions could perhaps be used to give different privileges to broadcast applications as needed.

I understand the timing constraints for ATSC. I think the use of an RPC mechanism in ATSC 3.0 makes it easy to discuss a possible future alignment. It would be good to understand whether ATSC members are interested to work on that alignment longer term, perhaps providing ATSC 3.0 RPC mechanism to W3C as a starting point, and/or on the integration of the RMP with the media player in HTML.

Thanks,
Francois.

> 
> 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 Friday, 24 February 2017 16:04:22 UTC