On Thu, Apr 30, 2009 at 12:00 AM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Thu, 30 Apr 2009, Robert O'Callahan wrote:<br>
> > ><br>
</div><div class="im">> > > So I think a safer design would be to interpret currentTime as<br>
> > > relative to the startTime, perhaps renaming startTime to<br>
> > > 'timeOffset' instead?<br>
> ><br>
> > I considered that, but it seems that in the streaming video<br>
> > ("DVR-like") case, in the steady state where the data in the buffer is<br>
> > being thrown away at the same rate as the video is being played you'd<br>
> > end up in a weird position of the currentTime not changing despite the<br>
> > video playing, which would likely be even more confusing.<br>
><br>
> Why should the "start time" change in this case? I assume you mean the<br>
> server is streaming video and does not support sending any data except<br>
> the data for the current time, and the UA is caching a window of data.<br>
> Then I would expect the element to expose a fixed start time (the time,<br>
> relative to the start of the resource, at which the UA first opened the<br>
> stream). As the stream plays, 'duration' would increase and the<br>
> 'seekable' and 'buffered' TimeRanges would change to reflect the data<br>
> the UA has in its buffer.<br>
<br>
</div>I mean, e.g., a TiVo-like interface, where the input is a TV tuner, or a<br>
streaming video service that doesn't let you seek but where the UA is<br>
buffering 15 minutes of content so that the user can seek within that. The<br>
way this is supported in the spec now, the start time (the "earliest<br>
possible position") continually changes, so that the UI doesn't show an<br>
increasingly long time frame, but instead only shows the last 30 minutes.<br>
<div><div></div></div></blockquote><div><br>To me, "the earliest possible position" seems redundant with the 'seekable' TimeRanges. I think your use-case can be exposed perfectly adequately with an indefinite 'duration' and 'seekable' and 'buffered' TimeRanges changing over time (which will happen in many non-streaming cases too). There is no need to have 'startTime' changing; that seems an unnecessary complication. I think that dynamically changing the "time coordinate system" in which 'currentTime' is interpreted is a bad idea.<br>
<br>Rob </div></div>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>