Mozilla

autobuffering video in Firefox

John Gruber recently wrote up an article titled Why the HTML5 ‘Video’ Element Is Effectively Unusable, Even in the Browsers Which Support It

He’s mostly upset that browsers don’t respect the autobuffer attribute. Or, really, that browsers autobuffer by default. Safari and Chrome do apparently autobuffer by default, but he incorrectly says that Firefox does as well. Just to be clear: Firefox does not autobuffer by default, nor does it autoplay by default. I’m not sure how his testing led him to believe that it does, but I wrote up some examples to show that it does not. Here are three examples:

The best way to test this is to load your favorite browser and clear its cache. Then load your favorite network monitor. Then load the page without the autobuffer attribute set. You can see how much bandwidth the browser is actually using via your external tool.

Of the browsers I tried, only Firefox gives useful feedback on how much is actually buffered as part of its native control set so you have to go to external tools to be able to tell what’s going on with anything else. If you load the page with two videos – one with autobuffer set and one without - you can mouse over them in Firefox and see how one has buffered and one hasn’t.

The video on that test page is pretty big – around 115mb – so you can really tell when it’s buffering even on a fast network.

Here’s what my testing shows:

This is consistent with what I know about Safari. I talked with one of the Apple WebKit engineers a few months ago and he said that Safari for desktops buffered by default and said that Safari for mobile does not.

There might be some confusion because Firefox does make a couple of network requests when you include a video tag. This is done for two reasons:

  • To get the first frame of the video and it’s size. It will only download a small part of the beginning of the video to get the first frame and then stop downloading.
  • If your server supports byte range requests, it seeks to the end of the video to try and determine the duration of the video. If your server doesn’t support byterange requests, we don’t get the duration. (Ogg was originally designed as a format for streaming, not static files and as such doesn’t include duration information in the header of the file, although there is work underway to add this functionality.)

If you want to get a sense of how Firefox uses bandwidth, try this bandwidth test I wrote a few months ago. It uses a Firefox-only feature to read progress information on a video as it’s downloaded and give you a rough sense of the amount of bandwidth that particular video element is using. It shows a little traffic when you load the video and then shows how it starts using bandwidth once you press the play button.

But this shows that we understand John’s point of view and we made the decision not to auto buffer by default for the very reasons he points out.

30 comments

