Warning:
This wiki has been archived and is now read-only.

Main Page/Technical Requirement

From TV Control API Community Group
Jump to: navigation, search

TV Control API Technical Requirements

These requirements were compiled from technical use cases submitted by members of the group.

General Tuner Requirements

  • [tuner] The API SHALL be able to provide the webapps with the meta information of the tuners as long as those meta information is available, including but not limited to:
    • [tuner.available] The set/number of tuners that are currently installed.
    • [tuner.type] The broadcasting type of each tuner, such as terrestrial, cable, satellite... etc.
    • [tuner.protocol] The broadcasting protocol of each tuner, such as DVB, ATSC, ISDB... etc.
  • [tuner.signal-strength] The API SHALL be able to provide the webapps with the streaming signal strength of the tuners.
  • [tuner.notifications] The API SHALL be able to notify the webapps of the tuner changes from time to time (e.g., hot-plug detection).
    • The following event SHALL be supported
      • [tuner.notifications.change] TUNER_CHANGE

General Channel Requirements

  • [channel] The API SHALL be able to provide the webapps with the meta information of the channels as long as those meta information is available, including but not limited to:
    • [channel.available] The set/number of channels that have already been scanned.
    • [channel.type] The broadcasting type of each channel, including a regular TV type, a radio type or a data type... etc.
    • [channel.lcn] The Logical Channel Number (LCN) of each channel.
    • [channel.name] The name of each channel (e.g, "CNN", "NHK"... etc).
    • [channel.media-sources] The type and schema of media sources of each channel, such as URI-based defined in RFC2838 "Uniform resource identifiers for television broadcasts"
    • [channel.accessibility] The accessibility of each channel (paid or free).
  • [channel.search] The API SHALL be able to provide the webapps with the functions of sorting, searching, and filtering the channel/program list, including but not limited to:
    • [channel.filter] filtered based on rating information for Parental Control
    • [channel.sort] sorted based on program start time, name etc
  • [channel.sequential] The API SHALL be able to provide the webapps with the functions of getting the previous channel and next channel (channel up and down)
  • [channel.select] The API SHALL be able to enable the webapps to switch a channel.
  • [channel.tracks] The API SHALL be able to enable the webapps to switch the video/audio/text tracks of a channel.
  • [channel.notifications] The API SHALL be able to notify the webapps of the channel set/content changes from TV broadcasters from time to time.
    • The following event SHALL be supported
      • [channel.notifications.change] CHANNEL_CHANGE

Tuner Channel Scan Requirements

  • [scan] The API SHALL be able to enable the webapps to initiate a scan for available DVB channels on a tuner
  • [scan.notifications.found] The API SHALL be able to provide the webapps with the channels as and when they are found during a channel scan
    • The following event SHALL be supported
      • SCAN_CHANNEL_FOUND
  • [scan.signal-strength] The API SHALL be able to provide the webapps with the signal strength of channels found during a channel scan
  • [scan.progress] The API SHALL be able to give the webapps an indication of progress during a channel scan
    • The following event SHALL be supported
      • SCAN_PROGRESS
  • [scan.stop] The API SHALL be able to enable the webapps to stop an in-progress channel scan
  • [scan.notifications] The API SHALL be able to notify the webapps when the channel scan is complete
    • The following event SHALL be supported
      • [scan.notifications.complete] SCAN_COMPLETE

General Program Requirements

  • [program] The API SHALL be able to provide the webapps with the meta information of the programs as long as those meta information is available, including but not limited to:
    • [program.current] The set/number of programs that are currently broadcast.
    • [program.data] Title, start time, duration, description, language, rating, classification... etc of each program.
    • Other program-/content-related information from service provider, for example:
      • [program.data.audio] For audio: such as language supported, codec used, etc.
      • [program.data.video] For video stream: such as quality, codec used, etc.
      • [program.data.captions] For captions: such as languages supported, etc.

Electronic Program Guide (EPG) Requirements

  • [epg] The API SHALL be able to provide the webapps with the EPG information of a channel or a time period.
  • [epg.notifications] The API SHALL be able to notify the webapps of the EPG changes from TV broadcasters from time to time.
    • The following event SHALL be supported
      • [epg.notifications.change] EPG_CHANGE

