HNTF/Home Network TF Requirements

From Web and TV IG

Jump to: navigation, search

Contents

Requirement Document Draft

(ONLY THE EDITOR SHOULD CHANGE THIS DOCUMENT)

This section contains the draft for a requirement document as discussed by Home Network TF. This is a best-effort attempt to summarize the consensus reached so far by the TF but is still to be considered a draft to subject to change at any time.

Abstract

There is an increasing amount of personal and streaming (broadcast) content that users would like to be able to access from any device in the home (personal computers, tablets, mobile phones, TVs and others).

Growing numbers of consumer electronic devices such as TVs and mobile phones can access internet based services as well as content originating from both home network devices and broadcast services.

There is also growing interest in providing richer and novel user experiences that provide a cohesive experience across multiple devices including TVs, mobile phones, tablets and others.

This document lists the design goals and requirements that proposed W3C recommendation should support in order to enable access to services and content provided by home network devices on other devices, including the discovery and playback of content available to those devices, both from services such as traditional broadcast media and internet based services but also from the home network.

Status of This Document

This document is merely a public working draft of requirement(s) for potential W3C recommendations. It has no official standing of any kind and does not represent the support or consensus of any standards organization.

Introduction

There is an increasing amount of personal and streaming (broadcast) content that users would like to be able to access from any device in the home (personal computers, tablets, mobile phones, TVs and others).

Growing numbers of consumer electronic devices such as TVs and mobile phones can access internet based services as well as content originating from both home network devices and broadcast services. For example, many commercial video providers currently provide the ability for a user to access content stored on a home network device (e.g. a digital video recorder, DVR) or from a network connected set-top-box, STB. A home network content discovery and control protocol is used by the DVR and STB to provide this access, through a native user interface on the device.

The dominant scenario today is for a home network device to both discover and playback home network content. Examples of these devices may include a personal computer or a connected television. This is commonly referred to as a 2-Box model. An emerging scenario is for the content discovery and control to take place on a separate handheld device, such as a smartphone or tablet computer, and for the handheld device to instruct a content player, a connected television for instance, to playback content from a content server such as a DVR. This is referred to as the 3-Box model.

In all use cases, security mechanisms are made available to protect user privacy and content owners’ rights.

There is currently no formally standardized way to build a web application that is able to use content discovery and control protocols to get access to the content available on different devices in the home network. This document lists the design goals and requirements that future W3C recommendations need to address in order to cover such gap. This would enable content providers to deliver web applications to any conforming device in order to enhance and harmonize the user experience

Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

This specification only applies to one class of product: W3C Technical Reports. A number of specifications may be created to address the requirements enumerated in this document. In some cases the union of multiple parts of different specifications may be needed to address a single requirement. Nevertheless, this document speaks only of a conforming specification.

A conforming specification is one that addresses one or more requirements listed in this document. A conforming specification should attempt to address requirements marked with the keywords "should" or "may" unless there is a technically valid reason not to do so.

Terminology

  • programme (program)

A programme (program) comprises a single period of audio visual content. It is usually expected to be labeled in content directories or television programme guides as a single entity. This might include an episode of a television programme, a radio programme, or a movie.

  • device

For the purposes of this document, a device is any piece of equipment connected to the home network. Note that this is a generic term that includes also television definition below.

  • television

A device that presents programme content from a variety of sources - such as received via broadcast (cable, satellite, terrestrial), on-demand streaming services, or streamed from other devices in the home (e.g. PVR). Within the scope of this document, it is presumed that a television is connected to the home network.

  • service

For the purposes of this document, a service is any functionality available on a device, such as the ability to playback audio/video content, record content, print documents etc.

  • document

An individual resource that adheres to a certain content type, ranging from short static documents to long essays or reports with rich multimedia. For simplicity, terms such as shown, displayed, and visible might sometimes be used when referring to the way a document is rendered to the user. These terms are not meant to imply a visual medium; they must be considered to apply to other media in equivalent ways.

  • application

For the purposes of this document, the term "Application" refers to a collection of documents (not necessarily delivered over HTTP) which use server-side or client-side processing (e.g. JavaScript) to provide an "application-like" experience within a Web browser or other kinds of Web run-time. Applications may include locally executable elements of interactivity and persistent state. Note that locally stored applications like W3C Widgets are also covered by this definition.

  • home network

For the purposes of this document, the term "home network" refers to the networking infrastructure that facilitates Internet Protocol communications between devices within the home. This may range from a single legacy IPv4 subnet to multiple IPv4 subnets and dual stack or IPv6 environments and will typically (but not always) be connected to the Internet.

  • content item

For the purposes of this document, the term “content item” refers to metadata describing or more binary versions of media. The media described by an item may either be stored or streamed. A single content item may refer to multiple media binaries that represent different formats for the content being described.

  • channel item

For the purposes of this document, the term “channel item” refers to an “item” describing a streaming source. A channel item may contain metadata describing the channel source such as channel number, distribution network, etc. A channel may not be available on the home network, i.e. the “channel item” may refer to a channel that can only be locally tuned. In these cases “channel item” metadata will not provide network addressing information (URLs) to connect to the channel source.

  • epg (electronic programming guide) item

