Monday, December 21st, 2009

HTML5 Video Autobuffers, Always

Category: Video

John Gruber of Daring Fireball says that the HTML5 video element, simple as it is, always autobuffers on Safari, Chrome, and Firefox. It’s something others have also come up against. Any videos on the page will start downloading right away, regardless of the “autobuffer” attribute’s setting:

The HTML5 spec defines an autobuffer attribute for the video and other media elements (bold emphasis added):

The autobuffer attribute is a boolean attribute. Its presence hints to the user agent that the author believes that the media element will likely be used, even though the element does not have an autoplay attribute. (The attribute has no effect if used in conjunction with the autoplay attribute, though including both is not an error.) This attribute may be ignored altogether.

It would appear, in my testing, that all three of these browsers take the spec up on the aforebolded offer to ignore this attribute. Even if you do not explicitly turn this attribute on, Safari, Chrome, and Firefox will still auto-buffer the content for your <video> (and <audio>) elements. There is no way to suppress this using HTML markup.

As Gruber points out, this might seem like a good thing for fast UI: videos start playing as soon as the user wants them to. That would be true in a world of unlimited bandwidth, but for now, this feature is likely to be a massive bandwidth hog. There is a nice workaround, albeit one that peels back the utter simplicity of a single <video> tag:

  1. In the HTML markup, rather than a <video> element, instead use an <img> element with the intended poster frame.
  2. Add an onclick JavaScript handler to the <img> element, which, when invoked, does some DOM jiggery-pokery to remove the just-clicked-upon <img> element and replace it with a <video> element that sources the intended video files.

And, in fact, that is exactly what I resorted to for my PastryKit videos. Do a View Source on that page to see the solution.

It’s difficult to see <video> becoming the web’s standard video component if every video buffers as soon as the page loads.

Posted by Michael Mahemoff at 6:56 pm

3.8 rating from 32 votes


Comments feed TrackBack URI


Comment by TNO — December 21, 2009

What happens if one does not set the src attribute in the first place and sets it only after the poster frame removal?
That’s what we were doing in Flash since like… when was YouTube launched?

Comment by cosmincimpoi — December 22, 2009

The ‘work around’ is terrible, one of the only real benefits of the video tag imo is the semantic intent.. plus, seems like the problem either doesn’t really exist or is highly likely to be fixed before it causes any big problems.

Comment by meandmycode — December 22, 2009

As is common with draft specs, the phraseology chosen doesn’t actually communicate the meaning intended. My assumption would be that the “this attribute may be ignored altogether” bit was intended to actually prevent forced auto-buffering, i.e: website author specifies that the video should be autobuffered, but the user is on a metered connection and therefore has set their browser to never autobuffer. The browser is allowed to ignore the attributed for scenarios such as this. However, it seems the current iterations of HTML 5 video-supporting browsers has implemented it backwards. It’s actually far more likely that they simply didn’t implement it at all and the video element is currently treated almost like an image element: it is downloaded as part of rendering the page.

Comment by chrisdpratt — December 23, 2009

On a page that has a few 1-hour long videos you loose control over bandwidth very quickly. Sadly.

I hope autobuffer option will be respected in next iterations of browsers.

Comment by michalfrackowiak — January 6, 2010

Leave a comment

You must be logged in to post a comment.