HNTF/Home Network TF Discussions/TVControl

From Web and TV IG
Jump to: navigation, search

Submitter: BBC

Tracker Issue ID: ISSUE-20

Description: An API, or service, for simplified control of key functionality of television devices, including those with integrated broadcast receivers and limited or no media streaming capabilities. The application defines its own user interface, independent of the user interface of the television device.

Application developers would benefit from a simplified API or services, that provides:

  • A single unified directory of programmes that a given rendering device (e.g. television display) is able to obtain and play. The application does not have to check, for itself, across multiple sources of content and for any issues of codec, container format, and transport protocol compatibility.
  • A single simple method for requesting a programme or channel be presented by a rendering device, irrespective of the above factors.

It is also desireable to be able to control other common aspects of television functionality through the same API.

The target of the API would be a processing engine on the home network. For a Javascript API this processing engine could be incorporated into the user agent. Alternatively, it could be implemented by any other device on the home network, including the television device itself. For the latter case, the user agent must be able to discover and communicate with the processing engine in order to execute the functions of the API.

The processing engine may, when appropriate, utilise existing home networking protocols to perform its function. For example: it may use UPnP AV services to discover and stream content.

Scenario 1: Basic programme guide application: The application uses the API to perform the following tasks:

  • The application sends a request to discover television devices on the home network
  • The application sends a request to ask for the identity of the programme currrently being presented on the television, and the source (e.g. television channel)
  • The application sends a request to retrieve basic programme metadata (title, description, start and end times) and displays this for the user
  • The application sends a request to retrieve a list of sources (e.g. channels) of programmes that can be displayed on the television
  • The application sends a request to retrieve a list of programmes, and their basic metadata for those sources for presentation to the user
  • The application sends a request to cause a given channel or programme be played on the television.

Extension to scenario 1: Control of other television functions:

  • The application can send a request to change the volume of the television
  • The application can enable or disable accessibility features such as subtitles or audio-description
  • The application can request to seek (jump to a different time point) within the programme being played

Scenario 2: A web site with material supporting a particular programme wants to be able to offer to play the programme on a television if it is available. A possible interaction (via the API):

  1. The application sends a request to discover television devices on the home network
  2. The application makes a request to query if a specific programme is available to the television. If it is available, the application offers the choice to the user to display it.
  3. If the user accepts, the application requests that programme be played on the television.

Each of the interactions described should be ideally achievable a single call to an API or service method.


Justification:

  • Simplify creation of applications that will work with a range of devices and variety of means by which a given programme might played on the television.
  • Standardisation could facilitate a new ecosystem of interfaces.
  • Existing standards for home network communication are not commonly available from the browser context and expose functionality at a lower level.
  • What could be standardised:
    • Type of use case: Application specific services / protocols / APIs
    • A Javascript API
    • Service(s) for television type devices on the home network

Dependencies:

  • Requires Application discovering a service (issue 14)
  • Scenario 2 requires 'Media Identification (issue 19)

Comments:

rberkoff: regarding justifications:

  • 'allows creation of UIs ...' : UPnP allows any device to act as an external control point. This device can determine the current state of the rendering device as well as control the device.
  • 'Existing standards ... not available from the browser context' : Actually CEA-2014-B has a web-binding for UPnP devices. PHP has a binding for UPnP Devices (GUPnP). A desirable goal of this TF is to have W3C also publish these (or similar bindings).
  • 'Existing standards ...) do not support query and control ...' : UPnP embodies no such restriction. There is nothing in UPnP that precludes a MediaRenderer from publishing locally based changes of device state. If anything this would be encouraged to provide a consistent user experience.

matt:

  • yes - its a use case for enabling direct access (eg. bindings ) to existing standards.
  • Happy to see these use cases folded into issue-17, so long as the specific requirement that these functions be possible in the context of receiving broadcast content, and not just for the context of streaming between devices in the home. From my perspective, the set of possible capabilities in the collection of specifications constituting UPnP seems considerably larger than what, in practice, appears to be implemented. The functions that seem to be implemented in actual devices concern with the use cases for streaming media content - an excellent success largely attributable to the DLNA initiative. Could the issue I am trying to raise be captured to everyone's satisfaction by rephrasing to say: "They ways in which existing standards are currently deployed in home devices do not support ..." ?

dan: need to better distinguish between what is commonly implemented and what is in the specs

matt (19 Jul 2011): have rewritten, addressing the intent more directly - that of requiring a simplified means controlling devices, including those with the specific capabilities mentioned.

matt (31 Jul 2011): Ammendments made, as recommended by other group members in weekly conf call [minutes]