MPTF/MPTF Requirements

From Web and TV IG

Requirement Document Draft

(ONLY THE EDITOR SHOULD CHANGE THIS DOCUMENT)

This section contain the draft for a requirement document as discussion by Media Pipeline 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

Status of This Document

This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.

Introduction

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.

Definitions

Design Goals

  • Compatibility with widely deployed standards
  • Security

A conforming specification needs to address the security concerns of end-users, authors, distributors and device manufacturers by recommending appropriate security policies and programming behavior. A conforming specification must also consider the distribution and deployment security requirements as they relate to authors and vendors.

  • Wider community benefit

Any new technologies or processes defined by a conforming specification needs to designed in such a way that they are beneficial the wider Web community at large. In other words, conforming specifications should try not to be insular to their problem domain, but should also consider the needs of the wider Web community.

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 below

Note
This section will include all approved test cases discussed here

UX. <TITLE>

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 dependant on or related to

What needs to be standardized:

  • What are the new requirements, i.e. functions that don't exist, generated by this use case?

Requirements

This section enumerates the requirements that conforming specification(s) would need to address to enable the delivery of commercial streaming media services over IP-based networks. 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 Media Pipeline Task Force of the Web & TV IG

Delivery of Television Services

The Media Pipeline should support existing and imminent television services that may be required by government regulation or expected by consumers. These services include insertion of advertising content, synchronization of events with a media stream, content advisory messages, supplementary audio programming, audio descriptions, closed captions and subtitles. The specific requirements are listed below. Some of the requirements can be met with existing W3C features. Where there is no existing solution, this fact is noted.

R1. Combined Main + Description Audio Track

Playing descriptive audio tracks, which come in two forms:

  • Description pre-mixed with main audio (e.g. USA, Canada)
  • Description not mixed with main audio (e.g. Europe)
What doesn't work

HTML5 specification only supports non-premixed description tracks.

Submitted bugs:
  • LC1 Bug 13357 - <track>: Additional AudioTrack.kind categories are needed to identify tracks where audio descriptions are premixed with main dialogue.
Section: 4.8.10.10.1 AudioTrackList and VideoTrackList objects
  • Table “Return values for AudioTrack.kind() and VideoTrack.kind()” defines seven Category values: "alternative”, "description”, "main”, "sign”, "translation”, "commentary”, "" (empty string).
  • Pre-mixed audio descriptions mix both "description” and ”main”, which cannot be specified.
Suggested changes:
  • Define two new Category values:
    • "main+description" - pre-mixed main audio track and audio descriptions
    • "translation+description" - pre-mixed translated audio track and audio descriptions
  • Make Category a list, allowing other combinations (e.g. video with main and sign)

Relevant Use Cases Include: Client Ad Insertion (Issue-31), Media Synchronous Web Content (Issue-32), TV Services Transport Mapping (Issue-39), Time Synchronization (Issue-45)

R2. Key Metadata Types

An ability to distinguish specific types of metadata should be added so that key metadata types can be handled appropriately by a User Agent.

What doesn't work

No gaps identified. The UA should already know about metadata it can process.

Relevant Use Cases Include: Client Ad Insertion (Issue-31), Media Synchronous Web Content (Issue-32), TV Services Transport Mapping (Issue-39)

R3. Handling of In-band Tracks

Playing in-band multiplexed media streams (e.g. broadcast television, live events and recorded movies) with track elements that come and go over time (e.g. secondary audio, subtitles in different languages, application signaling and content ratings.)

What doesn’t work:

Application doesn’t know type of data tracks or when tracks end.

Submitted bugs:
  • (accepted) LC1 Bug 13358 - <video> also fire a 'change' event at VideoTrackList, AudioTrackList, and TextTrackList objects when their list of tracks changes.
  • LC1 Bug 13359 - A way is needed to identify the type of data in a track element
  • LC1 Bug 14492 - <video> change event when tracks are removed (merge with LC1 Bug 13358?)
Section: 4.8.10.12.2 Sourcing in-band text tracks

References “relevant specifications” for setting in-band text track values. CableLabs has developed one of these specs for MPEG-2 TS. More will be needed for relevant media container formats. Should we publish these in W3C?

Suggested changes:
  • Mapping of in-band tracks needs to be done in a standard way within each transport: should W3C publish mapping specs?
  • The transport “directory” info(e.g. PMT) can be mapped as text track using current spec. Would be better as a track type.
  • Deletion of track causes some notification.

Relevant Use Cases Include: Client Ad Insertion (Issue-31), Media Synchronous Web Content (Issue-32), Timed Text (Issue-33), TV Services Transport Mapping (Issue-39), Time Synchronization (Issue-45)

R4. Content Authorization Parameters

A method for securely informing web content of a media item's content rating or other authorization parameters should be developed. This should be delivered when the media is loaded and whenever the authorization parameters change.

What doesn't work

No gaps identified. Content advisories are covered by LC1 Bug 13359 and the mapping specification. Everything else is handled by the application.

Relevant Use Cases Include: Parental Controls (Issue-36), TV Services Transport Mapping (Issue-39), Content Protection (Issue-40)

