[whatwg] [media] startOffsetTime, also add startTime?
Odin Hørthe Omdal
odinho at opera.com
Wed Mar 7 02:56:42 PST 2012
startOffsetTime seem to leave people confused, I often have to explain it,
and yesterday I read the spec 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
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
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
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:
And introduced here:
Sean O'Halpin of BBC recently mentioned 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:
> 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
Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /
More information about the whatwg