Bug 25267 - Autobuffer on <audio /> and <video /> cannot be disabled
: Autobuffer on <audio /> and <video /> cannot be disabled
Status: RESOLVED WONTFIX
: WebKit
HTML DOM
: 528+ (Nightly build)
: Macintosh Mac OS X 10.5
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-04-17 08:22 PST by
Modified: 2010-03-21 10:22 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-04-17 08:22:43 PST
Scenario:
I have a podcast, and an archive page that provides for a user to listen to many podcast entries (let's say a dozen). Each one has an associated audio player using the HTML5 <audio /> tag. It is likely that a user who visits this page will only listen to a small fraction of the available audio files (or none at all).

Result:
Using WebKit, upon first navigating to the page, the complete data for all 12 audio files is downloaded before the user interacts with them at all. Our bandwidth use would go through the roof, and the user may not appreciate it either (maybe they're on Comcast).

Cause:
HTML5 indicates this element has an 'autobuffer' attribute, but only defines behaviour when it is present or 'true'. Apparently, it is not possible in HTML5 to indicate that a boolean attribute should be false except by its absence. Neither omitting the attribute nor setting it to 'false' has the desired result of preventing automatic downloading.

Indeed, the spec does indicate '[t]his attribute may be ignored altogether', but as WebKit is the leading implementor of HTML5 so far, I would be comfortable trusting its implementation for now.

Change needed:
Only autobuffer an audio element when the autobuffer attribute is specified and/or true. Alternatively, provide some other way to disable the autobuffer behaviour.

Workaround 1:
Initially load a temporary element that instructs the user to 'click to begin playing', and use JavaScript to replace it with an <audio /> tag once they do. This breaks when JS is not enabled, and also is not instantly recognisable to the user as their browser's native audio player.

Workaround 2:
Use an Adobe Flash widget. This is a leading cause of unhappiness amongst standards-compliant web devs.
------- Comment #1 From 2009-04-17 13:00:38 PST -------
Another option is to use a <video> element with a 'poster' attribute. This will cause WebKit (and anyone that implements the media element spec correctly) to only load the poster image until the user clicks on the element.
------- Comment #2 From 2009-07-08 17:39:20 PST -------
Currently this bug is the only thing stopping me from implementing the AUDIO element on the site, http://huffduffer.com/

If there were some way of explicitly disabling autobuffer, that would be fine ...but because it's a Boolean attribute, the only way to disable it is not to use the attribute.[1] WebKit seems to be interpreting the lack of an autobuffer attribute as an implicit request for autobuffering when the opposite should be the case.

The indication in the HTML 5 spec that "this attribute may be ignored altogether"[2] means that an explicit request for autobuffering may be ignored. It does not mean that autobuffering should be enabled by default.

Disabling autobuffering by default, as well as being the behaviour indicated in the spec, is also the safest default behaviour for users' bandwidth.

[1] http://dev.w3.org/html5/spec/Overview.html#boolean-attribute
[2] http://dev.w3.org/html5/spec/Overview.html#attr-media-autobuffer
------- Comment #3 From 2009-12-12 08:55:08 PST -------
The VIDEO element suffers from the same autobuffer-impossibility problem. Even with the attribute absent Webkit immediately starts loading the video file.
------- Comment #4 From 2009-12-12 12:23:05 PST -------
In the Mac and Windows version of WebKit, QuickTime downloads media data. It is not currently possible to control QuickTime's download behavior - <rdar://problem/7171445>
------- Comment #5 From 2009-12-21 11:29:56 PST -------
According to John Gruber, WebKit will autobuffer the video even if a poster frame is used (http://daringfireball.net/2009/12/html5_video_unusable)

I have not independently verified this.
------- Comment #6 From 2009-12-21 12:18:35 PST -------
(In reply to comment #5)
> According to John Gruber, WebKit will autobuffer the video even if a poster
> frame is used (http://daringfireball.net/2009/12/html5_video_unusable)
> 
> I have not independently verified this.

I threw together <http://bdash.net.nz/files/video-with-poster-image.html>, which shows quite clearly that WebKit will auto-buffer the video even when a poster frame is specified.
------- Comment #7 From 2009-12-21 12:25:46 PST -------
(In reply to comment #6)
> I threw together <http://bdash.net.nz/files/video-with-poster-image.html>,
> which shows quite clearly that WebKit will auto-buffer the video even when a
> poster frame is specified.

I filed bug 32835 about this since it’s not exactly the same issue as this bug talks about.
------- Comment #8 From 2009-12-21 12:46:51 PST -------
My comment in about using the poster above is no longer correct. The spec now says that the poster should be displayed only "When no video data is available". The presence of the 'poster' attribute does not change the loading behavior, so if an element has both 'src' and a 'poster' attributes, the poster is only shown until the first frame of video data is available.
------- Comment #9 From 2009-12-21 15:31:04 PST -------
(In reply to comment #8)
> My comment in about using the poster above is no longer correct. The spec now
> says that the poster should be displayed only "When no video data is
> available". The presence of the 'poster' attribute does not change the loading
> behavior, so if an element has both 'src' and a 'poster' attributes, the poster
> is only shown until the first frame of video data is available.

It seems like if there is a poster attribute present, we don't even need to tell QuickTime to start the load until the first time the video starts playing (or autobuffer is present), so at least in that case, we could work around our limited control of its loading.
------- Comment #10 From 2009-12-22 05:03:27 PST -------
Would it make sense to load the media in WebCore with a SubresourceLoader instead of passing the URL directly to the MediaPlayerPrivate? That way we could abstract the loading for all ports, fix the autobuffering in one place, the loading would show up in the inspector, etc?
------- Comment #11 From 2009-12-22 08:14:44 PST -------
Firefox doesn't autobuffer by default: http://hacks.mozilla.org/2009/12/autobuffering-video-in-firefox/
------- Comment #12 From 2009-12-22 10:22:13 PST -------
(In reply to comment #10)
> Would it make sense to load the media in WebCore with a SubresourceLoader
> instead of passing the URL directly to the MediaPlayerPrivate? That way we
> could abstract the loading for all ports, fix the autobuffering in one place,
> the loading would show up in the inspector, etc?

Sure, we could do that for some media players. But for the QuickTime back end this may require API that does not currently exist.
------- Comment #13 From 2009-12-22 14:25:11 PST -------
(In reply to comment #10)
> Would it make sense to load the media in WebCore with a SubresourceLoader
> instead of passing the URL directly to the MediaPlayerPrivate? That way we
> could abstract the loading for all ports, fix the autobuffering in one place,
> the loading would show up in the inspector, etc?

We do eventually want to do that. Media engines tend to have unusual demands, such as loading only parts of resources using range requests. It also may not be desirable to hold onto all data loaded so far. So we'd have to add some features to the WebCore loader layer.

In the case of QuickTime in particular it could be particularly tricky to find a way to have WebKit drive the load instead of QuickTime.
------- Comment #14 From 2009-12-22 21:59:32 PST -------
(In reply to comment #13)
> 
> We do eventually want to do that. Media engines tend to have unusual demands,
> such as loading only parts of resources using range requests. It also may not
> be desirable to hold onto all data loaded so far. So we'd have to add some
> features to the WebCore loader layer.

  We will *definitely* not want to keep all of the data loaded in memory. We may be able to use the work the Chromium port has done to make the WebCore loader to use a sparse disk cache for media data. I don't think they have modified the loader to support files larger than 2GB, but this is also a real requirement (think HD movies on a local, eg. home, network).

> In the case of QuickTime in particular it could be particularly tricky to find
> a way to have WebKit drive the load instead of QuickTime.

  One of the tricky parts will be continuing to support HTTP Live Streaming, http://tools.ietf.org/html/draft-pantos-http-live-streaming-02.
------- Comment #15 From 2010-03-21 10:22:36 PST -------
https://bugs.webkit.org/show_bug.cgi?id=35385 replaced the 'autobuffer' attribute with 'preload'. 'preload=none' tells the UA that the best user experience will be to not load any media data initially, so the "change needed" in described in this bug should no longer be necessary.