Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 85 users
Status: Fixed
Email to this user bounced
Closed: Apr 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Feature

Blocked on:
issue 76555

  • Only users with EditIssue permission may comment.

Sign in to add a comment
<video preload> not respected (was autobuffer)
Reported by, Jul 10 2009 Back to list
Chrome Version       : (Developer Build 20045)
URLs (if applicable) : http://kir-fbarchard-
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: ok?
  Firefox 3.x: not sure
         IE 7: n/a
         IE 8: n/a

What steps will reproduce the problem?
1. start a video.

What is the expected result?
with autobuffer is should start in 26 ms.

What happens instead?
without autobuffer it should take 200 ms or more.

Please provide any additional information below. Attach a screenshot if
Jeremy Doig asked for latency to be reduced.
Comment 1 by, Jul 10 2009
Labels: video
Labels: -Area-Misc Area-BrowserBackend
Status: Assigned
hclam, can you trick the readahead with a fake read (zero bytes?) to get it started?

Labels: -video Video Mstone-3 Size-Medium
Comment 4 by, Jul 24 2009
Labels: -Pri-2 Pri-3
Comment 5 by, Jul 29 2009
Labels: -Pri-3 Pri-3Theautobufferattributeprovidesahintthattheauthorexpectsthatdownloadingtheentireresourceoptimisticallywillbeworthitevenintheabsenceoftheautoplayattribute.Intheabsenceofeitherattributetheuseragentislikelytofindthatwaitinguntiltheuserstartsplaybackbeforedownloadinganyfurthercontentleadstoamoreefficientuseofthenetworkresources.
This bug is blocked on 12258. Without proper caching on disk it is not possible to 
fetch the whole media file and keep it around. Note that even if we have caching of 
such, partial content of the media file can be evicted. Here's a description of the 
autobuffer attribute from the HTML5 spec:

The autobuffer attribute provides a hint that the author expects that downloading the 
entire resource optimistically will be worth it, even in the absence of the autoplay 
attribute. In the absence of either attribute, the user agent is likely to find that 
waiting until the user starts playback before downloading any further content leads 
to a more efficient use of the network resources.

So it's more like a hint than an absolute command we need to respect. And already our 
current fetching logic is pretty ambitious that once we are called to load a file we 
fill up the memory buffer until we pause the connection. We do not wait for play to 
actually start prefetching the media resource.
Comment 6 by, Jul 29 2009
Labels: -Pri-3Theautobufferattributeprovidesahintthattheauthorexpectsthatdownloadingtheentireresourceoptimisticallywillbeworthitevenintheabsenceoftheautoplayattribute.Intheabsenceofeitherattributetheuseragentislikelytofindthatwaitinguntiltheuserstartsplaybackbeforedownloadinganyfurthercontentleadstoamoreefficientuseofthenetworkresources. Pri-3
Comment 7 by, Jul 29 2009
Blockedon: 12258
Labels: -Mstone-3 Mstone-4
Labels: HTML5
Labels: -Size-Medium
Given how much our internal structures have changed, is this still an issue?
Blockedon: -12258
Labels: -Type-Bug -Mstone-4 Type-Feature Mstone-X
Our current implementation fetches a good chunk of data regardless of autobuffer.

Sparse caching or not, we might evict part of the data anyway so it's hard for us to 
ever respect autobuffer.
No need fixing, this is optional in the spec... we can choose to not support it and
I'm fine with it being delayed indefinitely.
The reason I suggested this feature be implemented, is our startup latency is too high, 
and this seems like the easiest way to fix it for videos that dont autostart.

The implementation would not buffer the entire file... just start to top up the 
readahead, so that when play is pressed, some bytes are buffered and the video can 
start immediately.  The readahead stops buffering when it is full, so it wouldnt cause 

autobuffer means buffering the whole file if possible, according to the spec.

Read ahead buffer is already implemented, that means the first thing it does when you 
load a file with javascript is fetch it and load the first part ~5MB into memory.
Not necessarily the whole file.  The spec says playback would benefit from buffering.
It is similar to "canplaythrough", which will buffer enough that the video can play 
without network stalls.
Comment 16 by, Dec 17 2009
Labels: -Area-BrowserBackend Area-Internals
Labels Update:

Replace Area-BrowserBackend by Area-Internals
Labels: Internals-Video
On John Gruber is irritated that 
there is seemingly no way to say "don't buffer anything until the user tries to play 
the video", meaning that his bandwidth costs go up for buffering people who never play 
anything.  It's not clear to me whether supporting "autobuffer" fixes this unless we 
choose to implement as "without autobuffer, buffer nothing".  Which may, in fact, be 
the right thing to do.
Chrome doesn't buffer until you press play... unless its autoplay
already sent him an email :)

fortunately we have a bandwidth conservative approach since we only download the
minimum required to play

