[whatwg] <video> feedback

[Matthew Gregan]

At 2009-03-25T10:16:32+0000, Ian Hickson wrote:
> On Fri, 13 Mar 2009, Matthew Gregan wrote:
> > It's possible that neither a 'play' nor 'playing' event will be fired
> > when a media element that has ended playback is played again.  When
> > first played, paused is set to false.  When played again, playback has
> > ended, so play() seeks to the beginning, but paused does not change (as
> > it's already false), so the substeps that may fire play or playing are
> > not run.
>
> 'playing' should fire, though, since the readyState will have dropped down
> to HAVE_CURRENT_DATA when the clip is ended, and will drop back up to
> HAVE_FUTURE_DATA after seeking.

Right, so your intention is to interpret it thusly: readyState becomes
HAVE_CURRENT_DATA when playback ends because it's not possible for the
playback position to advance any further, and thus it's not possible to have
data beyond the current playback position (which HAVE_FUTURE_DATA is
predicated upon).

Makes sense, but can the spec be made clearer about the behaviour in this
case?  HAVE_FUTURE_DATA talks about "advancing *without reverting to
HAVE_METADATA*", which doesn't apply in this case because we have all the
data available locally.

(Also, note that after the seek it'd return directly to HAVE_ENOUGH_DATA in
the case I'm talking about, since the media is fully cached.  That still
requires a 'playing' event to fire, so that's fine.)

Based on that interpretation, when the user sets playbackRate to -1 after
playback ends, the readyState would change from HAVE_CURRENT_DATA to
HAVE_FUTURE_DATA because the current playback position can now advance.

Following this logic, if playbackRate is set to 0 at any time, the
readyState becomes HAVE_ENOUGH_DATA, as advancing the playback position by 0
units means the playback position can never overtake the available data
before playback ends.  Except this case seems to be specially handled by:

       "The playbackRate can be 0.0, in which case the current playback
       position doesn't move, despite playback not being paused (paused
       doesn't become true, and the pause event doesn't fire)."

...which uses the term "move" rather than "advance", but suggests that the
concept of the playbackRate advancing by 0 isn't consider advancing, which
seems logical.

Cheers,
-mjg
-- 
Matthew Gregan                     |/
                                  /|                    kinetik at flim.org