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

[Philip Jägenstedt]

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

> On Tue, May 18, 2010 at 9:46 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com>wrote:
>
>> To be honest, it doesn't make much sense to display the "wrong" time
>> in a player. If a video stream starts at 10:30am and goes for 30 min,
>> then a person joining the stream 10 min in should see a time of 10min
>> - or better even 10:40am - which is in sync with what others see that
>> joined at the start. It would be rather confusing if the same position
>> in a video would be linked by one person as "at offset 10min" while
>> another would say "at offset 0min". And since the W3C Media Fragments
>> WG is defining temporal addressing, such diverging pointers will even
>> end up in a URL and how should that be interpreted then?
>>
>
> 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?

> -- media resources are allowed to have a "real time offset". This is an
> optional date+time (in UTC) that corresponds to currentTime=0, exposed  
> as a
> DOM attribute. Players would be encouraged to use this to display real
> times, when it's present.
>
> This would be similar in power to what the spec already has. In your  
> example
> you could either let currentTime=0 be the start of the stream that the
> user's loading, and use the "real time offset" to get the correct time
> displayed, or you could let 0 be the real "start", and set the initial
> playback time to match where the user joined. However, I think describing
> things the way I just did is simpler and avoids weirdness like the "start
> time" changing dynamically. It also preserves the invariant that  
> currentTime
> ranges from 0 to 'duration', which I think players will come to depend  
> on if
> the cases where it's not true are rare.
>
> Rob

What concretely should we change? Should we drop startTime, or redefine  
it? 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.

-- 
Philip Jägenstedt
Core Developer
Opera Software