that still doesn't address his requirements exactly, and my spec knowledge is rusty
but I believe the media resource load algorithm is activated during page load, which
implies we need to peek at the file in order to understand if we support it, which
implies that browsers will download some portion of the file :(
Do we support the "poster" attribute, and when it's used, avoid downloading anything, 
even to detect whether we support the video?  It seems like we should, and if the spec 
says we can't, then the spec should be changed.  (Warning, I haven't thought through 
this deeply.)
Gruber's criticism is targeted at the default buffering behavior of the video and audio 
tags in cases where autoplay and autobuffer are not used.

I still want to see autobuffer honored in cases where autoplay is not used. This is a 
useful distinction, as I want to support buffered play upon user selection, but would 
rarely want to autoplay.
Labels: -Video
Comment 24 by Deleted ...@, Jan 4 2010
All I want is for everything to work properly, without any snags or problems, I 
have enough problems as it is, without having more on my channel. I want the 
videos to play automatically, I want them to play well, I want everything perfect 
and without any flaws. Is that to much to ask ?
Well if you want to complain so much fix it yourself?
Comment 26 by Deleted ...@, Jan 4 2010
haha :P
Comment 27 by Deleted ...@, Jan 6 2010
Does this mean I have to fix this issue.
Well if someone can fix it then that would be useful!
patches are always welcome, but us chromium folk can look into the issue.

I'm wondering if this is a WebKit issue hmm...
Comment 30 Deleted
Comment 31 by, Jan 11 2010
Labels: -HTML5
Comment 32 Deleted
Comment 33 Deleted
Comment 34 by Deleted ...@, Jan 30 2010

at the bottom of my videos it says 

"Note, autobuffer/preload is ignored until  Issue 16482  is fixed"

When i click the link it brings me to this page. :S

any suggestions?

Thanks :)

ciaracorr38: could you provide a link or screenshot?  I don't think we've hardcoded 
that string anywhere inside Chromium.
Comment 36 by Deleted ...@, Feb 1 2010
@scherkus: it's an addon that converts youtube flash objects into html movies

or something like that
@scherkus: more precisely, it's on the "YouTube HTML5-ifier" Chrome Extension 
Ahh that explains it.  Thanks for the link!
Comment 39 Deleted
Comment 40 Deleted
Summary: <video preload> not respected (was autobuffer) (was: NULL)
autobuffer has been renamed preload

Comment 42 by, Jul 14 2010
 Issue 30994  has been merged into this issue.
Labels: -Internals-Video -Area-Internals Feature-Media Area-WebKit
Comment 44 by, Jul 29 2010
Reassigning this bug to vrk as she's working on this area now.
I don't know if I should create a separate issue for this, but I have a web app that shows a mosaic of possible videos. I was hoping that the preload='none' attribute would allow Chrome to not load the videos at all until the user tried to play one of them, but alas the attribute itself is being ignored. Will this issue's fix also allow preload='none' or preload='meta' to be obeyed?
Comment 46 by, Aug 12 2010
We are currently working on this bug. A proper fix will include doing preload='none' and preload='meta' correctly.

I think audio tag is affected as well by this problem, the preload="none" isn't honoured.

