RE: Follow up with ATSC

Hi Chris,

Many thanks for the draft! See a couple of comments inline.


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

I think we should point at a possible direction, typically the one you mention later in the response in "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". I would move that paragraph here, and would suggest to expand a bit with a few additional consideration to give more food for dialogue. Something like:

[[
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. For instance, the TV Control API could be used to control the rendering of the main video in a video element of a top-level browsing context, while broadcasters applications could launch in an iframe overlay on top of it. Broadcaster applications could then use a message protocol similar to the one defined in ATSC 3.0 (e.g. using a WebSockets connection or window message posting) to exchange commands with the top-level browsing context. They could perhaps also use the TV Control API, e.g. to render another video on top of the main one for picture-in-picture scenarios.

The group identified three types of applications for the TV Control API (see https://www.w3.org/wiki/TV_Control/Application_Types). Such a mechanism would avoid "dead air" for the main controlling application (type 1 in our categorization). Similarly, it would allow to set different permissions for that application and for broadcast-independent and broadcast-related applications. It would also make it possible to run more than one application at the same time if needed. From a Web platform perspective, this mechanism avoids introducing a separate video pane and media player which currently do not exist in a Web context, making it easier to align other features that e.g. address accessibility requirements across media sources.

This needs more work, and other mechanisms may be better suited to achieve these goals in the end.
]]

Feel free to adjust the wording.

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

If you include the suggested text above, you can drop the previous paragraph.

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

Would it be worth clarifying that "you" could be any person from ATSC available to discuss the topic?

Thanks,
Francois.


> 
> 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 Friday, 24 March 2017 09:38:00 UTC