philipj at opera.com
Mon May 24 04:01:02 PDT 2010
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,
>> 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.
> 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
>> * live streaming.
>> * server-applied media fragments where the offset of the fragment is
>> 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
> 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
> 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".
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.
More information about the whatwg