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

[Odin Hørthe Omdal]

On Thu, 08 Mar 2012 12:50:41 +0100, Ingar Mæhlum Arntzen  
<ingar.arntzen at gmail.com> wrote:
> Here's my reasoning. The progress value that is visualized in the video
> element (i.e. currentTime) is part of the end-user experience. For this
> reason it is important that it communicates the appropriate abstraction
> consistently to all end-users.


Ah, but that is up to the user agent to decide how to show the time code.  
The currentTime should be normalized from 0 until duration. That makes the  
API behave in a common way for all easy tasks. If you write a video player  
for your small cat clip, that video player will also work with streaming  
video without any problem. That is a good thing.

However, the user agent is free to show you (the user) your "real"  
position. And I agree that doing that makes sense. They don't exclude  
eachother.

> Maybe "joinTime" or some other property could be added to hold that
> information (which Chromium appears to lack - according to Sean O'Halpins
> comments).
>
> Alternatively, to match you suggestion, if it is the sum ("startTime" +
> "currentTime") that is visualilzed in the video element, that might be OK
> too, but possibly more phrone to confusion?

Only video player authors will actually see and use those attributes. They  
should be built for being robust and working nicely for different usages.  
Like I said, making the "dumb video player" also work for live streamed  
video without any changes.

If you want to do a more advanced media player that is live video  
streaming aware, you will have to opt-in to that instead. All the same is  
possible, only one way is more backward-proof than the other.

Philip Jägenstedt proposed "offsetTime" for what we've called "startTime",  
which IMHO is a clearer name.


> In addition, I wonder if negative values for currentTime are legal. For
> instance, when streaming a Formula 1 race that starts at 17.00, I would  
> not
> be surprised to see negative currentTime if I join the stream before the
> race starts.

They are not, and shouldn't be. currentTime is always normalized to 0 ->  
duration.

However, you would be perfectly able to write a video player that does  
that by using offsetTime and currentTime together. Even better, the  
proposed "currentDate" exposes the underlying "date of recording" (or  
similar date) of the media, which you can then just look for 2012-03-08  
17:00. Actually, you could also build your video player to show that date  
on-screen, because 17:00 on the screen might be 18:13 at my place, because  
a) I'm in a different time zone, and b) there's 13 minutes worth of  
buffering between the Formula 1 production cameras and my computer.

-- 
Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /