- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Mon, 24 May 2010 18:14:47 +1200
On Mon, May 24, 2010 at 5:54 PM, Philip J?genstedt <philipj at opera.com>wrote: > So from this I gather that either: > > 1. initialTime is always 0 > > or > > 2. duration is not the duration of resource, but the time at the end. > I wouldn't say that. If you can seek backwards to before the initial time, then clearly 'duration' really is still the duration, you just didn't start at the beginning. Same goes even if you can't seek backwards; e.g. "this live stream is an hour long and you have started 20 minutes into it". This seems to be what is already in the spec. Instead of guessing what > everyone means, here's what I'd want: > > 1. let currentTime always start at 0, regardless of what the timestamps or > other metadata of the media resource says. > > 2. let currentTime always end at duration. > > 3. expose an offset from 0 in startTime or a renamed attribute for cases > like live streaming so that the client can e.g. sync slides. > > The difference from what the spec says is that the concept of "earliest > possible position" is dropped. > I think the current spec allows you to seek backwards from the starting point. So would my proposal. Would yours? Would you allow 'seekable' to contain negative times? I think it's slightly simpler to allow currentTime to start at a non-zero position than to allow negative times and to support the offset in your point 3. I also think your point 3 would be slightly harder to spec. I'm not sure what you'd say. Rob -- "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] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100524/421c470c/attachment.htm>
Received on Sunday, 23 May 2010 23:14:47 UTC