[html5] r7047 - [e] (0) Add some notes clarifying this stuff about media timelines. Affected top [...]
whatwg at whatwg.org
whatwg at whatwg.org
Tue Apr 3 10:07:42 PDT 2012
Author: ianh
Date: 2012-04-03 10:07:40 -0700 (Tue, 03 Apr 2012)
New Revision: 7047
Modified:
complete.html
index
source
Log:
[e] (0) Add some notes clarifying this stuff about media timelines.
Affected topics: Video and Audio
Modified: complete.html
===================================================================
--- complete.html 2012-04-03 16:45:42 UTC (rev 7046)
+++ complete.html 2012-04-03 17:07:40 UTC (rev 7047)
@@ -29406,18 +29406,31 @@
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>
<p>Consider a stream from a TV broadcaster, which begins streaming
@@ -29435,14 +29448,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
Modified: index
===================================================================
--- index 2012-04-03 16:45:42 UTC (rev 7046)
+++ index 2012-04-03 17:07:40 UTC (rev 7047)
@@ -29406,18 +29406,31 @@
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>
<p>Consider a stream from a TV broadcaster, which begins streaming
@@ -29435,14 +29448,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
Modified: source
===================================================================
--- source 2012-04-03 16:45:42 UTC (rev 7046)
+++ source 2012-04-03 17:07:40 UTC (rev 7047)
@@ -31931,18 +31931,31 @@
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">
<p>Consider a stream from a TV broadcaster, which begins streaming
@@ -31961,14 +31974,15 @@
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
More information about the Commit-Watchers
mailing list