TV Control/Use Cases

From W3C Wiki
Jump to: navigation, search

This page lists use cases considered by the TV Control Working Group for the TV Control API specification.

Note related use cases, developed by the Web and TV Interest Group and the TV Control API Community Group, are available:

Application Types

See the TV Control/Application Types page for a discussion of the various types of web application that could make use of the TV Control API.

Format

Use cases should be written using the following form (see this article for background):

In order to <achieve some goal>, as a <role>, I want <feature>.

Technical requirements may then be derived from the use cases.

Radio use cases

Basic radio usage

This set of use cases describes the basic set of features for a controllable radio tuner.

Contributor

  • Alexander Erk, Institut für Rundfunktechnik

Use case descriptions

Technical requirements

Tuner channel scan

  • The API is able to initiate a scan for available Radio channels on a tuner
  • The API is able to report channels as and when they are found during a channel scan
  • The API is able to give a indication of progress during a channel scan
  • The API is able to stop an in-progress channel scan
  • The API is able to report when the channel scan is complete
  • The API is able to deliver a previously scanned channel list to the application

Integration with HTML <audio>

  • The API is able to render broadcast radio content via an HTML <audio> element
  • The API is able to Tune a service to start service presentation via <audio> element.
  • The API is able register/unregister at application level for change events regarding Status (e.g. CurrentChannel, Volume, reception quality, ServiceList, ScanProgress ...)
  • The API is able to control the service playback (stop, pause, resume, play ...)
  • The API is able to report the current status of a service (stopped, active, timeshifted, paused)

Service metadata

  • The API is able to deliver basic service metadata such as (ID (unique), name, genre, service provider..)
  • The API is able to deliver technical metadata regarding reception bearers (can the device use a different reception technology (DAB, FM, IP)
  • The API is able to register/unregister at application level for change events regarding service metadata

Radio applications (DynamicLabel, Slideshow)

This set of use cases describes the basic set of features for the additional reception of radio apps such as DynamicLabel (Text Messages) and SlideShow.

Contributor

  • Alexander Erk, Institut für Rundfunktechnik

Use case descriptions

Technical requirements

  • The API is able to register/unregister at application level callbacks for dls (DynamicLabel) and sls (SLideShow) events
  • The API is able to deliver the dls message texts as well as (if available) DL+ Tags incl. content type information see (ETSI TS 102 980 V1.1.1, AnnexA)
  • The API is able to deliver the sls images as well as (if available ) MOT-Header information see (ETSI TS 101 499 V3.1.1, 5.3 Common Parameters and 6.2.1 General)

Radio applications (EPG)

This set of use cases describes the basic set of features for the additional reception of radio EPG

Contributors

  • Alexander Erk, Institut für Rundfunktechnik
  • Jean-Pierre Evain, EBU (JP)

Use case descriptions

Technical requirements

  • (JP) In order to select a programme of interest, as a user, a minimum amount of metadata should be provided to describe programmes (TV or radio)
  • (JP) In order to attract a user towards my programmes, as a content provider, a minimum amount of metadata should be provided to describe programmes (TV or radio)
  • (JP) In order to identify the services offering content matching my preferences, as a user, a minimum amount of metadata is necessary to identify a service
  • (JP) In order to promote my brand, as a service provider, a minimum amount of metadata is necessary to identify a service
  • (JP) In order to help me watch or record content, as a user, a minimum amount of metadata should be provided to describe when and where content is available (publicationEvents, broadcastEvents, etc.).
  • (JP) In order to help me target an audience, as a service provider, a minimum amount of metadata should be provided to help provide appropriate content in the best period of availability.

Content publication use cases

The use cases in this section relate to content publication, so may not be addressed by the TV Control API itself. How the Working Group will address these requirements is TBD.

Metadata publication

Contributors

  • Jean-Pierre Evain, EBU (JP)
  • Chris Needham, BBC

Use case descriptions

In order to enable discovery of TV and radio content via search engines, as a content publisher I want to provide semantic metadata to describe programmes, channels, and time of publication (broadcast).

Technical requirements

  • (JP) The API is able to generate a description of the programme (TV or Radio) and associated publicationEvent and service to be embedded in the HTML page using schema.org's syntax to facilitate metadata harvesting by search engines.

Content protection use cases

The use cases in this section provide requirements for controlling presentation and redistribution of TV and radio content made available through the TV Control API.

Presentation restrictions

Contributors

  • Chris Needham, BBC

Use case descriptions

In order to ensure a consistent user experience, as a content publisher I want to only allow TV content to be presented on web domains that are authorised to do so.

Technical requirements

The API only allows presentation of audio and video media, and access to programme metadata, to whitelisted web domains.

Redistribution restrictions

Contributors

  • Chris Needham, BBC

Use case descriptions

In order to protect content owner interests, as a content publisher I want to prevent redistribution of received TV and radio content.

Technical requirements

The API should not allow audio and video media to be redistributed away from the receiving device (e.g., using WebRTC).

Media streaming use cases

Device capabilities

Contributors

  • Chris Needham, for Tatsuya Igarashi (Sony)

Use case description

In order to know how many streams can be rendered simultaneously, as an application developer I want to be able to be able to query the capabilities of the device.

Technical requirements

  • The API must allow web applications to obtain information about device capabilities:
    • The number of streams that can be displayed simultaneously
    • For each of these, the quality level, e.g., SD, HD, UHD, and other characteristics (TBD)
  • When starting presentation of a media stream:
    • The API must allow web applications to specify criteria for the stream, including:
      • The desired quality level or other characteristics (TBD)
    • If the implementation cannot satisfy the request given the specified quality level or other characteristics, it must give the application sufficiently detailed error information via a suitable mechanism (e.g., a rejected promise) to allow the application to act appropriately.