html5/spec Overview.html,1.5617,1.5618

Update of /sources/public/html5/spec
In directory hutz:/tmp/cvs-serv5474

Modified Files:
	Overview.html 
Log Message:
Add some notes clarifying this stuff about media timelines. (whatwg r7047)

Index: Overview.html
===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.5617
retrieving revision 1.5618
diff -u -d -r1.5617 -r1.5618
--- Overview.html	3 Apr 2012 16:46:01 -0000	1.5617
+++ Overview.html	3 Apr 2012 17:07:46 -0000	1.5618
@@ -27902,17 +27902,30 @@
   would not expose those times; it would instead expose the times as
   00:15..00:29 and 00:29..01:02, as a single video.</p>
 
-  <p>In the absence of an explicit timeline, the zero time on the
-  <a href="#media-timeline">media timeline</a> should correspond to the first frame of
-  the <a href="#media-resource">media resource</a>. For static audio and video files
-  this is generally trivial. For streaming resources that lack
-  explicit timelines, if the user agent will be able to seek to an
-  earlier point than the first frame originally provided by the
-  server, then the zero time should correspond to the earliest
-  seekable time of the <a href="#media-resource">media resource</a>; otherwise, it
-  should correspond to the first frame received from the server (the
-  point in the <a href="#media-resource">media resource</a> at which the user agent
-  began receiving the stream).</p>
+  <p>In the rare case of a <a href="#media-resource">media resource</a> that does not
+  have an explicit timeline, the zero time on the <a href="#media-timeline">media
+  timeline</a> should correspond to the first frame of the
+  <a href="#media-resource">media resource</a>. In the even rarer case of a <a href="#media-resource">media
+  resource</a> with no explicit timings ofd any kind, the user
+  agent must determine the time for each frame.</p>
+
+  <p class="note">An example of a file format with no explicit
+  timeline but with explicit timings is the Animated GIF format. An
+  example of a file format with no explicit timings at all is the
+  JPEG-push format (<code title="">multipart/x-mixed-replace</code>
+  with JPEG frames, often used as the format for MJPEG streams).</p>
+
+  <p>If, even in the absence of timing information, the user agent
+  will be able to seek to an earlier point than the first frame
+  originally provided by the server, then the zero time should
+  correspond to the earliest seekable time of the <a href="#media-resource">media
+  resource</a>; otherwise, it should correspond to the first frame
+  received from the server (the point in the <a href="#media-resource">media
+  resource</a> at which the user agent began receiving the
+  stream).</p>
+
+  <p class="note">At the time of writing, no format without an
+  explicit <a href="#media-timeline">media timeline</a> supported seeking.</p>
 
   <div class="example">
 
@@ -27931,14 +27944,14 @@
    fragments, broadcast by a server that does not allow user agents to
    request specific times but instead just streams the video data in a
    predetermined order, with the first frame delivered always being
-   identified as frame zero. If a user agent connects to this stream
-   and receives fragments defined as covering timestamps 2010-03-20
-   23:15:00 UTC to 2010-03-21 00:05:00 UTC and 2010-02-12 14:25:00 UTC
-   to 2010-02-12 14:35:00 UTC, it would expose this with a <a href="#media-timeline">media
-   timeline</a> starting at 0s and extending to 3,600s (one hour).
-   Assuming the streaming server disconnected at the end of the second
-   clip, the <code title="dom-media-duration"><a href="#dom-media-duration">duration</a></code>
-   attribute would then return 3,600. The <code title="dom-media-startDate"><a href="#dom-media-startdate">startDate</a></code> attribute would return
+   identified as the frame with time zero. If a user agent connects to
+   this stream and receives fragments defined as covering timestamps
+   2010-03-20 23:15:00 UTC to 2010-03-21 00:05:00 UTC and 2010-02-12
+   14:25:00 UTC to 2010-02-12 14:35:00 UTC, it would expose this with
+   a <a href="#media-timeline">media timeline</a> starting at 0s and extending to
+   3,600s (one hour). Assuming the streaming server disconnected at
+   the end of the second clip, the <code title="dom-media-duration"><a href="#dom-media-duration">duration</a></code> attribute would then
+   return 3,600. The <code title="dom-media-startDate"><a href="#dom-media-startdate">startDate</a></code> attribute would return
    a <code>Date</code> object with a time corresponding to 2010-03-20
    23:15:00 UTC. However, if a different user agent connected five
    minutes later, <em>it</em> would (presumably) receive fragments

Received on Tuesday, 3 April 2012 17:08:04 UTC