[whatwg] Start position of media resources

[Ian Hickson]

On Thu, 30 Apr 2009, Robert O'Callahan wrote:
> > >
> > > 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.
> 
> Why should the "start time" change in this case? I assume you mean the 
> server is streaming video and does not support sending any data except 
> the data for the current time, and the UA is caching a window of data. 
> Then I would expect the element to expose a fixed start time (the time, 
> relative to the start of the resource, at which the UA first opened the 
> stream). As the stream plays, 'duration' would increase and the 
> 'seekable' and 'buffered' TimeRanges would change to reflect the data 
> the UA has in its buffer.

I mean, e.g., a TiVo-like interface, where the input is a TV tuner, or a 
streaming video service that doesn't let you seek but where the UA is 
buffering 15 minutes of content so that the user can seek within that. The 
way this is supported in the spec now, the start time (the "earliest 
possible position") continually changes, so that the UI doesn't show an 
increasingly long time frame, but instead only shows the last 30 minutes.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'