W3C home > Mailing lists > Public > public-html-diffs@w3.org > January 2011

hixie: Add best-practices sections for media elements. (whatwg r5751)

From: poot <cvsmail@w3.org>
Date: Tue, 11 Jan 2011 21:44:08 -0500
To: public-html-diffs@w3.org
Message-Id: <E1Pcqgx-0000G8-VY@jay.w3.org>
hixie: Add best-practices sections for media elements. (whatwg r5751)


RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.4611
retrieving revision 1.4612
diff -u -d -r1.4611 -r1.4612
--- Overview.html	7 Jan 2011 22:47:54 -0000	1.4611
+++ Overview.html	7 Jan 2011 23:30:39 -0000	1.4612
@@ -823,7 +823,9 @@
        <li><a href="#user-interface"><span class="secno"> </span>User interface</a></li>
        <li><a href="#time-ranges"><span class="secno"> </span>Time ranges</a></li>
        <li><a href="#mediaevents"><span class="secno"> </span>Event summary</a></li>
-       <li><a href="#security-and-privacy-considerations"><span class="secno"> </span>Security and privacy considerations</a></ol></li>
+       <li><a href="#security-and-privacy-considerations"><span class="secno"> </span>Security and privacy considerations</a></li>
+       <li><a href="#best-practices-for-authors-using-media-elements"><span class="secno"> </span>Best practices for authors using media elements</a></li>
+       <li><a href="#best-practices-for-implementors-of-media-elements"><span class="secno"> </span>Best practices for implementors of media elements</a></ol></li>
      <li><a href="#the-canvas-element"><span class="secno">4.8.11 </span>The <code>canvas</code> element</a>
        <li><a href="#color-spaces-and-color-correction"><span class="secno"> </span>Color spaces and color correction</a></li>
@@ -25681,6 +25683,68 @@
   being able to read the subtitles would present a confidentiality
+  </div><h5 id="best-practices-for-authors-using-media-elements"><span class="secno"> </span>Best practices for authors using media elements</h5><p><i>This section is non-normative.</i><p>Playing audio and video resources on small devices such as
+  set-top boxes or mobile phones is often constrained by limited
+  hardware resources in the device. For example, a device might only
+  support three simultaneous videos. For this reason, it is a good
+  practice to release resources held by <a href="#media-element" title="media
+  element">media elements</a> when they are done playing, either by
+  being very careful about removing all references to the element and
+  allowing it to be garbage collected, or, even better, by removing
+  the element's <code title="attr-media-src"><a href="#attr-media-src">src</a></code> attribute and
+  any <code><a href="#the-source-element">source</a></code> element descendants, and invoking the
+  element's <code title="dom-media-load"><a href="#dom-media-load">load()</a></code> method.<div class="impl">
+  <h5 id="best-practices-for-implementors-of-media-elements"><span class="secno"> </span>Best practices for implementors of media elements</h5>
+  <p><i>This section is non-normative.</i></p>
+  <p>How accurately various aspects of the <a href="#media-element">media element</a>
+  API are implemented is considered a quality-of-implementation issue.</p>
+  <p>For example, when implementing the <code title="attr-media-buffered">buffered</code> attribute, how precise
+  an implementation reports the ranges that have been buffered depends
+  on how carefully the user agent inspects the data. Since the API
+  reports ranges as times, but the data is obtained in byte streams, a
+  user agent receiving a variable-bit-rate stream might only be able
+  to determine precise times by actually decoding all of the data.
+  User agents aren't required to do this, however; they can instead
+  return estimates (e.g. based on the average bit rate seen so far)
+  which get revised as more information becomes available.</p>
+  <p>As a general rule, user agents are urged to be conservative
+  rather than optimistic. For example, it would be bad to report that
+  everything had been buffered when it had not.</p>
+  <p>Another quality-of-implementation issue would be playing a video
+  backwards when the codec is designed only for forward playback (e.g.
+  there aren't many key frames, and they are far apart, and the
+  intervening frames only have deltas from the previous frame). User
+  agents could do a poor job, e.g. only showing key frames; however,
+  better implementations would do more work and thus do a better job,
+  e.g. actually decoding parts of the video forwards, storing the
+  complete frames, and then playing the frames backwards.</p>
+  <p>Similarly, while implementations are allowed to drop buffered
+  data at any time (there is no requirement that a user agent keep all
+  the media data obtained for the lifetime of the media element), it
+  is again a quality of implementation issue: user agents with
+  sufficient resources to keep all the data around are encouraged to
+  do so, as this allows for a better user experience. For example, if
+  the user is watching a live stream, a user agent could allow the
+  user only to view the live video; however, a better user agent would
+  buffer everything and allow the user to seek through the earlier
+  material, pause it, play it forwards and backwards, etc.</p>
+  <hr><p>When a <a href="#media-element">media element</a> that is paused is <a href="#remove-an-element-from-a-document" title="remove an element from a document">removed from a
+  document</a> and not reinserted before the next time the
+  <a href="#event-loop">event loop</a> spins, implementations that are resource
+  constrained are encouraged to take that opportunity to release all
+  hardware resources (like video planes, networking resources, and
+  data buffers) used by the <a href="#media-element">media element</a>. (User agents
+  still have to keep track of the playback position and so forth,
+  though, in case playback is later restarted.)</p>
   </div><h4 id="the-canvas-element"><span class="secno">4.8.11 </span>The <dfn id="canvas"><code>canvas</code></dfn> element</h4><dl class="element"><dt>Categories</dt>
    <dd><a href="#flow-content">Flow content</a>.</dd>
    <dd><a href="#phrasing-content">Phrasing content</a>.</dd>
Received on Wednesday, 12 January 2011 02:44:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 January 2011 02:57:38 GMT