Media APIs/Terminal Use Cases

From Web and TV IG
< Media APIs
Revision as of 11:31, 26 April 2013 by Ot (Talk | contribs)

Jump to: navigation, search

Terminal Capabilities / Metadata Task Force

This TF aims to define how terminal capabilities can be addressed within the scope of the Web and TV Interest Group.

The goal of the Terminal (for short) TF is to discuss use cases of terminal capabilities into classic TV usage and propose solutions or request others TF to work on proposing a solution.

In addition to terminal capabilities, the following topics are also in scope:

  • Investigate how to expose TV metadata to web applications
  • Investigate mapping between Media Element API and in- band metadata
  • Enable synchronization scenarios up to frame accurate

MODERATOR's NOTE: During TPAC2012 in Lyon (see minutes), there were a consensus the need to do this within W3C, and not in outside organizations, and to start from use cases and how they fit in the web standards:

  • define use cases
  • detail requirements
  • identify gaps between requirements and existing W3C recommendations
  • define additional requests to send to various WG

Dashboard

Use cases

The initial use cases list determined at TPAC includes:


1. "Channel"

  • Participants:
    • JC Verdié
    • Sung Hei Kim
    • Wook Hyun
  • Description:
    • We need a way to identify and access video sources coming from Broadcast sources. There are metadata needed (that might be different depending on broadcasting systems). Request Metadata TF to handle this.
    • Browser with embedded TV functionalities can provide TV services along with broadcasting service related convergence to the web browser or the web platform. Web application can provide program guide such as EPG for the user to control TV channels through the web browser. Regarding interactivity with the TV functionalities, it is possible to classify applications into channel bounded application and channel unbounded application.
      • Channel Bounded Application: It is a web application that provides contents related to the current broadcasting channel. This application is terminated when the user changes to different channel.
        • e.g., List of next programs to be broadcast, events, SNS, detailed information of broadcasting contents such as disaster alarm information, stock quota, athlete stats, etc.
      • Channel Unbounded Application: It is a web application that is independent of the current broadcasting channel which is executed by the user. This application does not have to be terminated when the user changes to different channel.
  • Status: WIP
  • Requirements:
    • Channel Control
      • Conforming specifications should provide a means for applications to access the status of tuner such as current channel number.
      • Conforming specifications should provide a means for applications to control the tuner.
      • Some of the examples APIs that can be considered are…
        • getCurrentChannel: It is used to get information of the current broadcasting channel such as channel delivery media (cable, terrestrial, satellite, IP, etc.), channel type (TV, radio, etc.), name of the broadcaster, channel number, source URI, etc.
        • getNextChannel: It is used to get information of the next channel of the current viewing channel.
        • getPrevChannel: It is used to get information of the previous channel of the current viewing channel.
        • onChannelChanged: It is invoked when the channel is changed.
        • getChannels: It is a list of channel that is supported by the TV. It is possible to sort or filter this list with the use of parameters.
        • NOTE: setChannel API is not needed, since it is possible to embed the source URI of the channel into a HTML5 video tag which has the same effect as the setting channel.
    • Channel Identifier
      • Conforming specifications should provide a means for applications to control the TV tuner by the use of source URI.
      • NOTE: IETF RFC 2838 (“Uniform Resource Identifiers for Television Broadcasts”) defines TV URI, however, it does not include local tuner identifier.
    • Source
      • Conforming specifications should provide a means for applications to imbed media stream from the TV source to the web browser using the HTML5 video tag.
    • Channel Bounded Application
      • Conforming specifications should provide a means for applications to get AIT information that is included in the digital broadcast signaling.
      • NOTE: Detailed description of Application Identification Table (AIT) can be found in “ETSI TS 102 809 V1.1.1: Digital Video Broadcasting; Signaling and carriage of interactive applications and services in Hybrid Broadcast/Broadband environments”, Jan. 2010”.
  • Proposal:
    • Defining APIs to control TV channel should be considered (maybe in Device API WG).
    • (JC)Does it need to be new API? We have various options here:
      • Use external already-defined API (need liaison: OIPF? Others? ...)
        • (SungHei) That would be a possible option, since OIPF has already defined OIPF JavaScript APIs within "Release 1 DAE Reference Guide"[1]
      • Use a more declarative approach such as http://www.w3.org/2011/09/webtv/papers/channel_xml.pdf
      • Albeit there's a huge trend on procedural json/javascript, a channel remains a structure object which should not require such effort
        • (SungHei) Of course, it is possible to control channel structure object by directly handling the DOM tree. But, if we have a APIs for handling channel, it will be much easier to program Web Applications for set-top box in a uniformed way.
        • (SungHei) My suggestion is as follows:
          • 1. Include declarative approach as one of the option.
          • 2. Weaken the requirements for APIs (i.e, should --> may)
          • If we have an agreement on this issue, we will make a proposal for revised text in this wiki.
    • Defining metadata for channel information, program information should be considered in metadata T/F.
    • (JC) I definitely suggest we collaborate with metadata tf on that one. That specific part might even be moved to this TF
    • (JC) I would add:
      • Establish application lifecycle model and collaborate with WebApps WG. There are plenty things to consider:
        • How an application is signaled?
        • Which states of an application should be defined and handled: signalled, ready, running, stopped, (un)bounded... Others ? Specific WebApps-WG-defined states?
        • How an application is transported? Installed? cached?
        • How is it killed (by the system)
        • What happens when you switch to a channel where another application is signalled? where the same application is signalled?
        • What happens if a new app is signalled while one is running?
        • Should we define a multiple app on the same screen scenario?
          • (SungHei) Are the issues you've raised pertains to the "channel"? To us, it looks like a different issue. Do you think it is better to make new chapter?