For the purposes of this document, the term “epg item” refers to an item that may be available with some defined time range. An “epg item” may contain metadata describing the channel source for the content and the time range the channel media will be available.

  • record schedule (item)

For the purposes of this document, the term “record schedule” refers to an item which contains metadata describing a request to a network recording service to record content. “Record schedule items” may include: simple time/duration requests, recording of a specific “epg item”, and recording dynamically selected “epg items” based metadata properties of desired content. “Record schedule items” additionally include metadata describing the status of the recording request.

  • record task (item)

For the purposes of this document, the term “record task item” refers to an item which contains metadata describing a pending or completed network recording operation. “Record task items” are created by a network recording service and allow network record service clients to control pending recording operations. Additionally, “record task items” include metadata describing the status of the recording request and the identity of “content items” that represent the results of network recording operations.

Requirements

This section enumerates the requirements that conforming specification(s) would need to address to enable discovery and control of devices and services in the home network by a user agent. These requirements are directly motivated by the #Use cases described in this document and are based on an interactive process of feedback from the discussions in the Home-Network Task Force of the Web & TV IG

General

Compatibility with widely deployed standards

Several home network protocols (e.g. UPnP, M-DNS/DNS-SD) are in popular use today for advertising and sharing content and services in a home network environment. A conforming specification shall set out requirements for an API that would enable interaction with those protocols.

Discovery and Advertising

Service Discovery

Conforming specifications should provide a means for applications to discover devices and applications in the home network which advertise services. Details of the advertising protocols are out of scope for this document and the type and number of supported discovery protocols is user agent dependent. Nevertheless conforming specifications should provide a means for application search for specific services and to be able to determine the means by which it should communicate with that service.

Application Discovery

Conforming specifications should provide a means for applications running in different user-agents to discover each other directly via the home network. Details of the advertising protocol are out of scope for this document.

Content Discovery

Conforming specifications should provide a means for applications to discover devices in the home network capable of serving content (content servers). In addition, conforming specifications should provide a mechanism to retrieve a list of the available content, provide additional information (metadata) about the content and to support negotiation of a supported content format between content servers and content players.

Content Advertisement

Conforming specifications should provide a means for application to expose content description to a service on the home network. Other devices or applications on the home network should be able to playback the content served by the application and retrieve additional metadata about the served content.

Services Advertisement

Conforming specifications should provide a means for application to expose and advertise services on the home network.

Media Identification

Conforming specifications should provide applications with a means to identify and thereby recognize a program that may be available from devices or services on the home network, when such an identifier is available. Such identifiers should be unique to a program, but common across multiple instance of the same program; and should be consistent across different services and devices in different home networks.

Control and Communication

Control of content players

Conforming specifications should enable applications to know what content that can be presented by a device or service on the home network and control the playback of that content presented, in such a way that the application does not have to handle:

  • issues of codec, container format, or transport protocol compatibility
  • differences in the mechanisms by which content is delivered to the rendering device (e.g. received from broadcast vs. streamed from a media server)

Control of content recorders

Conforming specifications should enable applications to control recording of content presented by devices or services within the home network, in such a way that the application does not have to handle:

  • issues of codec, container format, or transport protocol compatibility
  • differences in the mechanisms by which content is delivered to the rendering device (e.g. received from broadcast vs. streamed from a media server)

Playback of content

Conforming specifications should provide a means to playback content advertised by a home network content server.

Playback of live content

Conforming specifications should provide a means to playback live content advertised by a home network content server.

3 Box model

Conforming specifications should provide a means for controlling the playback of content from home network content servers to home network content players. Conforming specifications should support means to negotiate a supported content type format that is available on the content server and is suitable for being played on the content player.

Time-synchronization

User-agents should provide applications with a means to co-time the presentation of their own content (audio, video or other) with the timeline of a programme being played back on another device, including programmes being received via broadcast. Conforming specifications should provide applications with a means to be aware of the progress (time within the programme) of the playback of media content on a remote device/service, including programmes being received via broadcast

Accurate time-synchronization

Conforming specifications should support any protocols or optional protocol features that enable applications to be aware of the progress (time within the programme) of the playback of a programme on a remote device to within frame accuracy (1/25th or 1/30th second) or better. Conforming specifications should support the ability to determine an estimate of the level of accuracy with which timing information about media playback on a remove device/service is conveyed to applications.

Service Communication

Conforming specifications should provide a means for an application to exchange messages directly via the home network with services discovered in the home network.

Application communication

Conforming specifications should provide a means for applications to exchange messages directly via the home network with other applications running on a different user agent in the home network.

Content Protection

Conforming specifications should support the content protection mechanism for a content item used by a content server in order to playback that content item. Conforming specifications must provide a graceful failure model when a content protection mechanism is not supported.

Migration

Push migration

Conforming specifications should provide a means to transfer an application to a different user agent in the home network without requiring support of an application server.

Pull migration

