On Tue, 03 Apr 2012 19:13:12 +0200, Ian Hickson <i...@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
