Media APIs/Tuner API

From Web and TV IG

Background

As part of the Media APIs Task Force's work, the need for a Tuner Control API arose from a use case (Tuner Control thru Web Application) which resulted in a Tuner Control requirement. Subsequent gap analysis showed this requirement is not addressed by existing W3C standards. As it's a relatively specific requirement it was thought a Community Group is the best starting point to create such an API.

Community Groups

Community Groups can be started by anybody and are able to create draft specifications. However, for a specification to mature beyond a draft and become a W3C standard it must eventually be taken up by a Working Group where it follows the regular W3C standardization process.

Community Groups do not belong to any particular Interest Group or other group, but it is recommended that the Web and TV Interest Group follows the work of related Community Groups, and similarly that the chairs of such Community Groups share their progress with the Web and TV Interest Group.

Scope

Overview

Rendering and control of linear video using <video> («Tuner API»)

Why

  • No common API to render linear content via the video element
  • HTML5 API may not be currently covering all the requirements needed to render linear content, e.g.
    • Access to list of services
    • Parental access control

Issues

  • What should be included in the scope, e.g. broadcast streams, channels
  • Naming. "Tuner API" is not universally liked. Suggestions ("Channel API", "Channel Control", etc.) are welcome.
  • Whether the approach should be API-based, URI-based, etc.

Discussion

  • Name of CG

Discussion on the team-webandtv-moderators mailing list begins here: https://lists.w3.org/Archives/Team/team-webandtv-moderators/2013Dec/0006.html

and starts with this comment from Mark Vickers (Comcast):

First, I think the notion of a “Tuner API” is not the right name or
focus. A tuner is a hardware component. In the Web we have an HTTP API
focused on network endpoints, not an Ethernet API or WiFi API focussed
on specific transport. Likewise, we’re adding a “File API”, not a “Hard
disk API” or a “Flash Memory API.
Bringing traditional TV channels into the Web is a naming problem, not a
JavaScript API problem. Instead of
<video src="brave.webm”>
we need a standardized name to supply to the video src that resolves to
the video stream of a “TV Channel” regardless of whether it’s coming
from a tuner hardware or an IP stream.
I’d support a new effort to standardize naming, but I’d oppose any Web
API that brought in tuner hardware specifics like frequencies, because
it makes non-portable Web applications.
Second, once we realize it’s a naming issue, the answer is likely to be
a URI or URL. It could be done in other groups, but I note that
standardizing a URI or URL specific to the HTML WG’s media element is
within the new HTML WG charter [HTMLCHARTER]. I’d suggest a CG focussed
on delivering a new URI/URL extension, possibly to the HTML WG.
[HTMLCHARTER] http://www.w3.org/2013/09/html-charter.html

Reference

  • TV Channel Identification references
    • W3C TV Broadcast URI Schemes Requirements (http://www.w3.org/TR/TVWeb-URI-Requirements)
    • Uniform Resource Identifiers for Television Broadcasts, IETF RFC2838
      • IETF RFC 2838 has defined "tv" URI. However, since channel frequency is different for each countries, "tv:3" form of URI has been obsoleted.
    • The TV-Anytime Content Reference Identifier (CRID), IETF RFC4078
      • IETF RFC 4078 has defined "crid://" type of URL scheme. However, this scheme is for IP environment not for local tuner.
      • Although using integer number can cause broadcast frequency problem as indicated in RFC2383, the broadcasting service through tuner is a regional service.
    • Open IPTV Forum – Release 1 DAE Reference Guide, OIPF-T2-R1-DAE_Reference_Guide v1.0-2010-03-11
      • OIPF-T2-R1-DAE_Reference_Guide v1.0-2010-03-11 has shown on how to control channel with JavaScript APIs. According to that, it has defined Channel class with the channel identification in form of a (Integer)sourceID.
    • Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime Phase 1"); Part 4: Content referencing TVA-CR(ETSI TS102 822-4 v1.1.2),
    • SmartTV Alliance, Technical Specification V3