Method to stop HTML5 audio/video from preloading?

[Makosuke]

Working on a language lesson that has a bunch of audio clips in it. I'd been using a QuickTime-based method of inserting the audio clips in the page to date, but figured this was a perfect job for HTML5 audio, with the added bonus of making iPhones and iPads happy.

Problem: I don't want to preload the audio. Aside from chewing up bandwidth and slowing the browser unnecessarily if the person isn't interested in playing the sound clips, it REALLY slows down loading of the page as Safari tries to prep and preload two dozen short audio files simultaneously.

Bigger problem: You SHOULD be able to just set preload="none" ... but currently Safari and Chrome completely ignore that property and preload anyway. Eventually this won't be a problem (I hope), but right now it is.

Potential solution: The famed Gruber of Daring Fireball had the suggestion of just using a bit of Javascript to have a link (he used a poster image, I just want a text link since it's audio) that, when clicked, replaces itself with the appropriate <video> or <audio> element. Bingo, no preload until user action:

http://daringfireball.net/misc/2009/12/user_guide_demos

Tragic flaw: His solution uses JQuery, which I am already using, so that was quite convienent. Except there's some sort of bug in either Firefox or JQuery that, when you do exactly this, you get TWO copies of the video (or audio) file playing at the same time (at least as of FF 3.6.3). Try it on the DF link above, or the example linked from this question:
http://stackoverflow.com/questions/...-playing-duplicate-videos-after-jquery-insert

...both work perfectly with Safari, but in Firefox you'll hear a weird echo and if you pause the video the second invisible copy will continue playing. Does the same with audio:

http://tinderbox.animeworld.com/japanese/lesson1-1.html


Question: Anybody have either a workaround for this JQuery/FF issue or a better suggestion for keeping <audio> from preloading?

 

[Macman1993]

In your video or audio tags use autobuffer=false


More info on html5 video and audio
http://developer.apple.com/safari/l...s.html#//apple_ref/doc/uid/TP40009523-CH2-SW4

 

[Makosuke]

if you mean set autobuffer=false to stop Safari from preloading, that doesn't work. To quote the document you linked:

Important: Several of the attributes are boolean. Although they can be set to false using JavaScript, any use of them in the HTML tag sets them to true. Controls="controls", for example, is the same as controls=true or simply controls. Even controls=false sets controls to true in HTML. To set these attributes to false in HTML, omit them from the tag.

Firefox DOES respect the lack of an autobuffer element, if one doesn't exist:
http://hacks.mozilla.org/2009/12/autobuffering-video-in-firefox/

..but Safari does not. There was a bug explicitly filed under this and marked "wontfix":
https://bugs.webkit.org/show_bug.cgi?id=25267

...because they're adding support for the preload attribute:
https://bugs.webkit.org/show_bug.cgi?id=35385

Here's a test page with embedded video and all three settings combinations (important: While the video content is the same because I'm lazy, they're three separate files, so one buffering doesn't affect the others):
http://steelbluepanic.com/html5testcase/

Safari current release preloads all three. FF3.6.3 does NOT preload the one with only "preload="false" but DOES preload the other two (which is to say it currently ignores preload entirely, but if it sees NO autobuffer attribute at all, it won't autobuffer, as stated in the blog post above). Webkit Nightly from today also preloads all three, which is weird because it seems to disagree with the bug link above.


Any other suggestions? I should note that I actually sort of prefer the uncluttered look of the Javascript replace version, it's just that it's broken on account of that FF bug. Wonder if it's FF or JQuery that's the problem...

 

[Makosuke]

Addendum: A bit of testing with a very simple javascript insert, which doesn't play double audio in FF. So it does appear that the problem is with JQuery, or at least the method JQuery is using to do the replacement. Time to file a bug report and/or roll my own script, I guess.