At http://simon.html5.org/test/html/semantics/video/002.htm I never saw the videos loading at same time even though both are same video. This is true even after we started caching video. Except, now things happens little more faster from second visit. So we can we reuse cache and buffer if they are from same URL This will allow to cache short videos in background and then display it when needed, just like we use to cache images for showing roll over effect. Also it save band width and resources Test 1. go to cache_and_buffer.html Result: user see events fired at different time for each video Expected: user see events fired at same time on both videos

Note that animated images have this behavior and we generally consider that a bug... Synchronizing videos related by nothing but the url is really weird.

The spec does not in any way guarantee that two <video> elements will be synchronised. If you want synchronised multimedia, use something like SMIL.

We should rename this bug to "Reuse cache and buffer across page views and identical resources" This updates the bug to reflect the fact that the cache does not "cache" across page views. Which is a very similar to the problem of having identical video resources not share a cache. In essence video should work "as similar" to images as possible when it comes to caching.

Making this work would require some redesign of the media cache, but more importantly would require interaction with Necko caching. We'd need something similar for a good font cache too. Basically we need Necko to give us some kind of token whenever we *start* a load, with the promise that if it gives us the same token for two loads, those loads are guaranteed (via caching semantics) to return the same data. Then internally we can maintain a map of tokens to cached video stream blocks, or cached platform font objects, etc. Does that sound like a reasonable API? Or does it already exist? Or is there another way to do this? I'm not entirely sure what the behaviour of nsICachingChannel::cacheToken and nsICachingChannel::cacheKey are.

One issue with getting a token when starting a load is that the current necko cache has the following limitations: 1) Can't have a consumer reading a cache entry while it's being written by some other consumer. 2) Can't have multiple consumers opening a cache entry in write mode. So nsHttpChannel's start opens the cache entry... if no one else is using it right now, it's opened read-write. If someone else is something happens (not sure what, to be honest; I'd have to trace the code). If there's no entry, it's opened write-only. If multiple channels race on the entry, fun stuff happens (some of them don't get to use the cache, basically). cacheKey guarantees that any two loads with the same URI and the same cacheToken will get the same cache entry. It's fundamentally only useful for LOAD_FROM_CACHE loads in some ways, because it does NOT guarantee anything about what will happen if there is no cache entry or if the cache entry can't be used (e.g. has expired, etc). For example, for HTTP GET requests the cacheKey is a no-op; the URI completely determines the load behavior via the usual cache semantics. cacheToken, for HTTP, is basically a pointer to the nsICacheEntry the channel is using. If two channels have the same cache token, then, assuming they're reading from cache, they'll get the same data. I'm not sure what cacheToken tells you about _whether_ the channel is reading from cache... dcamp, do you know the answer to this?

I don't actually care if the loads are using the same cache entry or not. All I care about is whether the URIs are the same and we are allowed to reuse the data from one load for another load according to HTTP caching semantics. All I'm going to do is cancel the second load and reuse the object I constructed that represents the result of the first load. So it seems neither cacheToken nor cacheKey is what we want here.

Yeah, I don't think necko hands out the information you want at the moment...

On roc's blog post about mozLoadFrom, Hixie notes: "Per the HTML5 spec, just creating a new and doing newvideo.src = firstvideo.currentSrc; should have the same effect. (Well, may have. Implementations aren't _required_ to use the same streams, but they're allowed to.)" Roc: "Hmm, indeed. I didn't know that section 2.6 lets us ignore HTTP caching semantics for cases like this. Great!"

Mass closing do to inactivity. Feel free to re-open if still needed.