RE: TV Control API next steps

Hi all as well,

> From: Chris Needham [mailto:chris.needham@bbc.co.uk]
> Sent: Friday, July 21, 2017 1:34 PM
> 
> 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:

When it comes to standardization, it may also be useful to consider the so-called "classes of conformance", meaning to look at targeted runtimes for the functions to be developed. The TV Control Working Group identified three types of applications:

- Type 1: Device on-screen display. Highly privileged environment with access to all device features. 
- Type 2: Broadcast related applications
- Type 3: General web applications

It's interesting to look at these goals and at the comparison table that the TV Control Working Group drafted [7]. The "yes" cells in the "Type 3" column more or less match the 1) goal here, with the exception of:
- the ability to enumerate channels of a source. Maybe that is not exactly what is needed, though. Supposing there exists a URI scheme to address multicast IP or broadcast delivered media, it may be enough to actually be able to tell whether a particular URI can be played.
- the ability to retrieve the EPG, see below after 2)

In particular, functions for goal 2) (e.g. recording, parental control, CI card access) do not necessarily seem required for general web applications, and seem more specific to TV/radio devices.

Focusing on core features (and Type 3 applications) is often needed to target main web browser runtimes.
Focusing on extended features that are more specific to TV devices is doable as well, and may not require much support from main web browser runtimes. It does require clear support from the TV industry though.
Both can probably be done in parallel and in different specs.


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

The set of TV functions that people are interested in also seems to vary across companies and regions. For instance, my understanding is that the ability to expose the in-band EPG seems very much needed from an EU perspective, because the EPG is indeed often part of the broadcast stream. It is not very useful in e.g. the US as the EPG is actually retrieved separately over HTTP most of the time, which can already be done today without a specific API. 

Thanks,
Francois.

> 
> 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_Ma
> pping
> [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
[7] https://www.w3.org/wiki/TV_Control/Application_Types


> 
> ________________________________________
> 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 Monday, 24 July 2017 12:04:50 UTC