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

[Silvia Pfeiffer]

On Mon, May 24, 2010 at 11:03 AM, 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.
> -- 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.

Sounds like all the information would be there with this proposal.

Just to clarify: what time would a video display as it is playing back
in the browser?
The currentTime+realTimeOffset (if any), where currentTime would
include any initialPlaybackOffset?
If that can be realised, I believe that would provide the correct
perception to the user.

Cheers,
Silvia.