2. recording

  • Participants:
    • ...

Need to add description

  • Description:
  • Status: WIP
  • Requirements:
  • Proposal:

3. Device capability information / conflict detection

  • Participants:
    • ...
  • Description:
    • about number of decoders, ...
    • memory?
    • potential conflict ...
    • codecs
  • Status: WIP
  • Requirements:
  • Proposal:


4. Channel List

  • Participants:
    • JC Verdié
    • ...

Need to add description

  • Description:
  • Status: WIP
  • Requirements:
  • Proposal:

5. CA and CI

  • Participants:
    • ...

Need to add description

  • Description:
  • Status: WIP
  • Requirements:
  • Proposal:

6. Video output control

  • Participants:
    • ...

Need to add description

  • Description:
  • Status: WIP
  • Requirements:
  • Proposal:

7. TV Applications

  • Participants:
    • Sung Hei Kim
    • Wook Hyun
  • Description:
    • Web application that is installed within the TV (or set-top box) can be called a TV applications. TV applications may be in form of an application software (or apps) or in a form of an offline/online web page.
    • Web platform for TV (or set-top box) should consider interworking capability with the broadcasting service and prevent conflict between the broadcast-independent apps and broacast-related apps.
    • The TV applications and broadcast contents are transported as follows:
      • TV applications can be created by the broadcast network operators or app developers to be distributed through app store.
      • TV applications in a form of an apps can be downloaded and installed to the TV/STB from the TV application store.
      • Broadcast-related contents can be delivered to the user through the Internet.
      • Broadcast contents can be delivered to the user through the broadcasting network (e.g., satellite, cable, terrestrial, etc.) or the Internet.
      • Broadcast contents can be watched through the TV applications.
    • This requirements classified the TV applications into two types and described the signalling, lifecyle, and priority accordingly to the types.
  • Status: WIP
  • Requirements:
    • Types of application
      • Broadcast-related application
        • The interactive application associated with a broadcast television, radio or data channel, or content within such a channel. [reference: ETSI TS 102 796]
        • The broadcast-related application distributed from the TV application store much be verified by the pertaining broadcast network operator or trusted third-party (or application store administrator) which are approved by the broadcast network operator in order to guarantee interworking in manipulating the functionality of the channel and program.
        • The broadcast-related application can control the broadcasting audio/video stream (e.g.,play/stop, screen size and screen position adjustment).
      • Broadcast-independent application
        • The interactive application not related to any broadcast channel or other broadcast data. [reference: ETSI TS 102 796]
      • NOTE-This classification is referenced from HbbTV specification. (http://www.etsi.org/deliver/etsi_ts/102700_102799/102796/01.02.01_60/ts_102796v010201p.pdf)
      • NOTE-It is possible to make more or different classification.
    • Signaling
      • Broadcast-related application can be signaled by AIT(Application Information Table).
      • It is possible to check the existence of AIT by examining PMT(Program Map Table).
    • Life Cycle: The TV application can be executed automatically through the AIT signalling which can be a distinguished from the typical applications. Therefore, the TV application may have different life-cycle.
      • Web app WG may need to acknowledge this on their work on the state-machine.
      • Execution
        • TV application can be executed by the followings:
          • Execution initiated by the user
          • Execution through AIT signal from broadcast
        • NOTE-more method should be considered.
      • Termination
        • TV application can be terminated by the followings:
          • In case of broadcast-related application, it is terminated
            • when the channel is changed
            • when a control_code of AIT is changed
          • If there exists a termination key such as ‘exit’ key in the remote controller, the user can terminate the TV application by using the termination key.
          • In case of web platform that does not allows execution of multiple TV applications, the user can terminate the TV application through execution of other application.
          • In case of web platform that allows execution of multiple TV applications, this is for further study.
            • In this case, web platform must provide a means to explicitly terminate the running TV application.
        • NOTE-more method should be considered.
    • Priority
      • For case of web platform that does not allows execution of multiple TV applications:
        • When the broadcast-independent application is executed, the delivery of the broadcasting stream should stop.
      • For case of web platform that allows execution of multiple TV applications is for further study.
        • The TV application executed by the user should have higher priority than the TV application executed by the AIT signalling.
  • Issues for discussion:
    • Should we consider web platform that allows execution of multiple TV applications?.
      • example 1) Recording broadcasting stream while playing a game
      • example 2) Watching the broadcasting stream while playing a game