Comments are now closed.

  1. Justin Dolske wrote on December 21st, 2009 at 18:24:

    I think your bandwidth test is doing the same thing as the built-in video controls do… There’s a buffering bar that indicates how much of the video has been downloaded. For autobuffer videos you’ll see the bar immediately start progressing, for non-autobuffer videos you won’t.

    I wonder if Gruber was confused by the autobuffer attribute being a boolean attribute… [video autobuffer="false"] will *enable* autobuffering, because boolean attributes are only checked for their existence, not value. It’s my least favorite part of the spec. [video autobuffer] is all that’s needed, [video autobuffer="bacon"] means the same thing so far as the spec is concerned.

  2. Justin wrote on December 21st, 2009 at 18:38:

    Just read the article by Gruber about 10 mins before seeing this. I gave it a try FF 3.5.6 and it worked as you said. Glad to see Firefox doing the right thing here, but due to the fact the other browsers auto buffer even when not specified his solution would still be the same. Hopefully the other browsers will follow Firefox’s lead and add this in the next update.

  3. Brodie wrote on December 21st, 2009 at 20:50:

    It seems quite clear that Gruber wants the video to not be touched at all until the user clicks play. He doesn’t want the first frame displayed, nor the length detected. He wants the poster image displayed and nothing else until the user clicks play. This seems quite reasonable and is what I would expect the behaviour to be when a poster image is supplied.

  4. Mathias Bynens wrote on December 21st, 2009 at 23:50:

    Justin: It should be added that autobuffer is a shorthand for autobuffer="autobuffer". Which spec are you talking about? You’re right that autobuffer="bacon" may work as well, but according to the spec, it’s invalid:

    A number of attributes are boolean attributes. The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

    If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute’s canonical name, with no leading or trailing whitespace.

    The values “true” and “false” are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

  5. Andy Baio wrote on December 22nd, 2009 at 00:14:

    John corrected his article and apologized for the error.

  6. Colm Cinneide wrote on December 22nd, 2009 at 01:55:

    hi mozer,

    (trying to follow Mr. Eich on video was a ‘true agony.’) .

    as to say, open web page, use video, is *not* here,
    yet, for us, users anyways .

    .colm:

  7. Mathias Bynens wrote on December 22nd, 2009 at 03:20:

    Did you guys disapprove / remove my previous comment?

    @Justin:

    [video autobuffer] is all that’s needed, [video autobuffer="bacon"] means the same thing so far as the spec is concerned.

    I don’t know which spec you’re is talking about, but according to the HTML5 specification autobuffer="bacon" is invalid:

    A number of attributes are boolean attributes. The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

    If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute’s canonical name, with no leading or trailing whitespace.

    The values “true” and “false” are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

    You’re right that browsers should interpret autobuffer="bacon" as autobuffer="autobuffer", but saying that it’s the same in the spec is simply incorrect.

  8. Martin Kliehm wrote on December 22nd, 2009 at 05:59:

    @justin When autobuffer=”false” is the same as autobuffer=”bacon” or autobuffer=”true” that part of the spec needs to be fixed. This is so wrong, unintuitive and prone of authoring errors. Also if “false” actually means “true”, how do you disable the darned thing? Oh, you don’t, because the spec says browsers can ignore it. :(

  9. Ben De Rydt wrote on December 22nd, 2009 at 06:07:

    >> To get the first frame of the video and it’s size. It will only download a small part of the beginning of the video to get the first frame and then stop downloading. <<

    Why go through all this trouble when you could just display the poster image? I can't believe poster image do not work on the latest official Firefox (3.5.6).

    Also, setting a src in javascript and calling video.load() doesn't work.

  10. Adam Luter wrote on December 22nd, 2009 at 06:32:

    One thing that is keeping the video tag out of all our sites is actually Firefox supporting the video tag. Before that, we could put video around our flash player and we could be happy that at least on Safari things “worked” and everyone else could use flash to playback our video.

    However, since Firefox 3.5 we can no longer do this because Firefox does not support the same codec as Safari, but only OGG. Now, that’s not itself the problem. The problem is: If you have a video tag Firefox assumes it should activate it even if there are no OGG sources listed. So, unless you encode all of your videos both in OGG and MP4, you can’t use the video tag, lest Firefox users get a big blank box.

    To repeat, a video tag with just an MP4 file *cannot* fall back to a flash player (on Firefox). Oh well.

  11. Carl wrote on December 22nd, 2009 at 06:36:

    The iPhone appears not to buffer until you click the movie’s icon on the page.

  12. Dan wrote on December 22nd, 2009 at 08:37:

    The video without autobuffer behaves awkwardly when pressing play. It play a fraction of a second of video and audio, then stops and starts buffering before playing properly. I can see why this is, but I think it would be better to just not start playing until the video has buffered properly.

  13. Jenn wrote on December 22nd, 2009 at 09:07:

    And I really want to thank Mozilla for this propper autobuffer behaviour.

    It seems today you can only use video elements with ogg files, because in absence off Quicktime ogg plugins Webkit will not download the video by default – as it sadly will do with an mp4.

    It’s a really disappointing Webkit implementation, and I never thought I would once find something about Gecko superior.

    Oh, I forgot img alt text – thats much superior too.

  14. Christopher Blizzard wrote on December 22nd, 2009 at 10:43:

    Yeah, Dan, I agree. I suspect that’s just a long-standing bug.

  15. Christopher Blizzard wrote on December 22nd, 2009 at 10:46:

    I updated the post with some info from Opera on what they will do.

  16. Andrew Harvey wrote on December 22nd, 2009 at 14:22:

    This is all well and good, but I want to be able to tell my browser to disregard each individual video tag attributes and disable autobuffer for all videos. (My download quota is expensive!)

  17. Berserk wrote on December 22nd, 2009 at 15:35:

    This is an area where the spec hasn’t been thought through. Absence of an attribute does not signal author intent strong enough, imho.

    Instead of , and , it would have been better with , and . Then you can say that user agents _should_ honor the attribute if it exists, and do what they want if it does not.

  18. Robert O’Callahan wrote on December 22nd, 2009 at 21:55:

    Adam: that’s a spec issue. The HTML5 spec provides no way to fall back to alternative content if you don’t support any of the offered media types.

  19. Silvia Pfeiffer wrote on December 23rd, 2009 at 00:05:

    Jenn: you should use XiphQT with Safari/Webkit to play Ogg in html5 video and audio elements, see http://www.xiph.org/quicktime/

  20. Adam Luter wrote on December 23rd, 2009 at 05:54:

    @Robert: That’s fine. Don’t expect that to help adoption then. The whole point of and is to allow falling back when things are not supported. So, if the spec doesn’t let you look at the source’s mime type (which is set in the markup) and be able to say “oh I don’t support that, fallback!”, then it’s next to worthless. Sigh.

  21. Pingback from Benjamin Fleischer » Blog Archive » Limitations of Current HTML5 Video Tag Implementation on December 23rd, 2009 at 09:39:

    [...] work at all in Chrome (at least on the Mac) … In all three browsers (Safari, Chrome, Firefox), with the above simple markup, the video content buffers automatically on page load. What I mean [...]

  22. Pingback from Auto-Buffering Video in Firefo… | Wish Studios on December 23rd, 2009 at 10:43:

    [...] Auto-Buffering Video in Firefox http://hacks.mozilla.org/2009/12/autobuffering-video-in-firefox/ [...]

  23. Pingback from Twitter Updates for 2009-12-23 | Wish Studios on December 23rd, 2009 at 15:01:

    [...] Video in Firefox http://hacks.mozilla.org/2009/12/autobuffering-video-in-firefox/ [...]

  24. Pingback from HTML5 video con problemas en todos los navegadores : Blogografia on December 23rd, 2009 at 19:40:

    [...] Como todos sabemos, Internet Explorer no lo soporta, algo que no nos sorprende pero nos fastidia. Por otro lado, el tag dispone de un atributo que especifica que el vídeo debe autodescargarse a modo de buffer, este atributo no es tratado por todos los navegadores de igual forma, Google Chrome y Safari si que lo soportan pero empiezan a descargar los videos ignorando la inclusión del atributo en cambio, Firefox si que detecta este atributo y lo tiene en cuenta para auto-iniciar la descarga. [...]

  25. Kosso wrote on December 24th, 2009 at 08:24:

    I agree with Ben and Brodie in that the actual video url should NOT be hit AT ALL until a user clicks a ‘poster image’. Server stats on these videos will be skewed too otherwise.

  26. Kroc Camen wrote on December 26th, 2009 at 04:33:

    I’ll post this here because I don’t know who specifically to e-mail, and this thread is about the subject.

    “It’s not that Mozilla and her bloggers don’t value open video, it’s that there appears two problems:

    1. No sense of want; far too pampered by their WordPress installs and the presence of Flash on their computers

    2. No guiding call from the official channels (MozFoundation / MozCorp) for the bloggers to heed

    I seriously believe that all Mozilla engineers need to spend a week without Flash, and second to that I believe the official Mozilla (The CEO and the paid employees) need to make a statement to the volunteer and external engineers that open video is at the heart of Mozilla and that they are _encouraged_ to use HTML5 video in their blogs. Then I think we would see some take up.

    The bugs and the faults with HTML5 will be solved only if engineers are being beaten with them. I made Video For Everybody http://camendesign.com/video_for_everybody because I don’t have Flash. I felt no need to make something like VfE whilst I did have Flash. It’s that simple.

    In order for HTML5 video implementations to improve to the point they will see mass adoption, we need the developers first doing the adopting and eating their own video dog food.”

    Here at Mozilla Hacks you’ve been using HTML5 video as part of your series on Firefox features, but continually in P.M.O I’m left without being able to see various videos and announcements because there is not enough encouragement, need nor want to use HTML5 video. I’m asking you to fix this please through education, software and video servers. Thank you.

  27. Pingback from HTML5 video con problemas en todos los navegadores | aNieto2K on December 27th, 2009 at 05:13:

    [...] Como todos sabemos, Internet Explorer no lo soporta, algo que no nos sorprende pero nos fastidia. Por otro lado, el tag dispone de un atributo que especifica que el vídeo debe autodescargarse a modo de buffer, este atributo no es tratado por todos los navegadores de igual forma, Google Chrome y Safari si que lo soportan pero empiezan a descargar los videos ignorando la inclusión del atributo en cambio, Firefox si que detecta este atributo y lo tiene en cuenta para auto-iniciar la descarga. [...]

  28. Anonymouse wrote on January 1st, 2010 at 11:38:

    Is there an about:config parameter so that I can prevent ANY video from autobuffering, even if the site author has set this attribute?

  29. Silvia Pfeiffer wrote on January 6th, 2010 at 23:38:

    @Anonymouse I’m indeed hoping that browser vendors will introduce preference settings for this.

  30. wanker wrote on January 7th, 2010 at 11:06:

    Remember to look for byte ranges requested, not just hits on the video file, when you look in the access log.

    According to the RFC, web servers that do not support Range should just return the entire file.

    Some browsers break when this happens:

    * Firefox: works!

    * Chrome: breaks :(

    * Safari: breaks :(

    * MobileSafari: breaks :(

    There’s already an issue in the code.google.com/p/chromium tracker for this bug. Apple doesn’t have a publicly available tracker, so I haven’t reported it to them.

Comments are closed for this article.