Conforming specifications should support transfer an application to a different user agent in the home network without requiring support of an application server. The request is initiated by the target user agent.

Security and Privacy

Application trust level

Conforming specifications provide a means to define the trust level of an application. Determining the trust level may involve interaction with the user and the use of security mechanisms such as password, PIN etc.

Access to home network services

Conforming specifications should allow access to home network devices and services only to trusted applications

Prevent leaking of information

Conforming specifications should prevent unauthorized transfer of information outside the home network.

Use cases

This section is a non-exhaustive list of use cases that would be enabled by one (or more) specifications implementing the requirements listed above. Each use case is written according to the following template: 

Ux. <TITLE>
Original Proposal: ISSUE-n

Description: 
* high level description/overview of the goals of the use case
* Schematic Illustration (devices involved, work flows, etc.) (Optional)

Motivation: 
* Explanation of benefit to ecosystem
* Why were you not able to use only existing standards to accomplish this?

Dependencies:
* other use cases, proposals or other ongoing standardization activities which this use case is dependent on or related to

Requirements:
* List of requirements implied by this Use Case.

U1. Service User Interface

Original Proposal: ISSUE-4

Description: An application as an interface to a service: the application provides a remote user interface for a device (light switch, HiFi volume control, radio station chooser, etc.) or a service on a device (remote control on the media player software on a computer).

Possible implementation:

  • the application discovers services with a discovery protocol, selects one service of a certain expected type, e.g. a media renderer service.
  • the application binds to it and provides a UI for it.
  • on user interaction, the application sends the messages to set the content url to play then play, pause, ... to the media renderer service, with appropriate parameters.

Motivation: There is no standard interface to discovery protocols in existing standards implemented in connected devices. There is no standard interface to service communication protocols in existing standards implemented in connected devices. What should be standardized is:

  • an interface to get a list of discovered services;
  • an interface to get the list of messages exposed by a discovered service;
  • an interface to send a message to a discovered service;
  • an interface to set a listener for messages from a discovered service.

Dependencies: In order to interface with a service, the application first needs to discover the service (or the device, then the service on the device).

Requirements:

Low Level High Level
Determine list of discovered services #Service Discovery
Determine list of messages exposed by a discovered service #Service Discovery
Send a message to a discovered service #Service Communication
Listen to messages (possibly unsolicited) from a discovered service. #Service Communication

U2. Discovered content host

Original Proposal: ISSUE-5

Description: A document as host for discovered content: e.g. the document describe content provided by a local, discovered device or service.

Motivation: Rendering a media on another device than the one hosting is the basic step to enable more complex use cases.

Requirements:

Low Level High Level
Support a document which displays discovered content #Playback of content

U3. Service Migration

Original Proposal: ISSUE-7

Description: An application moving across HNTF user agents in a decentralized situation (local application, without a server).

A radio service is split into a radio application which resides typically on a HiFi, TV, personal music player or computer, and a radio controller application which resides on a device with intuitive interaction capability such as a phone, computer or tablet. The radio application is implemented as a document exposing a service interface on the network, and has a state that needs preserving if the document is migrated. The radio controller application is a pure interface, and does not have its own state.

The radio application does not have a visual interface. The radio application exposes a service of type JCDsRadioApp with seven possible messages:

  • setURI(radioStationURI, radioName),
  • play(),
  • stop(),
  • setVolume(n),
  • getURI(),
  • getRadioName(),
  • getPlayState(),
  • getVolume().

The radio application is running on a TV set.

The radio controller application has a visual interface, comprising:

  • a button to choose the radio station.
  • a play button.
  • a stop button.
  • a label for the current radio station name.
  • a volume bar to display the current volume.
  • two buttons to increase and decrease the volume.

The radio controller application is running on a smartphone. The radio controller application looks for a service called JCDsRadioApp by using the HNTF discovery mechanism, then establishes a connection with the above application. The radio controller application gets the radio name, volume, play state of the radio application and displays that information.

The stage is now set.

The user wants to move from the TV in the main room to the computer in her office:

  • In the HNTF user agent on the TV, the user requests to migrate the radio application.
  • The TV HNTF UA looks for other HNTF UAs on the network, by discovering service "HNTFUserAgentv1.0".
  • The result of the discovery is a list of HNTF UAs: the one on the phone, the one on the computer, possibly other ones.
  • The user selects the HNTF UA running on the computer.
  • The TV HNTF UA sends the message migrate(appURI, contextURI) to the computer HNTF UA.
  • The computer HNTF UA requests the appURI to get the radio application, then requests the contextURI, which contains all the information needed to place the radio application in the same state it was in on the TV.
  • The computer HNTF UA loads the radio application, then the context. Loading the context first sets the volume to half and the station to "Jazz".
  • Then the computer HNTF UA exposes a service of type JCDsRadioApp.
  • Then the smartphone HNTF UA understands that its connection to the radio application in the TV is down, so it starts again a discovery of service type JCDsRadioApp. It finds one on the computer HNTF UA, and sends a connection request.
  • The computer HNTF UA receives a connection request from the device mentioned in the migration context as formerly connected. It accepts the connection without requiring a user validation.

