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

[Robert O'Callahan]

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

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.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100524/51449e23/attachment-0002.htm>