At 6:21 +0000 30/04/09, Ian Hickson wrote:
On Thu, 30 Apr 2009, Robert O'Callahan wrote:
On Thu, Apr 30, 2009 at 1:04 PM, Ian Hickson <[email protected]> wrote:
>
> I have left the spec as is (except for adding startTime), which means
> that currentTime can be greater than duration if startTime is not
> zero.
I think it would be safer to have the invariant that 0 <= currentTime <=
duration. Most resources will probably have startTime==0 so authors will
write scripts expecting these invariants, and their scripts will break
when confronted with unusual resources with startTime>0.
So I think a safer design would be to interpret currentTime as relative
to the startTime, perhaps renaming startTime to 'timeOffset' instead?
I considered that, but it seems that in the streaming video ("DVR-like")
case, in the steady state where the data in the buffer is being thrown
away at the same rate as the video is being played you'd end up in a weird
position of the currentTime not changing despite the video playing, which
would likely be even more confusing.
If the resource is 'seekable' then time is relevant, and I agree that
time should be a normal play time and run from 0 to duration.
If it's not seekable (live), then the UA is free, of course, to
buffer and allow seeking in that buffer, but that's a UA thing.
Duration is indefinite, and the origin value of current time is also
so.
--
David Singer
Multimedia Standards, Apple Inc.
