Media APIs/HNReq Comparison

From Web and TV IG

Comparison of "Media APIs" and "Home Networking" requirements

This document is a basis for discussion. Its aim is to compare the requirements list currently (as of September 2013) being worked on by the Media APIs Task Force of the web and TV IG and the requirements published at the end of 2011 by the now-disbanded Home Networking Task Force (HNTF).


Service Discovery

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Discovery_Mechanism

Current Draft

There SHALL be a Service Discovery mechanism for a device to look for and pair with local networked services including contents provided by home appliances including set-top boxes.

in HNReq

There is an equivalent section: http://www.w3.org/TR/hnreq/#service-discovery

Conforming specifications should provide a means for applications to discover services advertised by devices and applications in the home network. 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.

Device Discovery

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Device_Discovery_Mechanism

Current Draft

There SHALL be a Device Discovery mechanism for an application to look for and pair with local networked services including contents provided by home appliances including set-top boxes.

In HNReq

There is no exact match, but the requirement for Content Discovery states:

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.


Service Aggregation Mechanism

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Aggregation_Mechanism

Current Draft

There SHALL be a Service Aggregation mechanism for local networked services including contents discovered by a device to be aggregated and bundled together so that the device can present a subscriber with the bundled services.

In HNReq

There does not appear to be such a requirement in HNReq. The use cases are covered, however, by a mix of requirements for service discovery and standard metadata.

Whether the combination of service discovery and Metadata makes the need for a standard Service Aggregation mechanism moot is to be discussed.

Service Synchronisation Mechanism

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Synchronisation_Mechanism

Current Draft

There SHALL be a Service Synchronization mechanism between the device that interacts with a subscriber and the sources of local networked services, including the content in the services.

In HNReq

The question if synchronisation is covered by two distinct sections in HNReq:

4.3.6 Time-synchronization

Conforming specifications should provide a means for applications 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.

4.3.7 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 Expiry Mechanism

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Expiry_Mechanism

Current Draft

There SHALL be a mechanism to specify the validity period of the local networked services including contents delivered to the devices.

In HNReq

There does not seem to be any requirement for service expiry in HNReq. This is a requirement the Media APIs TF should focus on and develop accordingly.

Device Authentication Mechanism

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Device_Authentication_Mechanism

Current Draft

There SHALL be a mechanism to authenticate the device, the application and the subscriber for security purpose.

In HNReq

There appears to be no requirement exactly at this level, but there are several high-level requirements addressing similar concerns:

4.5.1 Application Trust Level

Conforming specifications should 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.

4.5.2 Access to Home Network Services

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

4.5.3 Prevent Leaking of Information: http://www.w3.org/TR/hnreq/#prevent-leaking-of-information

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

The group should determine whether these two requirement meet the same needs, or if both are complementary.

Local Access Control

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Local_Access_Control

Current Draft

There SHALL be a mechanism to authorize a subscriber to access the local networked services including contents that are appropriate to the subscriber’s profile, such as age, subscription status, etc.


Local Network Service Protection Mechanism

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Local_Network_Service_Protection_Mechanism

Current Draft

There SHALL be a mechanism to protect the local networked services including contents from unauthorized access.


Context-based and targeted Service Aggregation

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Context-based_and_targeted_Service_Aggregation

Current Draft

There SHALL be a mechanism to support the Context-based and targeted Service Aggregation and Content Delivery in order to provide subscriber with more suggested and relevant service and content. The context information includes but is not limited to:

  • Subscriber’s context such as profile information and related tradition and culture information, current timestamp / day / season, etc.
  • Device context, such as current geo-location / country / region, application and environment, OS and platform, etc.
  • Network context, such as bandwidth and other measurement etc.
  • Service context, such as provider’s profile, EPG information etc.
  • Content context, such as current content information, current background information, view history, etc.


Wake-up Mechanism

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Wake-up_Mechanism

Current Draft

There SHALL be a Wake-up mechanism for the local network services to push a notification to the device and wake up a proper application to serve the subscriber.


Service Information in Push Notifications

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Information_in_Push_Notifications

Current Draft

The Push notification in the Wake-up mechanism SHALL carry all necessary information related to services and contents so that the appropriate application will be able to present the subscriber with content services WITHOUT extra handshaking steps.


Offline Mode for Services and Content

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Offline_Mode_for_Services_and_Content

Current Draft

There SHALL be a mechanism for subscriber to save the suggested service and/or content for watching later.


Device-to-device content transfer

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Device-to-device_content_transfer

Current Draft: There SHALL be a mechanism for content to be transferred among the devices, and between the device and original sources of local networked services.


Payment Mechanism

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Payment_Mechanism

Current Draft

A standard Payment mechanism SHALL be supported for a subscriber to purchase additional services including contents.


Search

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Search

Current Draft

There SHALL be a mechanism to integrate search functions with the local networked services including contents.


Operating Modes

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Operating_Modes

Current Draft

Subscribers SHALL be allowed for different operating mode, such as DVR mode, Life Goes On mode, etc.


Tuner Control

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Tuner_Control

Current Draft

There SHALL be a mechanism for the application on set-top box to control TV’s tuner.


Channel Identification

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Channel_Identification

Current Draft

There SHALL be a mechanism to support channel identification.


Content Streaming

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Streaming

Current Draft

There SHALL be a mechanism to stream TV’s content to HTML player in set-top box.

In HNReq

There is a similar (but not exactly equivalent) requirement in HNReq.

4.3.4 Playback of Live Content

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


Content Download

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Download

Current Draft

There SHALL be a method of referencing video sources for download, e.g. using anchor elements with the download attribute.

Media Content Protection

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Media_Content_Protection

Current Draft

There SHALL be an ability to:

  • store video content in a protected format, as applicable.
  • store content licenses of protected video contents for offline playback.
  • view previously stored protected video content, e.g. via the HTML5 Encrypted Media Extensions.
  • transfer media in a single operation (not copy-then-delete).
  • account & verify the number of coexisting instances of the media.


In HNReq

There is a similar requirement in HNReq.

4.3.10 Content Protection

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

The draft requirement by the Media APIs TF is both more precise and covers additional cases. Notably, it adds a case where content protection would also work with offline playback.


Content Storage

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Storage

Current Draft

  • There SHALL be an adequately-sized storage medium; at least enough to store several full movies, e.g. 32GB
  • There SHALL be a method of accessing the storage medium to save videos, e.g.
  • There SHALL be a method of specifying the validity duration of the content in offline storage
  • There SHALL be a method of clearing the content in offline storage when its validity period has expired

In HNReq

None?

Content Playback

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Playback

Current Draft:

In HNReq

There are several relevant requirements in HNReq, notably:

4.3.3 Playback of Content

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


Content Recording while Watching

http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Content_Recording_while_Watching

Current Draft:

  • There SHALL be an ability to store video content accessed via the HTML5 video element, while the video is being presented in the browser.
Retrieved from "https://www.w3.org/2011/webtv/wiki/index.php?title=Media_APIs/HNReq_Comparison&oldid=2812"