views:

68

answers:

1

I'm working out details on a web application which involves the sequential loading of a long series of (very short) video clips, one after the other, with occasional input from the user establishing new directions for which video clips to load.

I would like to be able to have the browser preload the video clips five at a time. However, the way that we currently have the site working is by means of a single video element which is having its src attribute continually updated through JavaScript.

So, my question is, is there a straightforward way I can get the browser to preload multiple video clips even though I am ultimately loading them all (one at a time) into the same video element?

This is my first question here, so let me know if I could have phrased that better...

+1  A: 

You can preload images in browsers by creating an <img> tag in JavaScript, and setting its src attribute. Although it’s not required by any spec, all browsers then download the image and cache it (assuming their caches haven’t been disabled).

I’ve no idea if that works with the <video> element in HTML5, but it might do. Could you give it a go?

Paul D. Waite
I have tried something similar, but my problem is that the page is designed to only have one <video> element, whose src gets changed each time a clip reaches its end. I can create multiple <video> tags with JavaScript and use them to preload a series of clips, but when the script to change the src attribute of the main <video> element gets called, the page does not use the clips it has preloaded for the other video elements, even though the src value is the same, rather it seems to fetch the clips again. So, it just ends up being redundant.
Sergio1132
I should explain that the video element in question is basically the entire page. I guess I need a way to tell the browser to grab a set of files and cache them until it is time to load them into the video element one at a time. And I need it to happen in JavaScript because the needed files change based on user input.
Sergio1132
@Sergio1132: ah, so the browser doesn’t seem to be caching the video files. In that case, I think you’ll have to change your approach — create additional `<video>` elements, and then swap them in, instead of using just one `<video>` element.
Paul D. Waite
Thanks, I ended up doing something along these lines. I'm using multiple hidden <video> elements with a <canvas> element. The <video> frames get drawn to the <canvas> and when the clip is over the script simply changes which <video> element is getting drawn to the canvas.
Sergio1132
@Sergio1132: ah, good stuff. Out of interest, what’s the advantage of having a `<canvas>` element involved as opposed to just showing and hiding the `<video`> elements via CSS?
Paul D. Waite
@Paul D. Waite: Well, for switching between the videos I don't think there is an advantage, but the site will have a minimal text interface that is laid over the video and I thought having the whole thing be a `<canvas>` element might make it possible to do some interesting things. Right now we are just using css positioning to lay the interface over the video, but I was thinking that if we draw the interface onto the canvas along with the video then it opens up the possibility of having the interface subtly interact with the video underneath it, using various `<canvas>` methods.
Sergio1132
@Paul D. Waite: I'm still testing to see how it performs, and if there is an apparent performance issue with the `<canvas>` intermediary then we will probably just show and hide the `<video>` elements via CSS, as you say.
Sergio1132
@Sergio1132: ah yes I see, neato. Well worth some experimenting.
Paul D. Waite