Program Recording Requirements

  • [recording] The API SHALL be able to enable the webapps to determine whether the device supports program recording, the total recording capacity, and remaining available capacity.
  • [recording.timed] The API SHALL be able to enable the webapps to record a program given a start time and duration.
  • [recording.identifier] The API SHALL be able to enable the webapps to record a program given the programme's unique identifier.
  • [recording.multiple] The API SHALL be able to enable the webapps to record 2 or more programs simultaneously.
  • [recording.series] The API SHALL be able to enable the webapps to record series-linked programs.
  • [recording.data] The API SHALL be able to enable the webapps to obtain information about recorded programmes.
  • [recording.playback] The API SHALL be able to enable the webapps to play back recorded programmes.
  • [recording.delete] The API SHALL be able to enable the webapps to delete recorded programmes.
  • [recording.parental] The API SHALL be able to apply parental controls to playback of recorded programmes.

Time Shifting Requirements

  • [timeshift] The API SHALL be able to enable the webapps to determine whether the device supports time shifted playback, the total storage capacity available for timeshifting, and remaining available capacity.
  • [timeshift.pause] The API SHALL be able to enable the webapps to pause a live program.
  • [timeshift.resume] The API SHALL be able to enable the webapps to resume playback of a paused live program from the point where the program was paused.
  • [timeshift.stop] The API SHALL be able to enable the webapps to resume playback of a paused live program from the latest program position.

Emergency Alert Requirements

  • [emergency.notifications] The API SHALL be able to notify the webapps when an emergency occurs, such as earthquake, tsunami... etc.
    • The following event SHALL be supported
      • [emergency.notifications.alert] EMERGENCY_ALERT

Parental Control Requirements

  • [parental] The API SHALL be able to provide the webapps with the information whether or not a channel/program is protected and only accessible by a certain group of users, e.g. age-based user groups.
  • [parental.channel] The API SHALL be able to enable the webapps to lock and unlock the protected channels/programs.

Conditional Access System (CAS) Requirements

  • [cas] This API SHALL be able to provide the webapps with the meta information of the CI cards as long as those meta information is available. For example, the CAS standards such as DVB-CI, ARIB-CAS... etc.
  • [cas.notifications] This API SHALL be able to notify the webapps of the dynamically added/removed Common Interface (CI) cards.
    • The following event SHALL be supported
      • [cas.notifications.change] CI_CHANGE

Triggered Interactive Overlay Requirements

  • [trigger.in-band] The API SHALL be able to fire an event based on in-band event triggering mechanism, e.g. triggers that are encoded within the content from current channel such as EBIF or similar
  • [trigger.out-of-band] The API SHALL be able to fire an event based on out-band event triggering mechanism, e.g. pre-provisioned triggers on the platform
  • [trigger.events] The following event types SHALL be supported:
    • [trigger.events.start] START_OVERLAY
    • [trigger.events.dismiss] DISMISS_OVERLAY
  • [trigger.types] The following triggers SHALL be supported as long as those triggers are available either in-band or out-band
    • [trigger.types.channel-changed] Triggers when channel is switched
    • [trigger.types.time] Triggers based on date and time
    • [trigger.types.content-boundary] Triggers based on content boundary
    • [trigger.types.fingerprint] Triggers based on content fingerprints
    • [trigger.types.watermark] Triggers based on content watermarks
    • [trigger.types.context] Triggers based on contextual information in content
    • [trigger.types.segment] Triggers based on program chapters or other segments within the program
    • [trigger.types.caption] Triggers based on subtitle captions
  • [trigger.data.supplemental] The API SHALL be able to provide the webapps with supplemental information supporting triggered events as long as those supplemental information is available either in-band or out-band
  • [trigger.validity] The API SHALL be able to provide the webapps with the validity information so that the content overlay can be dismissed after the validity period expires
  • [trigger.data.content-source] The API SHALL be able to provide the webapps with the content source information to be overlayed on top of current channel content
  • [trigger.sources] The API SHALL be able to provide the webapps with the content of multiple video/audio tracks in the same media stream of a given channel, including live, time-shifted programming, linear commercial, service provider-encoded, cable TV, IPTV, VoD, personal video, IP multicasting video, cellular multicasting video, supplementary audio streams (audio description), etc.

Integration with HTML <video> and <audio> Elements

  • [media-element] The API SHALL be able to render broadcast TV and radio content via the HTML <video> and <audio> elements respectively