Re: Firing media events early for throttled downloads

On Thu, 30 Apr 2009, Robert O'Callahan wrote:
> On Wed, Apr 29, 2009 at 5:23 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Thu, 2 Apr 2009, Robert O'Callahan wrote:
> > > Suppose a page waits for the "canplaythrough" or "load" events to 
> > > fire on an "autobuffer" media element before it starts playing the 
> > > media. Then suppose that a user-agent has a media data cache that's 
> > > smaller than the size of the media resource, so after loading some 
> > > amount of the data the user-agent decides to pause the download 
> > > because the cache is full. Unfortunately, the page will never start 
> > > playing the media.
> > >
> > > Authors can work around this by starting playback on receiving the 
> > > "stalled" event. (I'm assuming the the user agent is able to free up 
> > > cache space for played media data, so it will be able to resume the 
> > > download and eventually play the entire resource.) But that event 
> > > could fire in other situations, say due to temporary network stalls, 
> > > when the page would not need to start playback. It's also a trap for 
> > > authors; in testing they might never notice that the "stalled" 
> > > handler is needed.
> > >
> > > Should the spec allow the user-agent to set the media element ready 
> > > state to HAVE_ENOUGH_DATA, and to fire the "load" event, if it 
> > > pauses the download due to local resource constraints that may 
> > > persist indefinitely?
> >
> > The 'suspend' event, already specified, is intended for this case.
> 
> OK, that's good, but it's still going to be a trap for authors to listen 
> for "load" or "canplaythrough" and forget to listen for "suspend" 
> because that never fires in their test setup.

This seems like a premature optimisation. I agree that it's possible that 
authors will forget to do this right, but I believe that if we ensure that 
we have good tutorials for this API, we can sidestep this issue.

In the case of autoplaying, note that there is a better way than using 
script anyway -- we have an explicit "autoplay" attribute which we should 
be encouraging authors to use instead. This gives UAs the hint that they 
need to continue buffering past the point where they would otherwise have 
suspended the download, and again sidesteps the entire issue.

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

Received on Friday, 5 June 2009 20:14:36 UTC