Media APIs/HNReq Comparison
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
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.
- For local filesystem storage, the File Writer API
- For browser-internal storage, the IndexedDB API
- 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:
- There SHALL be a method of accessing the storage medium for video playback, e.g.
- There SHALL be an ability to view previously stored video content, e.g. via
- The HTML5 video element using a reference to a locally-stored file, provided through the File API
- The HTML5 video element using a reference to a video stored in browser-internal storage, and accessed via the IndexedDB API
- There SHALL be an ability to view previously stored protected video content, e.g. via the HTML5 Encrypted Media Extensions
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.