W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2017

Re: TV Control API next steps

From: Meerveld, Colin <C.Meerveld@activevideo.com>
Date: Thu, 29 Jun 2017 12:48:42 +0000
To: Chris Needham <chris.needham@bbc.co.uk>
CC: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <A577E2BF-15FC-4BA6-90C9-9F237996A2B5@activevideo.com>
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.

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.


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,


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

Received on Thursday, 29 June 2017 12:49:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:36 UTC