R5. Content Authorization Failure

A method for securely informing web content that a media item could not be played due to an authorization failure and the reason for the authorization failure.

What doesn't work

No gaps identified. Covered by requirement 11.

Relevant Use Cases Include: Parental Controls (Issue-36), TV Services Transport Mapping (Issue-39), Content Protection (Issue-40)

Adaptive Streaming of Media Content

The effective delivery of media content over an unreliable network such as the Internet is facilitated by the use of technologies such as adaptive bit rate streaming. Standardized support for adaptive streaming requires the following.

R6. Adaptive Bit Rate Format Support

The media element interface should support the specification of adaptive bit rate streaming formats (e.g. DASH .mpd or other manifest file formats).

What doesn't work

No gaps identified.

Relevant Use Cases Include: Adaptive Bit Rate Delivery (Issue-34),

R7. Additional Media Parameters

Playing adaptive rate video via video element. Currently deployed object element adaptive rate video players allow application control of adaptive play-out. Common parameters for other media should also be considered.

What doesn’t work:

HTML5 spec has no APIs to control adaptive video.

Submitted bugs:
  • Issue-179 (LC1 Bug 13333): {audio,video} require param child (or equivalent)
  • LC1 Bug 13625 - There is no way to pass audio and video content metadata to the user agent that is required in some cases for playback.
Section: 4.8.10 Media elements

Interface HTMLMediaElement : HTMLElement.

Suggested changes:
  • Expose information, such as the available bit rates and set a maximum used by the user agent
  • Expose and set parameters of an adaptive bit-rate fragment selection algorithm
  • Ability to signal and play media spliced seamlessly onto end of current video.

Relevant Use Cases Include: Adaptive Bit Rate Delivery (Issue-34)

R8. Additional Media Feedback and Errors

The media element interface should support the feedback of relevant adaptive bit rate, or other media information (e.g. delivery statistics, events, and errors).

What doesn’t work:

The HTML5 specification lacks error messages and events specific to adaptive bit rate video or other media specific support.

Submitted bugs:
Section: 4.8.10.1 Error codes
  • MEDIA_ERR_ABORTED
  • MEDIA_ERR_NETWORK
  • MEDIA_ERR_DECODE
  • MEDIA_ERR_SRC_NOT_SUPPORTED
Suggested changes:
  • Add error codes common to media errors, and additional events or information, e.g.
    • DNS failures, TCP failures, TLS failures
    • Delivery statistics (packet drop rate, etc.)
    • Change in rendered stream event

Relevant Use Cases Include: Adaptive Bit Rate Delivery (Issue-34)

Content Security and Digital Rights Management

The delivery of premium media over an unsecured network such as the Internet requires the protection of proprietary and copyrighted content. Standardized support for content protection requires the following.

R9. Security and Digital Rights Management Identification

The media element interface should support the specification of content protection and digital rights management formats (e.g. DECE Ultraviolet, DTCP-IP, etc.).

What doesn't work

No gaps identified.

Relevant Use Cases Include: Content Protection (Issue-40),

R10. Content Protection Parameters

The media element interface should support secure specification of content protection and digital rights management parameters (e.g. subscription requirements, etc.).

What doesn’t work:

HTML5 spec has no APIs to control content protection.

Submitted bugs:
  • Issue-179 (LC1 Bug 13333): {audio,video} require param child (or equivalent)
  • LC1 Bug 13625 - There is no way to pass audio and video content metadata to the user agent that is required in some cases for playback.
Section: 4.8.10 Media elements

Interface HTMLMediaElement : HTMLElement.

Suggested changes:
  • Retrieve DRM system information like DRM system is ready, it is initializing, error, etc.
  • Exchange DRM related messages with the underlying DRM system.
  • Result on exchange of DRM related messages if exchange is successful or an error occured. Errors may include user consent is required, unknown DRM sytem id for incoming content, wrong format, etc.
  • [This example is taken from OIPF DAE specification. Refer to Section 7.6 on Content Service Protection]

Relevant Use Cases Include: Content Protection (Issue-40)

R11. Content Protection Feedback and Errors

The media element interface should support the feedback of relevant content protection and digital rights management information (e.g. supported DRMs, DRM ready, need to reactivate license, etc.).

What doesn’t work:

The HTML5 specification lacks error messages and events specific to content protection support.

Submitted bugs:
Section: 4.8.10.1 Error codes
  • MEDIA_ERR_ABORTED
  • MEDIA_ERR_NETWORK
  • MEDIA_ERR_DECODE
  • MEDIA_ERR_SRC_NOT_SUPPORTED
Suggested changes:
  • Receive errors from DRM system with additional information like DRM rights URL for retrieval of keys. Errors may include: No license, Invalid license, Valid license
  • [This example is taken from OIPF DAE specification. Refer to Section 7.13.6 on Extension to video/broadcast for DRM rights errors]

Relevant Use Cases Include: Content Protection (Issue-40)

Other

No other requirements identified.

References

Retrieved from "https://www.w3.org/2011/webtv/wiki/index.php?title=MPTF/MPTF_Requirements&oldid=1638"