MPTF

From Web and TV IG

Media Pipeline TF

The MPTF is a subset of the Web and TV Interest Group. The goal of MPTF is to discuss requirements placed on the HTML5 video, audio and media interfaces by media formats that will be used for Web and TV. The MPTF will also propose APIs that meet these requirements.

MODERATOR's NOTE: Having completed its primary objective of preparing requirements for adaptive bit-rate streaming and content protection in HTML, the MPTF is currently dormant. The email reflector will remain active for follow-up on LC bug resolutions and for discussions on relevant topics, but no regular meetings are scheduled. Thanks to the group for your diligent effort and the achievement of the MPTF objectives.

Dashboard

Current Topics

Adaptive Bit-Rate Control in Script (model 3)

  1. The <video> tag should be used to specify the video in HTML.
  2. A common time reference must be unambiguously defined for combining tracks with different time references and for "continuous" tracks. Overlapping track segments must also be handled. (DASH may provide a reasonable model.)
  3. Search and trick-play must be unambiguously defined in the context of this common time reference (e.g. anchor point and offset).
  4. The ability of the user agent to play a piece of content must be determined quickly and with reasonable accuracy (e.g. using CanPlayType(codec, level, profile) or other means)
  5. The ABR media system must not advantage one specific method over another.
  6. The ABR methods must work with "open source" browsers.
  7. ABR media must be useable in HTML5
  8. Any parameters required for use of the ABR system must be identified and specifiable.
  9. Specific errors relevant to ABR media must be identified and reportable.
  10. It should be possible to seamlessly splice content with a discontinuous timeline (such as advertising) into the presentation [this requirement may conflict with (2)?]
  11. (Others)

Content Protection

  • Description: Content must be protected from illegal use in support of agreements with content owners and distributors.
  • Status: WIP
  • Background (include this section in the requirements document as well):
  1. The Media Pipeline Task Force takes no position on the specifics of the legal agreements (referred to hereinafter collectively as "the agreement.") between users, content owners and content distibution service providers. The objective of the MPTF regarding content protection is to identify requirements for the technical tools to enable the terms of those agreements.
  2. The requirements below will not be perfect. There is no system that can absolutely guarantee the intended behavior in all cases. When perfection cannot be achieved, a reasonable solution (as agreed upon by the MPTF) should be adopted.
  1. Content protection methods must enable the rights of the user as specified in the agreement (See item 1 in Backgroud section above).
  2. Content protection methods must protect the rights of the content owners as specified in the agreement.
  3. Content protection methods must protect the rights of the distribution service provider as specified in the agreement.
  4. The content protection system must not advantage one specific container format over another.
  5. The content protection solution must support at least one mandatory method that can be used to enable interoperability between different systems.
    1. This method should be unencumbered with IPR
  6. Content protection methods must work with "open source" browsers. Specifically, the interface defined by the proposed solution should be implementable in any browser without requiring any privileged information. This scope of this requirement is limited to the interface defined in the proposed solution.
  7. Content protection must be useable in HTML5
  8. (consensus not yet reached) Content protection must be useable with specific HTML5 features such as media elements (and features (such as timed tracks) within these elements).
  9. (consensus not yet reached) Media element features that are available in an implementation must be available for encrypted content as well as unencrypted content.
  10. The particular content protection method required to use the content must be identifiable.
  11. Any parameters required for use of the content protection method must be identified and specifiable.
  12. Specific errors relevant to content protections must be identified and reportable.
  13. The content protection method must be compatible with the (new) media source element as described in the adaptive bit rate proposal.
  14. Others...
  • Proposals:
  • Issues:
    • Open issues:
      • My open issue
    • Closed issues:
      • My closed issue

Bugs

Resources

Charter

Requirements Document Draft

Open/Closed Issues: a page to upload or link your contribution to be discussed with other IG members.

Relevant Groups:

This is a list of groups/activities that may be related to the TF work. Note that this list doesn't imply any endorsement of the linked technologies or official liaison with the linked group.

Participants

Tools:

Parameter and Feedback Proposals

HTML Error Codes

Adaptive Bit Rate

Content Protection

Procedures

Proposal submission process

  1. Submitter writes a proposal on the Wiki using an appropriate* template following the instructions on the discussion page.
  2. Submitter creates an issue to keep track of his proposal. Remember to set Product to MEDIA_PIPELINE_TF.
  3. (The Track system will send an email to public-web-and-tv@w3.org to inform about the new issue and assign it an issue number like "ISSUE-NN")
  4. An Editor takes editing responsibilities for the issue. In general the Submitter will also be the Editor but there could be exceptions.
  5. (discussion happens, Tracker monitors the mailing-list and automatically links emails that contain "ISSUE-NN" to the issue in the Web interface. The proposal gets updated as necessary on the Wiki.)
  6. The Moderator issues a short call for consensus ("anything else on that topic?")
  7. The Moderator notes the outcome of the discussion in tracker and closes the issue.
  8. At this point The Use Case/Proposal can be merged in the main requirement document (or in a separate document, as needed)
Notes
  • If none of the templates available here fits your purposes, feel free to send the contribution anyway in the format you think is more appropriate. text/wiki based contribution are preferred

Templates

Please bear in mind that text should be used whenever possible (instead of email attachements) for indexation purposes.

Teleconference Calls