--- a/mpreq/MPTF-ADB-Requirements.html Tue Apr 24 15:15:22 2012 -0600
+++ b/mpreq/MPTF-ADB-Requirements.html Tue May 01 16:37:09 2012 -0600
@@ -111,36 +111,41 @@
<dl>
<dt><dfn>programme</dfn> (program)</dt>
<dd>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.</dd>
+
<dt><dfn>Adaptive Bit Rate</dfn></dt>
<dd>Adaptive bit rate media is characterized by short independent parallel media stream segments that can be individually selected and rendered according to some selective criteria. Typically, the parallel segments are differentiated by a feature such as required bandwidth, image resolution, etc.</dd>
+
<dt><dfn>Open Source</dfn></dt>
<dd>Open source software can be defined in many ways. For the purposes of these requirements it is defined as software that is openly developed and maintained by groups of interested developers. In these requirements, it is not required that open source software may only call other open source software. However, all open interfaces must be sufficiently defined that other open software may be developed to call those same interfaces.</dd>
+
<dt><dfn>Common Time Base</dfn></dt>
<dd>A common time base is a time reference that can be unambiguously interpreted for synchronization purposes.</dd>
+
<dt><dfn>Trick Play</dfn></dt>
<dd>Trick play refers to common media playback controls such as play, stop, pause, rewind and fast forward.</dd>
+
<dt><dfn>Media Track</dfn></dt>
<dd>Media tracks are individual streams of media that may optionally be combined into an aggregated track. For example a video track and one or more audio tracks are typically combined in a feature film. Other media tracks include closed captioning, alternate language tracks and special features.</dd>
<dt><dfn>Active IDs</dfn></dt>
<dd>The set of <a href="#source-id">source IDs</a> that are providing the <code><a href="http://dev.w3.org/html5/spec/media-elements.html#dom-videotrack-selected">selected video track</a></code> and the <code><a href="http://dev.w3.org/html5/spec/media-elements.html#dom-audiotrack-enabled">enabled audio tracks</a></code>.</dd>
- <dt id="source-id">Source ID</dt>
+ <dt><dfn>Source ID</dfn></dt>
<dd>An ID registered with <code><a href="#dom-sourceaddid">sourceAddId()</a></code> that identifies a distinct sequence of <a href="#init-segment">initialization segments</a> & <a href="#media-segment">media segments</a> appended to a specific <a href="#source-buffer">source buffer</a>.</dd>
- <dt id="source-buffer">Source Buffer</dt>
+ <dt><dfn>Source Buffer</dfn></dt>
<dd>A hypothetical buffer that contains the <a href="#media-segment">media segments</a> for a particular <a href="#source-id">source ID</a>. When <a href="#media-segment">media segments</a> are passed to <code><a href="#dom-sourceappend">sourceAppend()</a></code> they update the state of this buffer. The source buffer only allows a single <a href="#media-segment">media segment</a> to cover a specific point in the presentation timeline of each track. If a <a href="#media-segment">media segment</a> gets appended that contains media data overlapping (in presentation time) with media data from an existing segment, then the new media data will override the old media data. Since <a href="#media-segment">media segments</a> depend on <a href="#init-segment">initialization segments</a> the source buffer is also responsible for maintaining these associations. During playback, the media element pulls segment data out of the source buffers, demultiplexes it if necessary, and enqueues it into <a href="#track-buffer">track buffers</a> so it will get decoded and displayed. <code><a href="#dom-sourcebuffered">sourceBuffered()</a></code> describes the time ranges that are covered by <a href="#media-segment">media segments</a> in the source buffer.</dd>
- <dt id="track-buffer">Track Buffer</dt>
+ <dt><dfn>Track Buffer</dfn></dt>
<dd>A hypothetical buffer that represents initialization and media data for a single <code><a href="http://dev.w3.org/html5/spec/media-elements.html#audiotrack">AudioTrack</a></code> or <code><a href="http://dev.w3.org/html5/spec/media-elements.html#videotrack">VideoTrack</a></code> that has been queued for playback. This buffer may not exist in actual implementations, but it is intended to represent media data that will be decoded no matter what <a href="#media-segment">media segments</a> are appended to update the <a href="#source-buffer">source buffer</a>. This distinction is important when considering appends that happen close to the current playback position. Details about transfers between the <a href="#source-buffer">source buffer</a> and track buffers are given <a href="#source-buffer-to-track-buffer">here</a>.</dd>
- <dt id="init-segment">Initialization Segment</dt>
+ <dt><dfn>Initialization Segment</dfn></dt>
<dd>A sequence of bytes that contains all of the initialization information required to decode a sequence of <a href="#media-segment">media segments</a>. This includes codec initialization data, trackID mappings for multiplexed segments, and timestamp offsets (e.g. edit lists). A moov box in MPEG4 is as an initialization segment. For WebM, the concatenation of the the EBML Header, Segment Header, Info element, and Tracks element are used as an initialization segment.</dd>
- <dt id="media-segment">Media Segment</dt>
+ <dt><dfn>Media Segment</dfn></dt>
<dd>A sequence of bytes that contain packetized & timestamped media data for a portion of the presentation timeline. Media segments are always associated with the most recently appended <a href="#init-segment">initialization segment</a>. WebM cluster elements and MP4 movie fragment boxes are examples of media segments.</dd>
- <dt id="random-access-point">Random Access Point</dt>
+ <dt><dfn>Random Access Point</dfn></dt>
<dd>A position in a <a href="#media-segment">media segment</a> where decoding and continuous playback can begin without relying on any previous data in the segment. For video this tends to be the location of I-frames. In the case of audio, most audio frames can be treated as a random access point. Since video tracks tend to have a more sparse distribution of random access points, the location of these points are usually considered the random access points for multiplexed streams.</dd>
</dl>
@@ -155,52 +160,62 @@
<h3>General</h3>
<section>
- <h4>Compatibility with widely deployed standards</h4>
+ <h4>Standards Compatibility</h4>
+ <h5>Compatibility with widely deployed standards</h5>
<p>One of the primary purposes for standardizing the way the media elements use adaptive bitrate streaming is to enable different existing and future adaptive bitrate streming methods to work consistently with HTML5 media tags. Therefore, media tags must work with the widely deployed adaptive bitrate methods that are available now.</p>
</section>
<section>
- <h4>The <video> and <audio> tags should be used to specify video and audio in HTML. </h4>
+ <h4>Media Tags</h4>
+ <h5>The <video> and <audio> tags should be used to specify video and audio in HTML. </h5>
<p>In the past, the <obj> tag has been used to add non-standard functionality to HTML pages. In order to provide more consistent functionality, the <video> and <audio> elements were added to HTML. This allows for consistent handling of streaming media between different browsers and encoded with different codecs. In order to maintain this consistency, streaming media should be specified with streaming media tags rather than generic tags.</p>
</section>
<section>
- <h4>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.)</h4>
+ <h4>Common Time Reference</h4>
+ <h5>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.)</h5>
<p>Frequently, it is necessary to synchronize serveral different steaming content sources. For example, audio tracks must be synchronized with streaming video or the experience of watching the video becomes unpleasant. Synchronization is also important for advertising, closed caption and other streaming media features. Since different streaming media sources have different time references, a strategy for synchronizing these different references must be adopted.</p>
</section>
<section>
- <h4>It should be possible to seamlessly splice content with a discontinuous timeline (such as advertising) into the presentation.</h4>
+ <h4>Splicing</h4>
+ <h5>It should be possible to seamlessly splice content with a discontinuous timeline (such as advertising) into the presentation.</h5>
<p>In addition to a common time reference, mapping to that common time reference must be seamless enough to enable continuous playback from sources spliced relative to different time bases.</p>
</section>
<section>
- <h4>Search and trick-play must be unambiguously defined in the context of this common time reference (e.g. anchor point and offset).</h4>
+ <h4>Trick Play</h4>
+ <h5>Search and trick-play must be unambiguously defined in the context of this common time reference (e.g. anchor point and offset).</h5>
<p>A common time reference is also important in the context of trick play. Pausing, advancing or rewinding media content must be done accurately and within a common reference. This is necessary in order to advance or rewind to exact locations or the adjust the playback lockation by precise increments.</p>
</section>
<section>
- <h4>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)</h4>
+ <h4>Playability</h4>
+ <h5>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)</h5>
<p>With media content available from sources around the world, it is important to quickly determine whether various content sources can be rendered. Therefore this determinitaion must be madew with a minimum of overhead.</p>
</section>
<section>
- <h4>The ABR media system must not advantage one specific method over another.</h4>
+ <h4>No ABR Method Preference</h4>
+ <h5>The ABR media system must not advantage one specific method over another.</h5>
<p>HTML aspires to be a level playing field. This philosophy enables innovation to flourish and allows superior solutions to become quickly implemnted and adopted. ABR media systems are and should continue to be innovative solutions within this spirit of openness.</p>
</section>
<section>
- <h4>The ABR methods must work with "open source" browsers.</h4>
+ <h4>Open Source Browsers</h4>
+ <h5>The ABR methods must work with "open source" browsers.</h5>
<p>The ability for a browser vendor to implement playback of ABR media must not be restricted by the requirements of this document.</p>
</section>
<section>
- <h4>Any parameters required for use of the ABR system must be identified and specifiable.</h4>
+ <h4>Common Parameters</h4>
+ <h5>Any parameters required for use of the ABR system must be identified and specifiable.</h5>
<p>While specific implementations may include vendor-specific parameters for special features, the parameters required for basic playback should be publicly specified.</p>
</section>
<section>
- <h4>Specific errors relevant to ABR media must be identified and reportable.</h4>
+ <h4>Common Errors</h4>
+ <h5>Specific errors relevant to ABR media must be identified and reportable.</h5>
<p>While specific implementations may include vendor-specific error codes, the error codes required for basic operation and diagnosis should be publicly specified.</p>
</section>
@@ -214,19 +229,418 @@
<section>
<h2>Use Cases</h2>
- <p>Paragraph...</p>
+ <p>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:</p>
+
+ <dl>
+ <dt>Ux. <TITLE></dt>
+ <dd>Use case title</dd>
+
+ <dt>Description</dt>
+ <dd><ul>
+ <li>High level description/overview of the goals of the use case</li>
+ <li>Schematic illustration (devices involved, work flows, etc.) (Optional)</li>
+ </ul></dd>
+
+ <dt>Motivation</dt>
+ <dd><ul>
+ <li>Explanation of the benefit to the ecosystem</li>
+ <li>Why existing standards cannot be used to accomplish this use case</li>
+ </ul></dd>
+
+ <dt>Dependencies</dt>
+ <dd>Other use cases, proposals or other ongoing standardization activities which this use case is dependent on or related to.</dd>
+
+ <dt>Requirements</dt>
+ <dd>List of requirements implied by this Use Case.</dd>
+ </dl>
+
+ <section>
+ <h3>U1. Play Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can play adaptive bit rate content identified in media tags regardless of the particular adaptive bit rate method used to format the content. Support for the playable content formats must be provided by the browser or extensible features of the browser.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item for playback.</li>
+ <li>The content plays.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface for adaptive bit rate content content. This leads to the implementation of multiple incompatible playback systems and interfaces. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the playback of adaptive bit rate content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>In order to play adaptive bit rate content, the application interface must be provided.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U2. Trick Mode with Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can use trick-play modes (pause, rewind, fast-forward) with adaptive bit rate content regardless of the particular adaptive bit rate method used to format the content.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item for playback.</li>
+ <li>The user clicks a trick-play button (pause, rewind, fast-forward) in the user interface.
+ <li>The playback of the content is changed according to the trick-play feature selected.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>Playback of media should be consistent regardless of the particular format of the content. Trick-play modes available to non-adaptive media formats should also be available to adaptive bit rate media. What should be standardized is:</p>
+ <ul>
+ <li>trick-play modes should work consistently across all streaming media formats.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for trick-play modes</td>
+ <td><a href="#trick-play" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U3. Search Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can search adaptive bit rate content identified in media tags to position playback at a specific point in time regardless of the particular adaptive bit rate method used to format the content.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item for playback.</li>
+ <li>The user selects a particular point in time in the playback of the video (e.g. 30 seconds ahead, 75% through the video, etc.).</li>
+ <li>The playback pointer is positioned at the specified location in time.</li>
+ <li>The content plays beginning at the new position.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>Playback of media should be consistent regardless of the particular format of the content. Search modes available to non-adaptive media formats should also be available to adaptive bit rate media. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify searching of adaptive bit rate content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U4. Merge, Splice and Append Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user merge, splice and append adaptive bit rate content identified in media tags regardless of the particular adaptive bit rate method used to format the content.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects two content items and identifies a location in time where they are to be merged (both items continue playing at the merge point), spliced (one item stops playing and the other item continues) or appended (one item plays to its end, then the other item plays from its beginning).</li>
+ <li>The content plays as specified.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface for merging, splicing content. Content can typically be appended by queueing up the next segment, but there is no guarantee that the common time reference will be preserved. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the means to merge, splice and append adaptive bit rate content;</li>
+ <li>a specification on how to preserve a common time base when merging, splicing or appending adaptive bit rate content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U5. Continuous Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can play a continuous stream of adaptive bit rate content identified in media tags regardless of the particular adaptive bit rate method used to format the content. Continuous content could be a stream that is continuously encoded from a live source (e.g. it has no specific finite length) or a play list that is continually getting content appended and has a common time base.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a "channel" for playback.</li>
+ <li>The channel plays continuously until the user selects a different source.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface for continuous playback adaptive bit rate content. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the playback of continuous adaptive bit rate content;</li>
+ <li>a specification for maintaining a common time base for continuous content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ <section>
+ <h3>U6. Timed Tracks and Adaptive Bit Rate Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user can add timed tracks adaptive bit rate content at specific points in time regardless of the particular adaptive bit rate method used to format the content.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item, timed text track to be merged and a specific location in time.</li>
+ <li>The content item and timed text track are merged as specified.</li>
+ <li>The merged content plays.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface for merging timed text tracks with adaptive bit rate content. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the merging of timed text tracks with adaptive bit rate content.</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>None.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Compatibility with existing standards</td>
+ <td><a href="#standards-compatibility" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for media tags</td>
+ <td><a href="#media-tags" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for a common time reference</td>
+ <td><a href="#common-time-reference" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Support for particular ABR media type</td>
+ <td><a href="#playability" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the ABR parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
+ </section>
</section>
<section>
<h2>Security</h2>
+ <p>In the context of adaptive bit rate media, security is primarily concerned with esuring that authorized users are able to play the media and unauthorized users are not. This may involve verifying that the content has been legally obtained. It may also mean that personally produced video is only viewable by friends and family. If viewing is intended to be restricted, a content protection system must be in place. Adaptive bit rate video should be treated the same as any video element in this regard. A content protection system for media elements has been proposed to the W3C HTML WG and is being reviewed. (Put reference here)</p>
+ </section>
+
+ <section>
+ <h2>Identified Gaps</h2>
+
+ <section>
+ <h3>Buffer Management</h3>
+ </section>
+
+ <section>
+ <h3>Capability Detection</h3>
+ </section>
+
+ <section>
+ <h3>Append URL</h3>
<p>Paragraph...</p>
+ </section>
</section>
<section>
<h2>Next Steps</h2>
- <p>Paragraph...</p>
+ <ul>
+ <li>Make any necessary changes or refinements in this document</li>
+ <li>Submit this document to appropriat W3C WC for development of specification.</li>
+ </ul>
</section>
<section>
--- a/mpreq/MPTF-CP-Requirements.html Tue Apr 24 15:15:22 2012 -0600
+++ b/mpreq/MPTF-CP-Requirements.html Tue May 01 16:37:09 2012 -0600
@@ -122,69 +122,69 @@
<section>
<h3>General</h3>
<section>
- <h4>Content protection methods must enable the rights of the user as specified in the agreement (See item 1 in Backgroud section above).</h4>
- <p>Description...</p>
- </section>
-
- <section>
- <h4>Content protection methods must protect the rights of the content owners as specified in the agreement.</h4>
- <p>Description...</p>
+ <h4>User Rights</h4>
+ <p>Content protection methods must enable the rights of the user as specified in the agreement (See item 1 in Backgroud section above).</p>
</section>
<section>
- <h4>Content protection methods must protect the rights of the distribution service provider as specified in the agreement.</h4>
- <p>Description...</p>
+ <h4>Owner Rights</h4>
+ <p>Content protection methods must protect the rights of the content owners as specified in the agreement.</p>
</section>
<section>
- <h4>The content protection system must not advantage one specific container format over another.</h4>
- <p>Description...</p>
+ <h4>Distributor Rights</h4>
+ <p>Content protection methods must protect the rights of the distribution service provider as specified in the agreement.</p>
</section>
<section>
- <h4>The content protection solution must support at least one mandatory method that can be used to enable interoperability between different systems.</h4>
- <p>Description...</p>
+ <h4>Container Format</h4>
+ <p>The content protection system must not advantage one specific container format over another.</p>
+ </section>
+
+ <section>
+ <h4>Mandatory Baseline</h4>
+ <p>The content protection solution must support at least one mandatory method that can be used to enable interoperability between different systems.</p>
<h5>This method should be unencumbered with IPR</h5>
</section>
<section>
- <h5>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.</h5>
- <p>Description...</p>
- </section>
-
- <section>
- <h4>Content protection must be useable in HTML5</h4>
- <p>Description...</p>
- </section>
-
- <section>
- <h4>(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).</h4>
- <p>Description...</p>
+ <h4>Browser Independence</h4>
+ <p>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.</p>
</section>
<section>
- <h4>(consensus not yet reached) Media element features that are available in an implementation must be available for encrypted content as well as unencrypted content.</h4>
- <p>Description...</p>
- </section>
-
- <section>
- <h4>The particular content protection method required to use the content must be identifiable.</h4>
- <p>Description...</p>
+ <h4>HTML5 Compatibility</h4>
+ <p>Content protection must be useable in HTML5</p>
</section>
<section>
- <h4>Any parameters required for use of the content protection method must be identified and specifiable.</h4>
- <p>Description...</p>
+ <h4>Media Elements</h4>
+ <p>(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).</p>
</section>
<section>
- <h4>Specific errors relevant to content protections must be identified and reportable.</h4>
- <p>Description...</p>
+ <h4>Encrypted Content</h4>
+ <p>(consensus not yet reached) Media element features that are available in an implementation must be available for encrypted content as well as unencrypted content.</p>
</section>
<section>
- <h4>The content protection method must be compatible with the (new) media source element as described in the adaptive bit rate proposal.</h4>
- <p>Description...</p>
+ <h4>Identifiable Content Protection Method</h4>
+ <p>The particular content protection method required to use the content must be identifiable.</p>
+ </section>
+
+ <section>
+ <h4>Common Parameters</h4>
+ <p>Any parameters required for use of the content protection method must be identified and specifiable.</p>
+ </section>
+
+ <section>
+ <h4>Common Errors</h4>
+ <p>Specific errors relevant to content protections must be identified and reportable.</p>
+ </section>
+
+ <section>
+ <h4>Adaptive Bit Rate Media</h4>
+ <p>The content protection method must be compatible with the (new) media source element as described in the adaptive bit rate proposal.</p>
</section>
<section>
@@ -199,7 +199,85 @@
<section>
<h2>Use Cases</h2>
- <p>Paragraph...</p>
+
+ <p>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:</p>
+
+ <dl>
+ <dt>Ux. <TITLE></dt>
+ <dd>Use case title</dd>
+
+ <dt>Description</dt>
+ <dd><ul>
+ <li>High level description/overview of the goals of the use case</li>
+ <li>Schematic illustration (devices involved, work flows, etc.) (Optional)</li>
+ </ul></dd>
+
+ <dt>Motivation</dt>
+ <dd><ul>
+ <li>Explanation of the benefit to the ecosystem</li>
+ <li>Why existing standards cannot be used to accomplish this use case</li>
+ </ul></dd>
+
+ <dt>Dependencies</dt>
+ <dd>Other use cases, proposals or other ongoing standardization activities which this use case is dependent on or related to.</dd>
+
+ <dt>Requirements</dt>
+ <dd>List of requirements implied by this Use Case.</dd>
+ </dl>
+
+ <section>
+ <h3>U1. Support Authorized User Access to Content</h3>
+
+ <dl>
+ <dt>Description</dt>
+ <dd>
+ <p>A user who has legitimate rights to content can access the content according to the terms of the agreements with the content owner and distribution partner.</p>
+
+ <p>Possible implementation:</p>
+ <ul>
+ <li>The user selects a content item for playback.</li>
+ <li>The user's rights to play the content are automatically verified.</li>
+ <li>The content plays.</li>
+ </ul>
+ </dd>
+
+ <dt>Motivation</dt>
+ <dd>
+ <p>There is no standard interface to verify a user's right to access premium content. This leads to the implementation of multiple incompatible rights authorization systems and interfaces. What should be standardized is:</p>
+ <ul>
+ <li>an interface to specify the content protection system;</li>
+ <li>an interface to allow any content protection system to be used to protect content;</li>
+ <li>an interface to allow a user to gain legitimate access to content;</li>
+ </ul>
+ </dd>
+
+ <dt>Dependencies</dt>
+ <dd>
+ <p>In order to obtain access to protected content, the content protection system must be identified and proper credentials need to be provided.</p>
+ </dd>
+
+ <dt>Requirements</dt>
+ <dd><table>
+ <tr>
+ <th>Low Level</th>
+ <th>High Level</th>
+ </tr>
+ <tr>
+ <td>Enable the rights of the user</td>
+ <td><a href="#user-rights" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Identify the content protection method</td>
+ <td><a href="#identifiable-content-protection-method" class="sectionRef"></a></td>
+ </tr>
+ <tr>
+ <td>Specify the content protection parameters</td>
+ <td><a href="#common-parameters" class="sectionRef"></a></td>
+ </tr>
+ </table></dd>
+ </dl>
+ </section>
+
</section>
<section>