Re: [whatwg] Firing canplaythrough when caches/buffers are full

On Mon, 28 May 2012, Robert O'Callahan wrote:
>
> We encountered an app that uses "canplaythrough" on a video element to 
> trigger execution of the app "so we don't start playing the video until 
> we can do so without stuttering". http://gaiamobile.org/apps/cubevid/ 
> This approach works fine on desktop browsers. On mobile browsers, we 
> want a smaller limit on the amount of data buffered by the media 
> subsystem. That means we pause the download before "canplaythrough" 
> would fire, so it never fires, so the app doesn't work.
> 
> We could fix this particular app, but this seems like a natural thing 
> for authors to do and get wrong.
> 
> I propose fixing this by having the UA enter the HAVE_ENOUGH_DATA 
> readyState when the UA decides to suspend a download indefinitely and 
> the preload state is "Automatic" (or overriden by "autoplay" being set).
> 
> We have checked in a patch to Gecko to do this. (Note that for a long 
> time, Gecko has triggered playback of autoplay elements when suspending 
> due to media buffers being full. The new change makes us enter 
> HAVE_ENOUGH_DATA as well.)

I've adjusted the definition of HAVE_ENOUGH_DATA to include this case. You 
have to have at least the conditions of HAVE_FUTURE_DATA (i.e. you have to 
be able to move at least one frame if play() is called), but beyond that, 
if you are in a state where waiting longer isn't going to help, you can 
just jump to HAVE_ENOUGH_DATA and fire the event.

(The goal of the state and event is for apps to know how long to wait, so 
obviously if waiting longer isn't going to be helpful then it makes no 
sense to not fire the event.)


On Wed, 30 May 2012, Jer Noble wrote:
> 
> For what it's worth, the Mac port of WebKit has this exact behavior: 
> <http://trac.webkit.org/changeset/97944>.  It would be good to formalize 
> this, however.

On Wed, 30 May 2012, Andrew Scherkus wrote:
> 
> Chrome's canplaythrough logic (which admittedly needs a little work) has 
> similar behaviour. I agree it'd be good to formalize the behaviour.
> 
> Rob: when you say to suspend a download indefinitely would this coincide 
> with dropping the networkState to NETWORK_IDLE and subsequently firing a 
> suspend event?

On Thu, 31 May 2012, Robert O'Callahan wrote:
> 
> I'm not sure whether we want to require that the readyState go to 
> HAVE_ENOUGH_DATA every time networkState goes to NETWORK_IDLE, though.

I have indeed not required that.

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

Received on Friday, 15 June 2012 22:31:42 UTC