html5/spec Overview.html,1.5615,1.5616

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

Modified Files:
	Overview.html 
Log Message:
Rename startOffsetTime to startDate and try to clarify its examples. (whatwg r7045)

Index: Overview.html
===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.5615
retrieving revision 1.5616
diff -u -d -r1.5615 -r1.5616
--- Overview.html	2 Apr 2012 21:15:15 -0000	1.5615
+++ Overview.html	3 Apr 2012 00:23:45 -0000	1.5616
@@ -26468,7 +26468,7 @@
            attribute double <a href="#dom-media-currenttime" title="dom-media-currentTime">currentTime</a>;
   readonly attribute double <a href="#dom-media-initialtime" title="dom-media-initialTime">initialTime</a>;
   readonly attribute double <a href="#dom-media-duration" title="dom-media-duration">duration</a>;
-  readonly attribute <span>Date</span> <a href="#dom-media-startoffsettime" title="dom-media-startOffsetTime">startOffsetTime</a>;
+  readonly attribute <span>Date</span> <a href="#dom-media-startdate" title="dom-media-startDate">startDate</a>;
   readonly attribute boolean <a href="#dom-media-paused" title="dom-media-paused">paused</a>;
            attribute double <a href="#dom-media-defaultplaybackrate" title="dom-media-defaultPlaybackRate">defaultPlaybackRate</a>;
            attribute double <a href="#dom-media-playbackrate" title="dom-media-playbackRate">playbackRate</a>;
@@ -27897,8 +27897,7 @@
   specifies an explicit start time <em>and date</em>, then that time
   and date should be considered the zero point in the <a href="#media-timeline">media
   timeline</a>; the <a href="#timeline-offset">timeline offset</a> will be the time
-  and date, exposed using the <code title="dom-media-startOffsetTime"><a href="#dom-media-startoffsettime">startOffsetTime</a></code>
-  attribute.</p>
+  and date, exposed using the <code title="dom-media-startDate"><a href="#dom-media-startdate">startDate</a></code> attribute.</p>
 
   <p>If the <a href="#media-resource">media resource</a> has a discontinuous timeline,
   the user agent must extend the timeline used at the start of the
@@ -27918,36 +27917,60 @@
   <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, 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>
+  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 class="example">Another example would be a stream that carries a
-  video with several concatenated 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. 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-startOffsetTime"><a href="#dom-media-startoffsettime">startOffsetTime</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 covering timestamps 2010-03-20 23:20: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,
-  and would expose this with a <a href="#media-timeline">media timeline</a> starting at
-  0s and extending to 3,300s (fifty five minutes). In this case, the
-  <code title="dom-media-startOffsetTime"><a href="#dom-media-startoffsettime">startOffsetTime</a></code>
-  attribute would return a <code>Date</code> object with a time
-  corresponding to 2010-03-20 23:20:00 UTC.</p>
+  <div class="example">
+
+   <p>Consider a stream from a TV broadcaster, which begins streaming
+   on a sunny Friday afternoon in October, and always sends connecting
+   user agents the media data on the same media timeline, with its
+   zero time set to the start of this stream. Months later, user
+   agents connecting to this stream will find that the first frame
+   they receive has a time with millions of seconds. The <code title="dom-media-startDate"><a href="#dom-media-startdate">startDate</a></code> attribute would always
+   return the date that the broadcast started; this would allow
+   controllers to display real times in their scrubber (e.g. "2:30pm")
+   rather than a time relative to when the broadcast began ("8 months,
+   4 hours, 12 minutes, and 23 seconds").</p>
+
+   <p>Consider a stream that carries a video with several concatenated
+   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
+   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
+   covering timestamps 2010-03-20 23:20: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, and
+   would expose this with a <a href="#media-timeline">media timeline</a> starting at 0s
+   and extending to 3,300s (fifty five minutes). In this case, 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:20:00 UTC.</p>
+
+   <p>In both of these examples, the <code title="dom-media-seekable"><a href="#dom-media-seekable">seekable</a></code> attribute would give the
+   ranges that the controller would want to actually display in its
+   UI; typically, if the servers don't support seeking to arbitrary
+   times, this would be the range of time from the moment the user
+   agent connected to the stream up to the latest frame that the user
+   agent has obtained; however, if the user agent starts discarding
+   earlier information, the actual range might be shorter.</p>
+
+  </div>
 
   <p>In any case, the user agent must ensure that the <a href="#earliest-possible-position">earliest
   possible position</a> (as defined below) using the established
@@ -28074,7 +28097,7 @@
   known as the <dfn id="timeline-offset">timeline offset</dfn>. Initially, the
   <a href="#timeline-offset">timeline offset</a> must be set to Not-a-Number (NaN).</p>
 
-  <p>The <dfn id="dom-media-startoffsettime" title="dom-media-startOffsetTime"><code>startOffsetTime</code></dfn>
+  <p>The <dfn id="dom-media-startdate" title="dom-media-startDate"><code>startDate</code></dfn>
   attribute must return <a href="#create-a-date-object" title="create a Date object">a new
   <code>Date</code> object</a> representing the current
   <a href="#timeline-offset">timeline offset</a>.</p>

Received on Tuesday, 3 April 2012 00:23:52 UTC