[whatwg] [media] startOffsetTime, also add startTime?
philipj at opera.com
Tue Mar 13 03:56:41 PDT 2012
On Fri, 09 Mar 2012 15:40:26 +0100, Philip Jägenstedt <philipj at opera.com>
> let me first try to summarize what I think the spec says:
> * currentTime need not start at 0, for streams it will typically
> represent for how long the server has been serving a stream.
> * duration is not the duration, it is the last timestamp of a resource.
> * startOffsetTime is the date at time 0, it's not an offset. It has
> nothing to do with syncing live streams.
> * initialTime is the first timestamp of the stream or the start time of
> a media fragment URL, if one is used.
> * For chained streams, the 2nd and subsequent clips have their timelines
> normalized and appended to the first clips timeline.
I think this is mostly correct, but Odin pointed out to me this section of
"In the absence of an explicit timeline, the zero time on the media
timeline should correspond to the first frame of the media resource. For
static audio and video files this is generally trivial. For streaming
resources, if the user agent will be able to seek to an earlier point than
the first frame originally provided by the server, then the zero time
should correspond to the earliest seekable time of the media resource;
otherwise, it should correspond to the first frame received from the
server (the point in the media resource at which the user agent began
receiving the stream)."
There are multiple problems here, and I think it's responsible for some of
* What is an "explicit timeline"? For example, does an Ogg stream that
starts with a non-zero timestamp have an explicit timeline?
* Does "For streaming resources ..." apply only in the absence of an
explicit timeline, or in general? In other words, what's the scope of "In
the absence of an explicit timeline"?
* Why does the spec differentiate between static and streaming resources
at all? This is not a distinction Opera makes internally, the only "mode
switch" we have depends on whether or not a resource is seekable, which
for HTTP means support for byte-range requests. A static resource can be
served by a server without support for byte-range requests such that the
size and duration are known up front, and I certainly wouldn't call that
These definitions can be tweaked/clarified in one of two ways:
1. currentTime always reflects the underlying timestamps, such that a
resource can start playing at a non-zero offset and seekable.start(0)
could be non-zero even for a fully seekable resource. This is what the
spec already says, modulo the "streaming resources" weirdness.
2. Always normalize the timeline to start at 0 and end at duration.
I think that the BBC blog post is favoring option 2, and while that's
closest to our implementation I don't feel strongly about it. A benefit of
option 1 is that currentTime=300 represents the same thing on all clients,
which should solve the syncing problem without involving any kinds of
To sum up, here's the spec changes I still think should be made:
* Make it pedantically clear which of the above two options is correct,
preferably with a pretty figure of a timeline with all the values clearly
* Rename startOffsetTime to make it clear that it represents the date at
currentTime=0 and document that it's intended primarily for display. I
wouldn't object to just dropping it until we expose other kinds of
metadata like producer/location, but don't care deeply.
* Drop initialTime.
More information about the whatwg