[e] (0) Add some notes clarifying this stuff about media timelines.

Affected topics: Video and Audio git-svn-id: http://svn.whatwg.org/webapps@7047 340c8d12-0b0e-0410-8428-c7bf67bfef74
whatwg · Apr 3, 2012 · 1a1fc1a · 1a1fc1a
1 parent c57159b
commit 1a1fc1a
Show file tree

Hide file tree

Showing 3 changed files with 97 additions and 57 deletions.
diff --git a/complete.html b/complete.html
@@ -29406,17 +29406,30 @@ <h5 id=offsets-into-the-media-resource><span class=secno>4.8.10.6 </span>Offsets
   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>
 
@@ -29435,14 +29448,14 @@ <h5 id=offsets-into-the-media-resource><span class=secno>4.8.10.6 </span>Offsets
    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

diff --git a/index b/index
@@ -29406,17 +29406,30 @@ interface <dfn id=htmlaudioelement>HTMLAudioElement</dfn> : <a href=#htmlmediael
   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>
 
@@ -29435,14 +29448,14 @@ interface <dfn id=htmlaudioelement>HTMLAudioElement</dfn> : <a href=#htmlmediael
    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

diff --git a/source b/source
@@ -31931,17 +31931,30 @@ interface <dfn>HTMLAudioElement</dfn> : <span>HTMLMediaElement</span> {};</pre>
   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
-  <span>media timeline</span> should correspond to the first frame of
-  the <span>media resource</span>. 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 <span>media resource</span>; otherwise, it
-  should correspond to the first frame received from the server (the
-  point in the <span>media resource</span> at which the user agent
-  began receiving the stream).</p>
+  <p>In the rare case of a <span>media resource</span> that does not
+  have an explicit timeline, the zero time on the <span>media
+  timeline</span> should correspond to the first frame of the
+  <span>media resource</span>. In the even rarer case of a <span>media
+  resource</span> 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 <span>media
+  resource</span>; otherwise, it should correspond to the first frame
+  received from the server (the point in the <span>media
+  resource</span> at which the user agent began receiving the
+  stream).</p>
+
+  <p class="note">At the time of writing, no format without an
+  explicit <span>media timeline</span> supported seeking.</p>
 
   <div class="example">
 
@@ -31961,14 +31974,15 @@ interface <dfn>HTMLAudioElement</dfn> : <span>HTMLMediaElement</span> {};</pre>
    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 <span>media
-   timeline</span> 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">duration</code>
-   attribute would then return 3,600. The <code
+   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 <span>media timeline</span> 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">duration</code> attribute would then
+   return 3,600. The <code
    title="dom-media-startDate">startDate</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