End of migration.

When moving the radio document, the following needs to be preserved:

  • the service needs to be restarted and exposed on the new device
  • the connection to the (same) radio controller needs to be reestablished
  • the radio needs to be playing the same station, with the same volume, etc.

Another possible example is a multi-user game, e.g. with lots of players sending location and activity information about their character/cars. Upon migration, the game state needs to be transferred to the new device, and the connections to other players need to be reestablished.

Motivation:

  • no way to discover a service from an application
  • no way to expose a service from an application
  • no way to move an application to another device and restart it while keeping an execution context

Dependencies: This use case depends on discovery. This is a refinement of ISSUE-15, where the migrated document uses a service rather than exposes a service.

Requirements:

Low Level High Level
User-Agents support a service to transfer a running Application to different User-Agent. #Push migration
Applications support the ability to save their current state and provide this information via a contextURI. #Push migration
Applications support the ability to restore their state on a different User-Agent using state information provided by a contextURI. #Push migration

U4. Service Distribution

Original Proposal: ISSUE-8

Description: An application spawning other applications on other devices and communicating with them: e.g. the TV set receives and renders an application implementing some voting; the application discovers multiple phones in the home, proposes to activate voting interfaces on each of the viewers' phones, communicates with the voting interfaces, collates votes and sends them back to the channel's voting service.

Possible implementation:

  • The TV receives a connected TV application for voting, which starts automatically.
  • The application exposes a service on the HN to collect votes and forward them to the TV channel.
  • The application discovers personal interactive devices (phones and tablets for our case) running the HNTF document UA which exposes a recognizable service.
  • The application sends a suggest message with a URL to a voting interface.
  • Willing users accept the suggested migration and their UA loads the voting interface.
  • The voting interface document loads and discovers and binds to the vote collecting service.
  • The user votes
  • The voting interface document sends a vote message to the vote collecting service.
  • The vote collecting service exposed by the TV application receives the vote message and forwards them for a certain voting period.
  • At the end of the show (or of the voting period), the application is killed by the TV system, so the voting collection service disappears.
  • Seeing the voting collection service disappear, the voting interfaces may shut down.

This use case does not require new technology, but reuses technology required by other use cases. Technologies required by other use cases are:

  • the ability to discover
  • the ability to expose a service

This use case requires:

  • the HNTF UAs to implement a service which could be called "HNTF service", so that documents can discover other "HNTF UAs"
  • the HNTF service to include a "suggest" message telling the UA to please render a document given by URL
  • maybe the HNTF service to include a message allowing a document to determine its capabilities, to be able to segregate between devices appropriate for voting or not.

A few sketches for clarification:

File:ServiceDistributionUC1.jpg

File:ServiceDistributionUC2.jpg

File:ServiceDistributionUC3.jpg

File:ServiceDistributionUC4.jpg

File:ServiceDistributionUC5.jpg

Motivation:

This is the generic version of a crucial "second screen" usage scenario.

As there are more devices in the home, some generic and some task-specific, and with varying capabilities (including different UI methods), there is a growing need to spread an application across different devices to achieve service distribution. But the service usually "enters" the home network through one particular device. The service running entirely on the initial device, as part of other use cases, can discover its environment and determine that other devices could meaningfully contribute to the quality of experience. From then on, the service needs to send part of "itself" to other devices.

Dependencies: Depends on Service UI, Document Responding to Requests, Document Exposing a Service, Document Discovering a Service

Requirements:

Low Level High Level
A document exposes an interface to a service. #Service Discovery, #Service Communication

U5. 3-Box model

Original Proposal: ISSUE-10

Description: A document as an interface coordinating action between other services. In the most obvious example, a document discovers media content sources and media players. The document allows the user to select a source and a player, then control playback (Play, pause, rewind, etc.) of the content to the player.

Motivation: Assets offered by one service (on one device) can be consumed by another service (on another device) and controlled by a separate controlling document (on a third device). Vendors can offer control services to manage services across the whole home.

Dependencies: This is similar to Service User Interface (ISSUE-4) but it explicitly manages services between independent devices, multiple simultaneous connections.

Requirements:

Low Level High Level
An application may invoke services to control devices on other User-Agents separate from the User-Agent issuing the service requests. #3 Box model

U6. Application Exposing a Service

Original Proposal: ISSUE-12

Description: An application exposes a service on the home network. In order to allow this with some technologies, it may be necessary for the HNTF user agent to advertise itself on the HN as a device. For example, an application rendered on a connected TV has access to the connected TV API for EPG information. Other devices on the HN do not have access to this information. The application implements a service exposing the EPG information and makes it discoverable by other devices.

Possible implementation:

  • the application A is a TV-broadcast-related application, which is allowed to call the function returning the description of the next program.
  • the application A exposes a service with one message getNextProgramDescription.
  • application B on another device discovers the service (not knowing that it is an application, it is just another service to application B).

Neither application A or B know the actual nature of the other. They may have an IP address, and they share a service type.

Motivation: Allowing sharing resources other than content, such as a capability (a large screen, a sensor) or an "authorization" (permission to use a restricted API).

