W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

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

From: Philip Jägenstedt <philipj@opera.com>
Date: Mon, 24 May 2010 13:01:02 +0200
Message-ID: <op.vc7h70n9sr6mfa@nog>
On Mon, 24 May 2010 12:33:56 +0200, Robert O'Callahan  
<robert at ocallahan.org> wrote:

> On Mon, May 24, 2010 at 10:13 PM, Philip J?genstedt  
> <philipj at opera.com>wrote:
>
>> Oh, so the idea is that the earlier data might actually be seekable,  
>> it's
>> just that the UA seeks to an offset, much like with media fragments? The
>> exception might be live streaming, where the duration is +Inf anyway.
>
>
> Yes.
>
> I don't think the current spec allows you to seek to before the "earliest
>> possible position", pretty much by definition.
>>
>> These are the cases I know of where an offset of some kind may be  
>> relevant:
>>
>> * live streaming.
>>
>> * server-applied media fragments where the offset of the fragment is  
>> given
>> in a header of the resource.
>>
>> For live streaming, I'm not sure the current spec has a problem, if
>> browsers would implement the startTime property.
>
>
> But you just said you want to get rid of startTime "regardless of  
> anything
> else"!
>
> For resources which themself claim an offset, I think we should let them
>> start at 0 anyway and let people who really want a weird timeline fix it
>> themselves.
>
>
> That means they basically won't work with most players, which won't be
> expecting to deal with negative seekable times or the "weird timeline".
>
> Rob

I think we both agree but aren't understanding each other very well, or  
I'm not thinking very clearly. People will write players assuming that  
currentTime starts at 0 and ends at duration. If this is not the case they  
will break, so an API which makes this not be the case in very few cases  
isn't very nice. That's the case now, where currentTime actually runs from  
startTime to startTime+duration (I think). Therefore, I want to get rid of  
startTime as it is now (regardless of anything else). I don't know if any  
current browser lets startTime be anything but 0.

Unless I'm missing some detail, that would mean that the current spec  
*does* have a problem even for live streaming, so I must take that back.  
To avoid confusion, it might be best to introduce a new attribute to solve  
the problem rather than re-use startTime.

-- 
Philip J?genstedt
Core Developer
Opera Software
Received on Monday, 24 May 2010 04:01:02 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC