Re: TV Control API next steps

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