RE: TV Control API next steps

Hi all,

I agree with Alexandre's point that the TV Control API spec could be split up. This is something the Working Group recognised, although we didn't start work on it.

It seems that there are a few different goals:

1) Allowing the HTMLMediaElement to support rendering of multicast IP or broadcast delivered media.

With MSE we have a way of delivering adaptive media streams to browsers over HTTP, but allowing the media to be rendered from other sources is beneficial. This could be achieved by a JavaScript API in the browser or by defining a URI scheme that allows such media to be addressed in a <source> tag inside a media element [1]. A particular problem to be solved is defining a "same origin policy" that can be applied between web pages and these media sources. There is then the issue of limited resources for decoding media streams in devices, which was a particular focus in the TV Control WG.

The feedback we received from ATSC [2] showed a desire to avoid making substantial changes to browser code bases, and this goal would require (possibly significant) code changes to be able to source and render the streams. But, this approach could be applicable more broadly than TV devices, for browsers and devices generally, and I wonder if this could lead to implementations in open source browser engines.

ATSC's reply also mentions that "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." It would seem there is benefit in allowing browser rendered video to take advantage of such features.

2) A control API for TV functions. As Colin points out, there is large variation between manufacturer APIs for TV device functions, and this was the direction of the initial work in the TV Control CG. The CG did a survey of existing APIs [3] when considering the features to include in a W3C spec.

Such an API could be used from a web application associated with a TV channel or service, or as a remote control mechanism. It be a JavaScript API, a RESTful HTTP interface, or a Websocket RPC interface as used in ATSC 3.0 [4]. And this may not require integration with the HTML media element for video rendering. We had some discussion based on TAG feedback, in this issue [5], in particular the "external source-centric" model described in this comment [6].

Thanks all who have replied, and I welcome further discussion.

Best regards,

Chris

Co-chair, Media and Entertainment Interest Group
(former) Chair, TV Control Working Group

[1] https://www.w3.org/2011/webtv/wiki/Media_APIs/Tuner_API#Discussion
[2] https://lists.w3.org/Archives/Public/public-tvcontrol/2017Feb/0020.html
[3] https://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping
[4] http://atsc.org/candidate-standard/a344-atsc-candidate-standard-atsc-3-0-interactive-content/
[5] https://github.com/w3c/tvcontrol-api/issues/24
[6] https://github.com/w3c/tvcontrol-api/issues/24#issuecomment-261918951

________________________________________
From: Alexandre Morgaut [alexandre.morgaut@wiztivi.com]
Sent: 04 July 2017 16:44
To: Meerveld, Colin
Cc: Paul Higgs; Chris Needham; public-web-and-tv@w3.org
Subject: Re: TV Control API next steps

What's true is that this specification includes a lot of features:

  *   Channel Scan
  *   Channel zap
  *   Recording
  *   Program Info
  *   Alerts
  *   Subtitles
  *   CAS CI card

Agreeing to implement such spec means agreing implementing a lot of things

I'm pretty sure this API could be split in more atomic feature specs


2017-07-04 12:26 GMT+02:00 Meerveld, Colin <C.Meerveld@activevideo.com<mailto:C.Meerveld@activevideo.com>>:
Hi Paul,

I understand the rational behind the current API design. It solves a certain problem which is very helpful. Unfortunately, it turn out that there isn't sufficient (practical) support for the API. As the API is back in the IG and we are thinking about the fundamental aspects of it, i tried to convey another way of solving the problem. i.e. instead of one monolithic solution, dividing it into smaller separated specifications.

Thanks,

Colin

On 01 Jul 2017, at 12:21, Paul Higgs <paul_higgs@hotmail.com<mailto:paul_higgs@hotmail.com>> wrote:

Hi Colin

Your comments are all very useful, however the primary task at hand was to come up with an API that allowed tuner resources on the client to be manipulated by the WebApp. We could certainly come up with a “playProgram(….)” method/function where the implementation would look to match (…) with metadata it had accumulated, find a source (multicastIP, unicastIP, broadcast tuner) and provide the resulting content to a Media Source.
What was decided was to provide a sufficient API to the basic tuner functions that a could then me leveraged by the WebApp to provide an entertainment service wherein the content was delivered over a broadcast mechanism (which is still deemed to be the most cost-effective delivery mechanism for highly viewed content). Certainly there are those that say “no-one watches live TV anymore” and to some extent they are correct. In such cases there are cloud based storage systems that make “recorded programs” available as DASH content – no problem for W3C to solve there.

