736339 - Don't use Necko disk cache for media streams' nsHttpChannels

Status: RESOLVED WONTFIX

(Core :: Audio/Video, defect)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

In bug 725993 I discovered that Necko is caching data that we're caching anyway in the nsMediaCache, and flushing that cache in our nsHttpChannel::OnDataAvailable listener, which can block the main thread when the system is performing a lot of heavy IO. See bug 725993 comment 12 for STR and stack trace.

We don't need to cache media data twice surely. We can use the nsIRequest::INHIBIT_CACHING load flag to ensure that we're not relying on the Necko cache.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

Hmmm, except Chris Double pointed out we had a rash of bugs filed by people complaining when we *didn't* cache stuff in the Necko cache. I guess the problem is the media cache isn't persistent, whereas the Necko cache is. We should probably just wait for our friends in the Necko team to fix bug 725993, and continue as normal until then.

Comment 2

[Jason Duell]

Well, I think it's an open question as to whether we should cache media stuff between sessions, especially large files like video.  It may really lower our overall disk cache hit rate by evicting lots of stuff.  It seems that Chromium is not using the regular HTTP cache for their media files (though it's not clear from this whether their media cache persists across sessions):

  https://plus.google.com/103382935642834907366/posts/XRekvZgdnBb

   "Remember that Chromium uses a different cache for normal resources and media (audio/video) resources.."