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

[Philip Jägenstedt]

On Mon, 24 May 2010 07:23:05 +0200, Robert O'Callahan  
<robert at ocallahan.org> wrote:

> On Mon, May 24, 2010 at 3:52 PM, Philip Jägenstedt  
> <philipj at opera.com>wrote:
>
>> On Mon, 24 May 2010 03:03:15 +0200, Robert O'Callahan <
>> robert at ocallahan.org> wrote:
>>
>>  Here's how I think it should work:
>>> -- currentTime (and related times, such as times in TimeRanges) range  
>>> from
>>> 0
>>> to 'duration'
>>> -- media resources are allowed to have a non-zero "initial playback  
>>> time".
>>> This is what currentTime should be set to on media load. We could  
>>> create a
>>> new DOM attribute to expose this.
>>>
>>
>> Is this a typo? If currentTime runes of 0 to duration, how can it begin  
>> at
>> something non-zero?
>
>
> Let me rephrase (English is such a bad language!):
> -- The valid values for currentTime (and related times) range from 0 to
> 'duration', inclusive.
> -- A media resource can specify an initial value for currentTime.
>
> What concretely should we change? Should we drop startTime, or redefine  
> it?
>
>
> We could redefine it but it might be less confusing to drop it and use
> another name for the initial value of currentTime. Currently startTime  
> means
> something quite different to that (as others have noted, it means  
> basically
> the first time in the 'seekable' TimeRanges, or currentTime if those  
> ranges
> are empty).
>
> So I would change:
> -- get rid of startTime and the concept of "earliest possible position",
> plus the related dispatching of timeupdate events

I support this, regardless of anything else.

> -- create a new readonly DOM attribute, say call it "initialTime" that
> returns the default initial playback position for the media resource
> -- during media resource loading, when metadata loads set the current
> playback position to initialTime
> -- note that currentTime is always between 0 and 'duration' (if duration  
> is
> known)

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.

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.

> Is it necessary to have the offset as an absolute date, or could that
>> probably odd case be handled in other ways? I can't really see a  
>> browser UI
>> making use of it, so I'd be happy to put it in a data-* attribute or  
>> using
>> microdata.
>>
>
> The "real time offset" is a property of the media resource (although I
> suppose we could have it settable via a content attribute as well) so it
> would need to be supported by the browser as an API on media elements.  
> The
> question is whether there's enough demand to justify it. I don't know how
> widely supported this data is in media resource formats; Ogg Skeleton
> supports it, but I don't know about others.

I don't have a strong opinion, but would want to see a use case for it.

-- 
Philip Jägenstedt
Core Developer
Opera Software