Dependencies: This is a prerequisite to applications discovering each other without a "middle man": one of the two applications exposes a service that the other application may discover.

Requirements:

Low Level High Level
An application can cause a User-Agent to act as a device which exposes services. #Services Advertisement

U7. Application Discovering a Service

Original Proposal: ISSUE-14

Description: An application discovers a service. Discovery means that after discovery, the application has:

  • an identification of a device (maybe) and a service;
  • a means to know the messages that can be exchanged, possibly with their parameters;
  • a means to send messages to the service, if the service may receive messages;
  • a means to receive messages from the service, if the service may send messages.

Motivation: Very basic use case, on which all other use cases depend. There is no existing way for an application to discover services and communicate with them, if the author did not have the address of the service.

Dependencies: None

Requirements:

Low Level High Level
An application can determine allowable messages and parameters provided by a service. #Service Discovery
An application can send messages to a service. #Service Communication
An application can receive messages from a service #Service Communication

U8. Application Push-Migration

Original Proposal: ISSUE-15

Description: An application moving across devices in a decentralized situation (local application, without a server).

I start using my phone for the user interface to a device and then my tablet becomes available, so I move the interface application to the tablet. The application in question is an HNTF application, which means it has discovered services and has connections to some services and a history of execution. Just restarting the application on another device would lose the execution state, the existing connections, etc...

  • I start using my phone as a UI of a service on my TV, e.g. EPG, but the screen is small.
  • My tablet finally becomes available.
  • I request the migration of the current application: this is a user agent function.
  • The user agent discovers its peers on the network, i.e. other user agents capable of running the current document.
  • The user agent proposes to me a list of suitable user agents, including the one running on the tablet.
  • I choose the user agent running on the tablet.
  • The UA on the phone binds to the UA on the tablet, and sends a migration message with the URL of the document, and the URL of the execution state.
  • The UA on the tablet receives the migration message, fetches the application and the execution state and loads both.
  • The UA on the tablet signals to the UA on the phone that migration is complete, by replying "success" to the migration message.
  • The UA on the phone stops rendering the migrated application.
  • I pick up the tablet and go on with the service at the point I left it on the phone.

Motivation: There is no way with current standards and in the absence of a central server to achieve the saving and transfer of the execution state of a widget, so there is no way to start an application on a device, switch devices and restart the application on the new device, keeping the exact same execution state.

Dependencies: This use case depends on discovery.

Requirements:

Low Level High Level
User-Agents support a service to transfer a runningapplication from another User-Agent to itself. #Push migration
Applications support the ability to save their current state and provide this information via a contextURI. #Push migration

U9. Application Pull-Migration

Original Proposal: ISSUE-25

Description: An application moving across devices in a decentralized situation (local application, without a server), the migration being initiated on the target device.

I start using my phone for the user interface to a device and then my tablet becomes available, so I move the interface application to the tablet by interacting with the tablet. The application in question is an HNTF application, which means it has discovered services and has connections to some services and a history of execution. Just restarting the application on another device would lose the execution state, the existing connections, etc...

  • I start using my phone as a UI of a service on my TV, e.g. EPG, but the screen is small.
  • My tablet finally becomes available.
  • I drop my phone.
  • I take the tablet, start the HNTFUA and request a list of discoverable HNTFUAs on the tablet: this is a user agent function.
  • I start the HNTFUA of the phone and request from it a list of pullable applications and I choose one in the list.
  • The UA on the tablet sends a pull-migration message with the identifier of the wanted application chosen from the above list.
  • The UA on the tablet receives the response to the pull-migration message, i.e. the url of the application and the url of the execution state, fetches the application and the execution state and loads both.
  • The UA on the tablet signals to the UA on the phone that migration is complete.
  • The UA on the phone stops rendering the migrated application.

Motivation: Same as ISSUE-15, with the additional twist of triggering the migration from the target device rather than the source device.

Requirements:

Low Level High Level
User-Agents support a service to notify a running application of a request to transfer itself to another User-Agent. #Pull migration
Applications support the ability to save their current state and provide this information via a contextURI. #Pull migration

U10. Media Identification

Original Proposal: ISSUE-19

Description: Where available, applications should be able to determine and refer to programmes using a unique and consistent identifier. If the same programme is available from multiple devices or services, the programme should have the same identifier associated with it across all devices or services.

Scenario: An application, wants to present more information associated with a particular programme that the user is currently viewing on their television, without the television acting as an intermediary that serves that additional information.

  1. The application discovers an appropriate service
  2. The application sends a request to the service to return an identifier for the programme currently playing on the television
  3. The application discovers a service that can return metadata for an identified programme
  4. The application sends a request to the service to retrieve a unique identifier for the programme that was assigned by the original broadcaster, content publisher or content creator
  5. The application contacts an internet service that can resolve identifiers to additional programme metadata
  6. The internet service returns additional metadata for the programme