(I'm using the chromium daily ubuntu package)
Great to hear you guys are working on this as, its quite a big issue for us content providers, users browsing the site reading article really shouldn't sit their buffering the entire content of a large video they have no intention of playing, which is what currently happens.
Comment 49 by, Oct 5 2010
Confirmed comment 47 (@elthariel): this same bug occurs with the <audio> element. I have a page with about 20 <audio> elements for MP3 podcasts which all start to download whenever a user loads the page (and hence, freezes the browser). 
preload='none' (and preload='meta') are still not working in the latest Chrome release (v8). Any news on when you'll be able to fix this? 

It's a pretty serious issue.

We (SublimeVideo) are getting reports from users who have several <video> elements on the same page and  they are complaining about their site becoming completely unresponsive on Chrome. Basically all those videos preloading in the background can be quite heavy for the browser to handle, especially on older machines with limited resources. 
(and we're not even talking about the waste of bandwidth involved in those cases)

It'd be great if you could share any news about this. 

Btw, here is a nice test page showing that on Chrome the 'progress' event is fired (i.e. video preloading) despite the fact that the <video> element has the preload attribute set to 'none':

Comment 52 by, Dec 8 2010
I promise it is on my radar! :) I am actually secretly hoping to get this in for M10 as I am pretty sure this is easy to implement, but I need to look at the code again before I can say so definitively. I'll comment on this thread when I have updates!
that would be a nice Xmas present!
I already had mentioned this issue on the html5 announcement, when i was still thinking this was an problem, and after loosing 5 Gb.

that would be a nice Xmas present!
I already had mentioned this issue on the html5 announcement, when i was still thinking this was an problem, and after loosing 5 Gb.


I am disabling the layout test (media/video-preload.html) due to this issue. Please enable this test once this issue is fixed.
Comment 56 by Deleted ...@, Feb 4 2011
hey, this is STILL broken. any updates on this?
Comment 57 by Deleted ...@, Feb 4 2011
hey, this is STILL broken. any updates on this?
Comment 58 by, Feb 7 2011
 Issue 72520  has been merged into this issue.
 Issue 48777  has been merged into this issue.
Hi, any news or update on this issue?
vrk will try to take a look at preload=none
Comment 63 by, Mar 3 2011
I looked into this a few months ago and saw it wasn't totally trivial to implement, but I didn't follow up on the thread as I said I would. Sorry about that!

Looked into it again today, and here's the status: In our current buffering implementation, we try to buffer the entire file when a video is paused. So when a <video> is loaded but not yet playing, it is considered paused and the entire video tries to buffer. When a video is playing, we buffer up to 10 mb then "defer" resource loading until we've consumed half of that, or until we pause again. You can think of it sort of like, we have a Load-Everything option and a Load-10mb option, and currently no granularity in between.

To implement preload=none, ideally we'd like to not do any resource loading until a user explicitly asks to play() something. 

But prerolling makes this a somewhat tricky... When we have initialized all filters in our pipeline, we "preroll" the first four frames of the video. (This actually happens whenever we seek to a new location, not just at the start.) The act of prerolling essentially switches on resource loading, which will buffer 10+mb of video data. Right now prerolling is somewhat baked into our Pipeline state machine, so it's not a 1-2 line change to turn it off for preload=none. Still, it shouldn't be too hard to decouple it and make prerolling dependent on the preload value. I'll experiment with it.

@acolwell: maybe I can chat with you sometime tomorrow about ideas to make sure they don't cause unseen catastrophes for the pipeline?
Comment 64 by, Mar 3 2011
Chatted with acolwell!

So sounds like I will actually implement "preload=metadata" first; this will preroll but will not autobuffer the entire video. Should be an easier/faster change to make and should be what (I think) most folks will want.

When the preload attribute is not set, the spec suggests defaulting to metadata (though it's up to us). I will also change the default preload behavior to metadata as well. This is also what Firefox does:
vrk, thanks for taking a look at this.

Again, I think this is the single most important missing feature regarding the HTML5 video implementation in Chrome. I have just checked IE9 (released yesterday) and it correctly supports both preload=none and preload=metadata. So Chrome is currently the only HTML5 browser not supporting the preload attribute.

If you can start by implementing and releasing the support for preload=metadata it's already fine (much better than waiting to release something until both "metadata" and "none" are implemented). 

I can't stress enough the importance of this issue. With many <video> elements on the page the situation can get so bad that we have even considered making SublimeVideo fallback to flash on Chrome by default until this issue is fixed, which is clearly a very painful decision for us. We also tested several workarounds to avoid preloading (like resetting the video's src), but none of them work in a satisfactory manner and consistently across the different versions of Chrome (Windows, Mac, Linux).

Comment 66 by, Mar 16 2011
Labels: -Pri-3 -Mstone-X Pri-1 Mstone-12
Status: Started
I will try my best to get this fixed in the very near future. I already have a patch out for preload=metadata but was blocked on some other video pipeline changes. The changes that had been blocking me have now landed and I will update my preload=metadata patch today, so barring explosions this should land very soon.
(For the curious:

preload=none is a bit trickier but I will work on it today/tomorrow; optimistic for a patch soon.

Upping Pri and putting a date on this!

Thanks for the news Victoria

Please keep up the work on this!


Comment 68 by, Mar 17 2011
Blockedon: 76555
Ahh, looks like some of the pipeline refactoring has broken communication from pipeline->filters. Will talk to @acolwell today about it.
Comment 69 by, Mar 24 2011
Sorry, had a bit of delay with some other stuff! 

Status update: preload=metadata Chromium and WebKit patches up for review.

I looked more into preload=none today and it's still a pain. Short version is this:
- We need to load data to initialize FFmpegDemuxer (av_open_input_file will trigger a read, which will start resource loading).
- We need to initialize FFmpegDemuxer to initialize our pipeline
- We need to initialize the media pipeline as a response to load() requests from HTMLMediaElement
- If we don't initialize the media pipeline, we don't get HTMLMediaElement in a state that allows playback, so we can never play videos

Anyway it is tricky, I need to look at it more... will hopefully make some progress tomorrow.
Comment 70 by, Mar 24 2011

Turns out I was going about preload=none the wrong way; Eric has shown me the light and it was waaaaay easier to implement than I thought. Patch now out in WebKit:
Project Member Comment 71 by, Apr 5 2011
The following revision refers to this bug:

r80465 | | Tue Apr 05 09:28:20 PDT 2011

Changed paths:

Implementing preload=metadata for video

This patch implements the logic necessary to respect the preload attribute
when it is set to MetaData.  This also refactors the BufferedResourceLoader
to determine its buffering techniques based on a DeferStrategy value.

BUG= 16482 , 76555 
TEST=media/video-preload.html, test_shell_tests

Review URL:
Comment 72 by, Apr 5 2011
Status: Fixed
The patches to implement preload have now landed! The preload attribute will be finally recognized in Chrome 12. (Dev channel should get this update in a few weeks.)
Project Member Comment 73 by, Oct 13 2012
Blockedon: -chromium:76555 chromium:76555
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 74 by, Mar 10 2013
Labels: -Mstone-12 -Feature-Media -Area-WebKit Cr-Content Cr-Internals-Media M-12
Project Member Comment 75 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 76 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment