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>:

> 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> 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
> <C.Meerveld@activevideo.com>]
> *Sent:* Thursday, June 29, 2017 8:49 AM
> *To:* Chris Needham <chris.needham@bbc.co.uk>
> *Cc:* 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> 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
>
>
>
>
>


-- 
[image: 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