746005 - Replace automatic caching of audio/video streams by nsHttpChannel with smarter media-specific disk caching logic

Status: RESOLVED INACTIVE

(Core :: Audio/Video: Playback, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #725993 +++

(In reply to Brian Smith (:bsmith) from comment #31)
> (In reply to Jason Duell (:jduell) from comment #24)
> > MediaCache: no longer caches files >50MB.  This is probably ok (though I
> > think a better solution eventually is to have either a separate cache for
> > large files (so small ones don't get squeezed out), and/or an algorithm that
> > evicts large files earlier).
> 
> Probably, for very large entries that we know are audio/video, we should
> MAYBE try to cache individual chunks--e.g. the first 1 minute, the
> most-recently-played minute, and the next 2 minutes instead of caching the
> whole thing. That would require higher-level smarts. I don't think anybody's
> expecting their giant YouTube videos to play offline, but it would be cool
> to get them to start/resume playing without having to hit the network.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #34)
> (In reply to Jason Duell (:jduell) from comment #32)
> > > for very large entries that we know are audio/video, we should MAYBE try to 
> > > cache individual chunks--e.g. the first 1 minute, the most-recently-played 
> > > minute, and the next 2 minutes instead of caching the whole thing.
> > 
> > Nice idea--open a bug for it and cc roc?
> 
> nsMediaCache already does something similar. It caches a window of data
> around the current play point of each media resource. Its policy is to cache
> up to the cache size limit (currently 500MB on desktop), and to equalize the
> amount of cached time before and after the current play point of all media
> resources.
> 
> We can change that policy, of course.

The idea of this bug is that we stop wasting as much disk space storing huge videos and audio files, by caching portions of the audio/video data to disk in a way that is similar to the way the media cache currently caches them in memory. Videos are huge and can easily eat the entire disk cache if cached naively using regular HTTP "cache the whole response" semantics. Really, we probably only need to cache the first minute or so of video (to give a nice buffer for replay) of the most recent N videos, where N is a small number.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Do we have an API to determine when an HTTP load is returning a resource that is the same as a resource we previously loaded? I.e. some sort of cache validation API?

Comment 2

[Masatoshi Kimura [:emk]]

I'm using nsICachingChannel::IsFromCache for XHR blob response. An obvious problem is that it is useless if necko do not cache the data :)

Comment 3

[Nils Ohlmeier [:drno]]

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