- From: David Singer <singer@apple.com>
- Date: Thu, 30 Apr 2009 09:22:25 -0700
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 <ian at hixie.ch> 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.
Received on Thursday, 30 April 2009 09:22:25 UTC