- From: poot <cvsmail@w3.org>
- Date: Tue, 03 Apr 2012 13:08:07 -0400
- To: public-html-diffs@w3.org
hixie: Add some notes clarifying this stuff about media timelines.
(whatwg r7047)
http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.5617&r2=1.5618&f=h
http://html5.org/tools/web-apps-tracker?from=7046&to=7047
===================================================================
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:10 UTC