Procedures

Proposal submission process

  1. Submitter writes a proposal on the Wiki using (filling the use case description)
  2. The target use case is described, including use case, proposed technology, ...
  3. An Editor or moderator will consolidate information
  4. Each use case is discussed into the mailing list

Please use appropriate tags in mail subjects to keep the discussion visible and isolated (e.g. : [Terminal][Test case X])


Notes
  • Propose more template?

Discussion & Calls

  • The TF intends to work with e-mail only
  • During AC or TPAC, some f2f shall be organized
  • If needed, we can leverage IRC or Conf call facilities, but it should remain a less-likely option

Relevant work in other fora

Metadata Formats / Vocabularies

On the mailing-list, a few participants have mentioned existing work on media metadata. References will be listed here.


Participants

  • JC Verdié (MStar)
  • JC Dufourd (Telecom ParisTech)
  • Geun-Hyung Kim (Mobile Web Forum)
  • Wook Hyun (ETRI)
  • Sung Hei Kim (ETRI)
  • Giuseppe Pascale (Opera)
  • Christian Fuhrhop (Fraunhofer FOKUS)
  • Raphael Troncy (EURECOM)
  • Kaz Ashimura (W3C)
  • Calin Ciordas (Irdeto)
  • Olivier Thereaux (BBC)
  • Pablo Cesar (CWI)
  • Paul Gausmsan (ATT)
  • Bob Lund (CableLabs)
  • José Luis Redondo (EURECOM)
  • Mark Vickers (Comcast)
  • Sheau Ng (NBCUniversal)
  • Yosuke Funahashi (Tomo-digi)
  • Graham Clift (Sony)
  • Pierre Lemieux (supported by MovieLabs)
  • Jean-Pierre Evain (EBU)
  • David Corvoysier (Orange)
  • Geun-Hyung Kim, (Mobile Web Forum)
  • Edit and add your name here