W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2012

[whatwg] [media] startOffsetTime, also add startTime?

From: Rick Waldron <waldron.rick@gmail.com>
Date: Wed, 7 Mar 2012 10:04:33 -0500
Message-ID: <CAHfnhfrGsDbWBQq4ijLatLky3AZWRYEYGU8+wu7TDEG6qwfmUQ@mail.gmail.com>
Thanks for putting this together Odin -- this has long been a point of
interest for all of us on the Popcorn.js dev team.

Rick

On Wed, Mar 7, 2012 at 5:56 AM, Odin H?rthe Omdal <odinho at opera.com> wrote:

> startOffsetTime seem to leave people confused, I often have to explain it,
> and yesterday I read the spec[5] and old emails and got confused myself. It
> hasn't been implemented after almost 2 years.
>
>
> Having the UTC time of the clip you're getting would be very useful. But
> it'd be really nice to get the start of the non-normalized timestamp
> exposed to javascript for synchronizing out-of-band metadata with the live
> streamed media.
>
> Browsers are currently supposed to take the timestamp and normalize it to
> 0 for currentTime. Chromium currently does not do that; it starts at 3:15,
> if I join a streamed video that I started streaming 3 minutes, 15 seconds
> ago.
>
> I don't think using the UTC time as the sync point is very stable at the
> moment. It'd be a much quicker, stable, and easier win to get a startTime,
> timelineStartTime or timeSinceStart or similar that exposes the
> NON-normalized timestamp value at the start of the stream. So that, if you
> do
>
>   startTime + currentTime
>
> you're able to get the actual timestamp that the stream is at, at that
> point. And in contrast with startOffsetTime this one won't ever change, so
> startTime + currentTime will always be continuously increasing.
>
>
>
> The Date UTC which startOffsetTime would use, seems to be varying quite a
> bit. You need to know your streaming server and what it does in order to
> understand the result. Even different media from the same server might give
> different results if the streaming server implementation just reads the UTC
> time directly from the file. The information could be useful, but for more
> advanced uses.
>
>
> startOffsetTime and initialTime came out of this conversation in 2010:
>  <http://lists.whatwg.org/**htdig.cgi/whatwg-whatwg.org/**
> 2010-May/thread.html#26342<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/thread.html#26342>
> >
>
> And introduced here:
>  <http://lists.whatwg.org/**htdig.cgi/whatwg-whatwg.org/**
> 2010-August/028004.html<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028004.html>
> >
>
>
> Sean O'Halpin of BBC recently mentioned[2] some of the confusion:
>
>  There seems to be some confusion here in how the HTML5 media elements
>> specification is dealing with logical stream addressing versus physical
>> stream addressing. The excerpt above talks about a user agent being able to
>> "seek to an earlier point than the first frame originally provided by the
>> server" but does not explain how this could possibly happen without
>> communication back to the server, in which case we are effectively dealing
>> with a request for a different physical resource. At the very least, the
>> fact that the Firefox and Chrome teams came up with different
>> interpretations shows that this part of the specification would benefit
>> from clarification.
>>
>
>
> And an earlier blog post about startOffsetTime specifically[3]:
>
>  The reason for setting this out is that we'd like to see consistent
>> support for startOffsetTime across all commonly used codecs and for browser
>> vendors to bring their implementations into line with the published HTML5
>> media elements specification. There are ambiguities in the specification
>> itself, such as the interpretation of 'earliest seekable position', which
>> could be clarified, especially with respect to continuous live streaming
>> media. Browser vendors need to agree on a common interpretation of
>> attributes such as currentTime so others can experiment with the exciting
>> possibilities this new technology is opening up.
>>
>
>
>
> Sooo... It would be nice to get some real cleanups to the whole media +
> time thing. :D
>
>
>
> 1. <http://www.whatwg.org/specs/**web-apps/current-work/**
> multipage/the-video-element.**html#offsets-into-the-media-**resource<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#offsets-into-the-media-resource>
> >
> 2. <http://www.bbc.co.uk/blogs/**researchanddevelopment/2012/**
> 02/what-does-currenttime-mean-**in.shtml<http://www.bbc.co.uk/blogs/researchanddevelopment/2012/02/what-does-currenttime-mean-in.shtml>
> >
> 3. <http://www.bbc.co.uk/blogs/**researchanddevelopment/2012/**
> 01/implementing-**startoffsettime-f.shtml<http://www.bbc.co.uk/blogs/researchanddevelopment/2012/01/implementing-startoffsettime-f.shtml>
> >
> --
> Odin H?rthe Omdal ? Core QA, Opera Software ? http://opera.com /
>
Received on Wednesday, 7 March 2012 07:04:33 UTC

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