[whatwg] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)

[Robert O'Callahan]

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-0002.htm>