Motivation:

  • Allows anyone (not just the original content creator or distributor) to create an application that can associate programmes with metadata and web based content; without that metadata or content having to be delivered, or referenced by data served from services on the television or set top box.
  • Recommendations to be fed to any groups defining home network protocols to add global content identifier support where not present
  • Areas for standardization: (Application specific API/protocols)
    • Requirement for any high level media playback API abstractions (see issue-20) should include the ability to:
      • expose such identifiers as part of programme metadata
      • search for programmes using such identifiers
      • request playback of a programme using such an identifier
    • This use case does not suggest mandating a particular identifier format.

Dependencies: TV Querying and Control use case (for outlined user scenario)

Requirements:

Low Level High Level
Provide consistent program identifiers which are meaningful across multiple devices. #Media Identification
Provide services to provide metadata corresponding to program identifiers. #Media Identification

U11. TV Control

Original Proposal: 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 provide:

  • 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 to be presented by a rendering device, irrespective of the above factors.

It is also desirable 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, utilize 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 currently 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.

Motivation:

  • 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.
  • Standardization 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 standardized:
    • 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)

Requirements:

Low Level High Level
Provide a directory of programs a rendering device can play. #Control of content players
Provide a service to select a program on a rendering device to play. #Control of content players
Provide services to control other aspects of a rendering device such as Seek, Volume, etc. #Control of content players

U12. Time Synchronization

Original Proposal: ISSUE-21

Description: Applications should be able to time synchronize their activity with the time-line of a programme being played on a television or other home media rendering device.

Application developers will benefit from having a single simple API that provides a unified interface to this functionality, irrespective of the means by which the programme is being delivered to, or played by, the television device.

The application is running on a different device from where the programme is being played. This could be a laptop, mobile phone, tablet, etc. Both devices are on the same home network. The device playing the programme may be a television or other media rendering device. The programme being played may be being obtained by a variety of different means:

  • from a live broadcast via an integrated tuner
  • playback from local storage (e.g. a Personal Video Recorder device)
  • streaming from another device on the home network
  • streaming from an on-demand internet service

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, utilize existing home networking protocols to perform its function. For example: it may use UPnP AV services to query and set the playback time index.

An API meeting these requirements may enable an application to:

  • request the current playback time index of the programme being played on a given device
  • command the device to jump to a different playback time index
  • request notification when programme playback reaches a particular moment or time interval in the programme timeline.

Scenario: An application wants to present a slideshow of content relating to the programme the user is watching on their television. As the programme progresses, the slideshow automatically moves onto the correct slide for any given point in the programme. If it is possible to seek within the programme timeline (because the programme is not being watched from a live broadcast), the user can use the application to jump to a different point in the presentation and the television will also seek to the corresponding segment of the programme.

Motivation:

  • 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.
  • Enable the creation of added-value viewing experience for the user where additional information is available in a timely fashion without interrupting the TV viewing experience or increasing on screen 'clutter'.
  • What could be standardized:
    • Type of use case: Application specific services / protocols / APIs
    • A Javascript API
    • Services or protocols implemented by devices on the home network

Dependencies:

  • Application discovering a service (issue 14)
  • Media Identification (issue 19) - required for an application to know which content to provide for the programme being watched in the described scenario
  • This use case could be considered an extension of the TV Control (issue 20) use case

Requirements:

Low Level High Level
Provide ability to generate notification to application when a particular playback time is reached. #Time-synchronization
Provide the ability to position playback to a specified time-index. #Time-synchronization
Obtain the current playback time-index. #Time-synchronization

U13. Lip Sync Time Synchronization

Original Proposal: ISSUE-22

Description:

This use case is a specialization of the use case: Time Synchronisation (issue-21)

An application should be able to synchronize the presentation of its own content with a high degree of accuracy to the timeline of a programme being played on a television or other home media rendering device. The level of accuracy should be sufficient to achieve 'lip-sync' between audio and video (typically within 1 to 2 video frames or tens of milliseconds).

In addition to the functions described in the Time Synchronisation use case; the API used by the application should be able to:

  • report an estimate of the timing synchronism accuracy that is achievable
  • provide synchronization to within lip-sync accuracy if all devices involved support it

The processing engine that implements the API may utilize existing home networking protocols to achieve the required accuracy. A likely necessary component will be the synchronization of clocks between the television or media rendering device and the device on which the application is running. Possible protocols that might be used to achieve this include: Precision Time Protocol (IEEE 1588-2002) IEEE1588, IEEE 802.11AS, UPnP Precision Time Synchronization UPNPAV4.

Applications will benefit if the API presents a simple unified set of functions such that the application does not need know which protocols are being used.

Scenario: An application plays alternative audio that is time synchronized to a programme that the user is watching. The synchronization is sufficiently accurate to maintain 'lip-sync' between the alternative audio and the programme video. The alternative audio may be delivered to the application independently of the television device - such as via a direct stream from a broadcaster's internet based server.

Motivation:

  • Simplify creation of applications requiring lip-sync accurate time synchronization that will work with a range of devices and variety of means by which a given programme might be played on the television.
  • What could be standardized:
    • Type of use case: Application specific services / protocols / APIs
    • A Javascript API
    • Services or protocols implemented by devices on the home network

