W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Should <video> buffer control be tri-state?

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 08 Jan 2010 01:13:03 +0100
To: "Jeremy Keith" <jeremy@adactio.com>, "HTMLwg WG" <public-html@w3.org>
Message-ID: <op.u56tjqvlsr6mfa@worf>
On Fri, 08 Jan 2010 00:36:49 +0100, Jeremy Keith <jeremy@adactio.com>  
wrote:

> Henri suggested:
>> "no buffering strategy": Don't request any piece of the video at all  
>> before the video is played.
>
> To which Philip responded:
>> the "no buffering" strategy won't be possible to use for <audio>
>
> Could you explain this a bit more, please? Isn't this what Mozilla  
> currently does for <audio> elements that don't have an @autobuffer  
> attribute? (i.e. "don't request any piece of the audio at all before the  
> audio is played")

To get the first frame and duration for Ogg Theora, you must make at least  
2 HTTP requests to get the beginning and end of the file (unless the  
X-Content-Duration header is used, in which case 1 would suffice). This  
must be done for all <audio> or <video> elements for them to reach  
HAVE_METADATA and to fire the load event on window. This may or may not be  
a problem, but a "no buffering" strategy would stall before download  
begins and stay at HAVE_NOTHING. Basically it's a click-to-play video that  
otherwise does nothing more than an image. Since this can be done with  
some script it's not vitally important to allow, but it would make more  
sense in an enumeration attribute "buffering" (or whatever) than e.g.  
triggering on the absence of autobuffer (breaks everything) or a new  
attribute (not worth it).

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 8 January 2010 00:13:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:57 GMT