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

[Silvia Pfeiffer]

On Mon, May 24, 2010 at 1: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:
>
>> 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?

The way I read that was that as a baseline measure, currentTime runs
from 0 to 'duration', but it is offset by initialPlaybackTime, if that
is available.


>> -- 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?

Again, the way I read that was that initialPlaybackTime is the same as
startTime. So, we would only need to add a realTimeOffset.

Cheers,
Silvia.