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

[Philip Jägenstedt]

On Tue, 03 Apr 2012 19:13:12 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 3 Apr 2012, Philip Jägenstedt wrote:
>> > >
>> > > It could also do with a good example. The spec says:
>> > >
>> > > "If the media resource specifies an explicit start time and date,
>> > > then that time and date should be considered the zero point in the
>> > > media timeline; the timeline offset will be the time and date,
>> > > exposed using the startOffsetTime attribute."
>> > >
>> > > I interpret this as [...] currentTime=-initialTime (unless media
>> > > fragments are used) in the Opera/Firefox definition of currentTime.
>> >
>> > Not sure what this means.
>>
>> In current Opera and Firefox the timeline is always normalized to start
>> at 0, so the time that corresponds to 0 in the original timeline would
>> be at a negative currentTime.
>
> I still don't really understand what you mean by "start" here.
>
> The idea is that all the times are unsigned, though. So if there's any  
> way
> to seek to one of these times that are before what you're calling the
> "start", then yeah, it'll be a mess, because the naive approach of simply
> drawing a seek bar from 0 to duration (rather than seekable.start(0) to
> duration) will fail.

What I mean with "normalized to start at 0" is that when playing the whole  
resource, currentTime will start at 0 and end at duration. (This was not  
really a deliberate choice in Opera, it's just what GStreamer does and I  
never thought about it until this issue came up.)

>> We will have to change this at the same time as implementing startDate,
>> since otherwise everything will be a mess...
>
> So long as startDate gives the Date at media timeline's 0 point, it
> doesn't really matter exactly what the media timeline is.

Yeah, I guess we could shift startDate by same (undetectable) offset, but  
if we're going to spend efforts shifting things around we might as well  
shift currentTime into alignment with the spec :)

>> > > > > Finally, what about initialTime? [...]
>> > >
>> > > Yes, but why do we need to expose that in the DOM API, what is the
>> > > use case?
>> >
>> > Allows controllers to trivially implement UI to jump back to where the
>> > stream started, while still showing the full seekable range.
>>
>> Unless I'm missing something, initialTime is just the initial value of
>> currentTime, so this is already easy.
>
> Only if the controller is around when the video is created. Don't forget
> that one of the design principles of this API is that you should be able
> to hook up a controller at any time and have it be able to provide a
> fully-fledged controller.

Right, I keep forgetting that...

>> Also, if media fragments are not used, just setting currentTime=0 will
>> clamp and seek to the earliest position. However, I've never actually
>> seen such UI for <video>, do you have a real world example? It seems to
>> me like this is a <1% use case that is already easy to solve and that
>> it's not worth adding an API to go from easy to trivial.
>
> Yeah, that's probably fair. I've removed initialTime.

Thanks!

[snip]

The spec changes around explicit timelines and static/streaming resources  
are a big improvement, thanks! However, it now talks about both "explicit  
timeline" and "explicit timings" in a way that makes me uncertain about  
Ogg. Ogg (at least without skeleton) is just a stream of timestamped  
packets, so the timeline simply spans the timestamp of the first packet to  
the timestamp of the last packet. WebM is similar in the streaming case in  
that timestamps the don't start at 0. Clarification of whether or not  
"explicit timestamps" (Ogg, WebM) implies an "explicit timeline" would be  
welcome. I assume that's the intention, which I also agree with. (Perhaps  
saying "explicit frame durations" instead of "explicit timings" would also  
help.)

Finally, a typo: "no explicit timings ofd any kind"

-- 
Philip Jägenstedt
Core Developer
Opera Software