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

[Ian Hickson]

On Wed, 7 Mar 2012, Odin Hørthe Omdal 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.

Can you elaborate on how it's confusing? I don't really understand.


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

What is 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 ago.

If you start streaming at 3:15 (no date) into a stream that had a finite 
start at an implicit 0:00, then it is conforming (recommended as "should", 
in fact) for the media's first frame to be at currentTime=195s.

In fact if the media has a timestamp, browsers are explicitly urged 
("should") to only rebase it to 0 if the timeline has a negative 
component. If the media has a discontinuous timeline, the timeline used 
for the first part is required ("must") to extend it to the rest of the 
resource, but it is still used as is. only if no timeline is present at 
all (e.g. an MJPEG stream) is the user agent supposed to use a zero origin 
for the timeline, and even then it's still only a "should".


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

I don't understand what this is asking for. Can you give a concrete 
example with a specific media stream I can look at?


> 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 is only useful when there's a date component. The only 
time I'm aware of that being available is for something like a cable TV 
DVR. Does any Web media format have a way to specify a date?


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

You'll definitely need communication with the server; even for just 
straight streaming without seeking, or for seeking forwards, you'll 
probably want client-to-server communication (e.g. for bandwidth 
management).

Not sure what the difference is between a "logical" and "physical" 
resource in this case though.


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

The spec intentionally allows different behaviours with respect to how 
much of the stream the user is allowed to seek to. A browser could just 
make .seekable return a single empty range consisting of just the 
currentTime, for instance.


I'm happy to change the spec on this point, but I don't understand what 
the problem is, so it's hard for me to make changes.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'