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

[Philip Jägenstedt]

On Mon, 24 May 2010 08:14:47 +0200, Robert O'Callahan  
<robert at ocallahan.org> wrote:

> 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".

Oh, so the idea is that the earlier data might actually be seekable, it's  
just that the UA seeks to an offset, much like with media fragments? The  
exception might be live streaming, where the duration is +Inf anyway.

> 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

I don't think the current spec allows you to seek to before the "earliest  
possible position", pretty much by definition.

These are the cases I know of where an offset of some kind may be relevant:

* live streaming.

* server-applied media fragments where the offset of the fragment is given  
in a header of the resource.

For live streaming, I'm not sure the current spec has a problem, if  
browsers would implement the startTime property. For resources which  
themself claim an offset, I think we should let them start at 0 anyway and  
let people who really want a weird timeline fix it themselves.

-- 
Philip Jägenstedt
Core Developer
Opera Software