But back to the API and the WebApp, just because the API is structured around traditional TV content delivery, doesn’t mean that a well crafted, cloud assisted WebApp couldn’t have a “playProgram(….)” library function.

Paul

From: Meerveld, Colin [mailto:C.Meerveld@activevideo.com]
Sent: Thursday, June 29, 2017 8:49 AM
To: Chris Needham <chris.needham@bbc.co.uk<mailto:chris.needham@bbc.co.uk>>
Cc: public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: Re: TV Control API next steps

Hi Chris,

It is unfortunate that the TV Control API didn't reached a state of publication in the WG. I believe the industry really need something like this specification. Currently, implementations are very fragmented and mostly proprietary. Enabling web applications on different platforms usually means to reimplement all tv specific integrations. That said the current TV Control API is almost an one-to-one relation with broadcast infrastructure. This is not wrong per se but it do impact and limit the scope of the specification. This also implies that W3C members who are willing to invest in this specification are scarce. I personally believe a more abstracted type of specification is much more beneficial. Instead of a all-encompassing TV control API i rather see a solution where we reuse existing APIs (where applicable) or have specific specifications for a isolated problem. The challenge is to bridge (RF) broadcast with (IP) broadband. I jotted down some examples to express my line of thinking:

Parental control
In a broadcast environment this is tight to a channel but why should we restrict it to a channel? Video providers (like, Youtube or Hulu) have the same problem. There need to be a way to prevent children from getting adult content (not only video). In broadband this is solved on different levels (filtering on the network level, OS level sending specific headers to the video provider or web application settings). I understand that in broadcast, specific (regulatory) requirements are needed (such-as using a rating system).. Having a API that only address this issue would be helpful and are probably hard enough to come up with a proper solution on its own.

Multicast video
You may naively say that this video is live (or continues) and may have in-band [1] tracks. Should we really use the broadcast structure (sources, channels, programs)? In broadband the channel and program information is obtained via different means (usually via web services). Broadcast service providers doesn't always have this luxury of using web services (e.g. due to network constrains). In these cases they may extract this information using MSE by parsing the media container.

Encryption
In broadcast, encryption could be done with so-called conditional access system. We may create an API specific for this but couldn't we leverage the work of the EME specification. According to my understanding this specification should be a generic way of handling encrypted video and not only for DRM systems.

I am not sure if those solutions are feasible (probably not) but alternatives may work. It is another mind set of solving the same thing.

Thanks,

Colin Meerveld
Platform Architect, ActiveVideo

[1]: https://dev.w3.org/html5/html-sourcing-inband-tracks/

On 28 Jun 2017, at 14:56, Chris Needham <chris.needham@bbc.co.uk<mailto:chris.needham@bbc.co.uk>> wrote:

Dear all,

As you may be aware, the TV Control Working Group has now closed. The goal of the group was to enable integration of broadcast and IPTV delivered video into HTML, providing a control interface for channel selection and media playback using the HTMLMediaElement interface.

This work started from a Task Force in the Interest Group [2], which identified a need for a Tuner API. The TV Control API specification [1] produced by the Working Group currently includes:

- Support for playback of broadcast and IPTV sources of audio and video media via the HTML5 <video> and <audio> elements
- Access to EPG information such as channel and programme lists
- Programme recording and playback
- Information about available conditional access modules

Although the group had a number of active contributors (thank you all), during rechartering not enough members expressed an interest in implementing the API.

I would now like to invite IG members to share thoughts on the future direction that this work should take, and in particular to revisit our goals.

For example, do we want to pursue integration of broadcast delivered content on the web, and provide a common set of operations that allow a Web page to present and control broadcast content, e.g., from a broadcaster web application? If so, which types of user agent should we aim to support? Some examples could be: connected TVs and set top boxes, PCs with TV tuner hardware, radio receivers in mobile devices, in-car entertainment systems.

Please feel free to share your thoughts on the mailing list.

Best regards,

Chris

Co-chair, Media and Entertainment Interest Group
(former) Chair, TV Control Working Group

[1] https://w3c.github.io/tvcontrol-api/
[2] https://www.w3.org/2011/webtv/wiki/Media_APIs/Tuner_API






--
[wiztivi-logo]<http://www.wiztivi.com/>
Alexandre Morgaut | Web Architect
@amorgaut<https://twitter.com/amorgaut>
wiztivi.com<http://www.wiztivi.com/>
2 bis avenue du Professeur Jean Rouxel
44481 Carquefou CEDEX - France
[http://static.wiztivi.com/images/sig/current-event.png]



-----------------------------
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, 21 July 2017 11:35:36 UTC