RE: Follow up with ATSC

> From: Chris Needham [mailto:chris.needham@bbc.co.uk]
> Sent: Friday, March 24, 2017 1:48 PM
> 
> Hi Francois,
> 
> Thank you for your comments. I've included your changes, with a couple of
> minor alterations. Please see the updated draft below. Does this look OK? If
> there are no further comments I plan to send this (and a reply to HbbTV)
> later today.

The text around "accessibility requirements" is duplicated in that letter. I suppose you forgot to drop one of the two paragraphs. That looks good to me otherwise!

Francois.

> 
> Best regards,
> 
> Chris
> 
> ---
> 
> 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. 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 broadcaster
> 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 different permissions to be
> set 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.
> 
> We think that bringing a closer integration could also make it easier to align
> other features that, for example, address accessibility requirements across
> media sources.
> 
> From a Web platform perspective, this mechanism should avoid the need for
> a separate video pane and media player, which could make it easier to align
> other features that, for example, address accessibility requirements across
> media sources.
> 
> Of course, more work is needed to achieve this, and other mechanisms may
> be better suited to achieve these goals in the end, but our group would
> welcome the discussion.
> 
> > * 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 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 or someone else from ATSC 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
> ________________________________________
> From: Francois Daoust [fd@w3.org]
> Sent: 24 March 2017 09:37
> To: Chris Needham; public-tvcontrol@w3.org
> Subject: 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
> >
> 
> 
> 
> 
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------

Received on Friday, 24 March 2017 13:04:47 UTC