Dependencies:

  • This use case is a specialization of the Time Synchronization use case

Requirements:

Low Level High Level
Determine the time synchronization capabilities of home-network devices. #Accurate time-synchronization
Provide the capability for applications to synchronize with playback content to approximately frame resolution. #Accurate time-synchronization
Provide the capability to precisely synchronize multiple content streams #Accurate time-synchronization

U14: Local Link of Web Applications

Original Proposal: ISSUE-24

Description:

  • This use case is about the bi-directional communication between web applications via the local IP network e.g. Home IP network
  • Assumptions:
    • User devices are connected to the same local IP network
    • The applications on user devices know each other and can exchange messages for communications
    • Note that the applications may not necessarily be provided by the same distributor or service provider
    • A user uses the IR remote controller to operate the HTML5 browser on the TV device (10 feet UI)
    • A user uses the touch screen to operate the HTML5 browser on the tablet device or smart phone (Touch UI)
    • Note that the application may not necessarily to be a web application as long as it communicates by the same network protocols as the user-agent does.
  • User Scenario A - Single User
    • Bob operates the TV device to watch movies on an online video service
    • Bob also operates the tablet device to access a social network service about movies
    • Bob views web pages of the social network service and find a favorite movie
    • Bob clicks the “your device” button on the web page of the social network service
    • The application on the TV device show the web page of the video service about the movie, then Bob starts to watch the movie
  • User Scenario B - Multiple Users
    • Bob operates his smart phone to use an application for a picture service
    • Alice operates her smart phone to access another picture application
    • Bob selects his favorite picture and clicks the “Sharing photo with other device” on the application
    • The application on Bob’s device shows the device name list and he selects the Alice’s device
    • The picture file is transferred from the Bob’s device to the Alice’s device while each application shows the progress bar of file transfer
    • After the transfer is completed, the application on the Alice’s device shows the Bob’s favorite picture
  • User Scenario: Interactive quiz
    • Alice and Bob operates the TV device to watch a quiz programme, from live broadcast
    • Alice and Bob also operate their smart phones to access a quiz application
    • Note: The smart phone quiz application knows that the quiz programme is being watched on the TV and establishes communication with an interactive application on the TV that is active during the quiz programme)
    • The TV application overlays on-screen information informing Alice and Bob that they are now taking part in the quiz.
    • As a question is asked in the quiz programme, the interactive TV application instructs Alice and Bob's smart phone quiz applications to ask Alice and Bob the same questions. Alice and Bob enter answers to the questions using their smart phones, which are relayed back to the interactive TV application.
    • Between quiz rounds, Alice and Bob's scores are displayed on their smart phones and overlayed on screen by the TV interactive application. Scores are compared to those of the contestants featuring in the programme.
    • Note: Regarding need/justification: Using local-link communication to an interactive application provided as part of a broadcast stream provides a way around scalability concerns if participation is substantial for a particularly popular programme.
  • Use case (System Interactions)
    • An User-Agent discover other Users agent on the same IP-sub network
    • Via API, the User-Agent provides the discovered application list which contains the applications which are running on other user-agent, e.g. application id, the URL for message exchange, physical device name(for user selection)
    • The application establishes the bi-directional communication for message exchanges with the application on the other user-agent via API
  • Implementation Examples
    • For the local discovery, the HTML5 browser implements UPnP Discovery to provide the generic discovery API to find applications on the same IP sub-network
    • For the message exchange, the HTML5 browser implements the extended WebSocket protocol and APIs for bi-directional communications
    • The HTML5 browser should implement some mechanism to confirm the user consensus to permit the device discovery and message exchanges for the applications
  • Additional comments:
    • The above user scenarios are examples. As long as the message exchange API is service/application agnostic, many rich user experience can be realized as the open web platform does

Motivation

  • The “Local Link” enables applications to exchange message, e.g. String, Blob, via the local network directly. Without the “local Link”, the applications which are running on different devices can in-directly communicate via a service on the Internet. But, the “Local Link” has the following benefits
    • Adhoc: Without any syndication of services, the applications provided by different services can communicate each other's in ad-hoc. Also, all devices are not required to be bound to the same service. This is a kind of service mash-up using multiple devices
    • Efficient: A large size of files can be transferred between devices via high bandwidth local network connection.
    • Off-line: Even if the Internet access is not available, the applications can still communicate
    • Use-centric: Users can easily recognize which devices communicate. Only devices on the same network are listed and the communications of different user device are based on the user consent
  • There are some standards of local discovery, e.g. UPnP, Bonjour, WS-Discovery, but there is no standard of the JavaScript API which enables communications between Web applications in the manner of application/service agnostic
  • What needs to be standardized:
    • Type of use case: Generic APIs
      • General service discovery and messaging APIs should be standardized
      • Network protocols for the APIs should be specified

Dependencies:

  • Any other use cases related to the local IP network discovery since the discovery is also application/service agnostic

Requirements:

Low Level High Level
Support applications communicating with each-other via ad-hoc messages. #Application communication, #Application Discovery

