104
In any case, the user agent must ensure that theearliest possible positionp348
(as defined below) using the establishedmedia timelinep347
, is greater
than or equal to zero.
Themedia timelinep347
also has an associated clock. Which clock is used is user-agent defined, and may bemedia resourcep334
-dependent, but it
should approximate the user's wall clock.
Media elementsp333
have acurrent playback position, which must initially (i.e. in the absence ofmedia datap334
) be zero seconds. Thecurrent
playback positionp348
is a time on themedia timelinep347
.
Media elementsp333
also have anofficial playback position, which must initially be set to zero seconds. Theofficial playback positionp348
is an
approximation of thecurrent playback positionp348
that is kept stable while scripts are running.
Media elementsp333
also have adefault playback start position, which must initially be set to zero seconds. This time is used to allow the element
to be seeked even before the media is loaded.
Eachmedia elementp333
has ashow poster flag. When amedia elementp333
is created, this flag must be set to true. This flag is used to control
when the user agent is to show a poster frame for avideop325
element instead of showing the video contents.
ThecurrentTimeattribute must, on getting, return themedia elementp333
'sdefault playback start positionp348
, unless that is zero, in which case it
must return the element'sofficial playback positionp348
. The returned value must be expressed in seconds. On setting, if themedia elementp333
's
readyStatep351
isHAVE_NOTHINGp349
, then it must set themedia elementp333
'sdefault playback start positionp348
to the new value; otherwise, it
must set theofficial playback positionp348
to the new value and thenseekp358
to the new value. The new value must be interpreted as being in
seconds.
If themedia resourcep334
is a streaming resource, then the user agent might be unable to obtain certain parts of the resource after it has expired
from its buffer. Similarly, somemedia resourcesp334
might have amedia timelinep347
that doesn't start at zero. Theearliest possible positionis the
earliest position in the stream or resource that the user agent can ever obtain again. It is also a time on themedia timelinep347
.
When theearliest possible positionp348
changes, then: if thecurrent playback positionp348
is before theearliest possible positionp348
, the user agent
mustseekp358
to theearliest possible positionp348
; otherwise, if the user agent has not fired atimeupdatep384
event at the element in the past 15 to
250ms and is not still running event handlers for such an event, then the user agent mustqueue a taskp843
tofire a simple eventp854
named
timeupdatep384
at the element.
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. ThegetStartDate()p349
method 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").
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 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 amedia timelinep347
starting at 0s and extending to 3,600s (one hour). Assuming the streaming server disconnected at the end
of the second clip, thedurationp349
attribute would then return 3,600. ThegetStartDate()p349
method would return aDate
object
with a time corresponding to 2010-03-20 23:15:00 UTC. However, if a different user agent connected five minutes later,itwould
(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 amedia timelinep347
starting at 0s and extending to 3,300s (fifty five
minutes). In this case, thegetStartDate()p349
method would return aDate
object with a time corresponding to 2010-03-20 23:20:00
UTC.
In both of these examples, theseekablep358
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.
Theearliest possible positionp348
is not explicitly exposed in the API; it corresponds to the start time of the first range in theseekablep358
attribute'sTimeRangesp381
object, if any, or thecurrent playback positionp348
otherwise.
Note
Because of the above requirement and the requirement in theresource fetch algorithmp341
that kicks inwhen the metadata of the clip
becomes knownp344
, thecurrent playback positionp348
can never be less than theearliest possible positionp348
.
Note
348
