25267 2009-04-17 08:22:43 -0700 Autobuffer on <audio /> and <video /> cannot be disabled 2010-03-21 10:22:36 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Mac OS X 10.5 RESOLVED WONTFIX P2 Normal --- 1 bugs eric.carlson adrian+applebugzilla ayg beidson bugs bugzilla darin dror emacemac7 eric.carlson farukates jeff jeremy Justin jwalden+bwo matthew mjs ml simon.fraser vestbo oldest_to_newest 117913 0 bugs 2009-04-17 08:22:43 -0700 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. 117959 1 eric.carlson 2009-04-17 13:00:38 -0700 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. 130584 2 jeremy 2009-07-08 17:39:20 -0700 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 171102 3 farukates 2009-12-12 08:55:08 -0800 The VIDEO element suffers from the same autobuffer-impossibility problem. Even with the attribute absent Webkit immediately starts loading the video file. 171115 4 eric.carlson 2009-12-12 12:23:05 -0800 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> 174020 5 beidson 2009-12-21 11:29:56 -0800 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. 174036 6 mrowe 2009-12-21 12:18:35 -0800 (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. 174040 7 mrowe 2009-12-21 12:25:46 -0800 (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. 174044 8 eric.carlson 2009-12-21 12:46:51 -0800 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. 174119 9 mjs 2009-12-21 15:31:04 -0800 (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. 174249 10 vestbo 2009-12-22 05:03:27 -0800 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? 174272 11 simon.fraser 2009-12-22 08:14:44 -0800 Firefox doesn't autobuffer by default: http://hacks.mozilla.org/2009/12/autobuffering-video-in-firefox/ 174288 12 darin 2009-12-22 10:22:13 -0800 (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. 174396 13 mjs 2009-12-22 14:25:11 -0800 (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. 174526 14 eric.carlson 2009-12-22 21:59:32 -0800 (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. 202292 15 eric.carlson 2010-03-21 10:22:36 -0700 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.