U15. Home Network Enabled User-Agent - Network Media Player

Original Proposal: ISSUE-26

Description:

  • Enable a User-Agent to act as a Home Network Media Player

Scenarios

  • The User-Agent acts as a Home Network Media Player device. For example:
  1. List available Home Network Media Server devices. Steps
  2. List available content on a Home Network Media Server. Steps
  3. List available content on a Home Network Media Server matching specified metadata criterion. Steps
  4. Determine capabilities of User-Agent playback facilities provided to Home Network Media Player. Ex: supported content formats, number of streams, supported resolution(s).
  5. Play content from a Home Network Media Server. Steps
  6. View EPG data from a Home Network Media Server. Steps
  7. Tune and play live programs from a Home Network Media Server capable of streaming live content. Steps
  8. Select and play recorded content from a Home Network Recording device. Steps
  9. Select and play time-shifted content. Steps


Steps:

  • The User-Agent acts as a Home Network Media Player device.
    1. List available Home Network Media Server devices.
      1. Web page issues a method to discover home network devices
      2. User-Agent gets an event indicating the list is ready.
      3. User-Agent retrieves a list of handles representing the discovered devices
      4. Web page issues a method to get information about each discovered device
      5. Web page retains handles for devices of the appropriate type.
      6. Web page displays available devices to end-user.
      7. End-User selects one of the displayed devices.
      8. Web page issues method to access the device.
      9. User-Agent responds that a password is required.
      10. Web page obtains the password from the end-user (or secure password store) and issues method to provide the password to the User-Agent
      11. Web page can now access the device.
    2. List available content on a Home Network Media Server.
      1. Web page formats an action request to browse the Home Network device metadata containers for EPG Items matching desired channel/time ranges.
      2. Web page issues method to send action request to selected Home Network device
      3. User-Agent sends request to Home Network Media Server device.
      4. User-Agent generates event when Home Network device responds (or times-out)
      5. Web page gets response (XML document) from Home Network Media Server device.
      6. Web page displays containers and items as indicated in XML document
        This depends on the data representation of Home Network Media Server content metadata.
      7. Web page displays the information in the Home Media Server response.
    3. List available content on a Home Network Media Server matching specified metadata criterion.
      1. Web page formats an action request to determine searchable metadata on the selected Home Network device metadata store.
      2. Web page issues method to send action request to selected Home Network device.
      3. Web page formats an action request to search the Home Network device metadata store.
      4. Web page issues method to send action request to selected Home Network device
      5. User-Agent sends request to Home Network Media Server device.
      6. User-Agent generates event when Home Network device responds (or times-out)
      7. Web page gets response (XML document) from Home Network Media Server device.
      8. Web page displays containers and items as indicated in XML document
    4. Play content from a Home Network Media Server.
      1. End-user select displayed Home Network Media Server item for playback.
      2. Web page formats an action request to browse metadata for selected item.
      3. User-Agent sends request to Home Network Media Server device.
      4. User-Agent generates event when Home Network device responds (or times-out)
      5. Web page gets response (XML document) from Home Network Media Server device.
      6. Web page selects media binary format that is compatible with User-Agent.
      7. Web page displays Media Player using HTML5 <video> element.
      8. Web page transfers item URL to <video> element @src (or creates

        Invalid language.

        You need to specify a language like this: <source lang="html4strict">...</source>

        Supported languages for syntax highlighting:

        4cs, 6502acme, 6502kickass, 6502tasm, 68000devpac, abap, actionscript, actionscript3, ada, algol68, apache, applescript, apt_sources, asm, asp, autoconf, autohotkey, autoit, avisynth, awk, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_mac, caddcl, cadlisp, cfdg, cfm, chaiscript, cil, clojure, cmake, cobol, cpp, cpp-qt, csharp, css, cuesheet, d, dcs, delphi, diff, div, dos, dot, e, ecmascript, eiffel, email, erlang, f1, fo, fortran, freebasic, fsharp, gambas, gdb, genero, genie, gettext, glsl, gml, gnuplot, go, groovy, gwbasic, haskell, hicest, hq9plus, html4strict, icon, idl, ini, inno, intercal, io, j, java, java5, javascript, jquery, kixtart, klonec, klonecpp, latex, lb, lisp, locobasic, logtalk, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, magiksf, make, mapbasic, matlab, mirc, mmix, modula2, modula3, mpasm, mxml, mysql, newlisp, nsis, oberon2, objc, objeck, ocaml, ocaml-brief, oobas, oracle11, oracle8, oxygene, oz, pascal, pcre, per, perl, perl6, pf, php, php-brief, pic16, pike, pixelbender, plsql, postgresql, povray, powerbuilder, powershell, progress, prolog, properties, providex, purebasic, python, q, qbasic, rails, rebol, reg, robots, rpmspec, rsplus, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, sql, systemverilog, tcl, teraterm, text, thinbasic, tsql, typoscript, unicon, vala, vb, vbnet, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xbasic, xml, xorg_conf, xpp, z80, zxbasic

Retrieved from "http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements"
Personal tools