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

[Philip Jägenstedt]

On Fri, 09 Mar 2012 15:40:26 +0100, Philip Jägenstedt <philipj at opera.com>  
wrote:

> 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  
the spec:

"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  
the confusion.

* 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  
streaming.

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  
dates.

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  
marked out.

* 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.

-- 
Philip Jägenstedt
Core Developer
Opera Software