Re: <video> readyState oddities

On Fri, 25 Feb 2011, Philip Jägenstedt wrote:
> 
> "When a media element is potentially playing and its Document is a fully 
> active Document, its current playback position must increase 
> monotonically at playbackRate units of media time per unit time of wall 
> clock time."
> 
> During normal playback, whether or not currentTime increases depends on 
> "potentially playing":
> 
> "A media element is said to be potentially playing when its paused 
> attribute is false, the readyState attribute is either HAVE_FUTURE_DATA 
> or HAVE_ENOUGH_DATA, the element has not ended playback, playback has 
> not stopped due to errors, and the element has not paused for user 
> interaction."
> 
> In other words, when readyState is HAVE_METADATA or HAVE_CURRENT_DATA, 
> currentTime doesn't change, but I can't see that it's clearly defined if 
> readyState should fall back to HAVE_METADATA or HAVE_CURRENT_DATA when 
> playback has ended or you just ran out of buffer.

While it has data, it'll be in HAVE_CURRENT_DATA and will be increasing. 
It'll get to the last frame where it has data, where it will still be in 
HAVE_CURRENT_DATA, and it will thus increase once more, at which point it 
won't have data and it'll therefore switch to HAVE_METADATA and the 
position will stop increasing.

Again, this all seems pretty unambiguous.


> My reading would be that it depends on if the end of buffered TimeRanges are
> inclusive or not. Example: if buffered.end(0) == 1 and currentTime == 1, is
> "Data for the immediate current playback position is available"? Is readyState
> HAVE_METADATA or HAVE_CURRENT_DATA?

Yeah, that's a good question (but orthogonal to the issue at hand, IMHO). 
I've filed a bug to make sure I specify explicitly that TimeRanges are 
inclusive (which seems like the only behaviour that would be intuitive 
-- you wouldn't want .end(0) to be greater than .currentTime when the 
video has .ended, right?).

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=12186


> > > I think it would make sense to behave the same way as at the end of 
> > > the resource, and that HAVE_CURRENT_DATA actually makes sense.
> > 
> > Not sure what you mean.
> 
> Running out of data because the network is slow or because the end of 
> the resource has been reached is really very similar on the decoding 
> side of things, so I think the state should be the same for consistency, 
> be that HAVE_METADATA or HAVE_CURRENT_DATA.

It seems extremely different in one key respect: when you have ended, the 
frame you _want_ to be rendering is the last one, but when you have run 
out of data, the frame you _want_ to be rendering is the next one.


> In the best of worlds we wouldn't have these two barely distinguishable 
> states, but clearly this is not the best of worlds.

These states seem very distinguishable to me, but maybe I'm just too close 
to the API to see the woods for the trees. :-)

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