MediaCache can use lots of disk space for every content process
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
People
(Reporter: konomikitten, Unassigned)
References
()
Details
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Comment 3•6 years ago
|
||
Konomi: You could try opening about config and change media.cache_size to a much smaller value; say drop a zero off the value. That should reduce the amount of data Firefox stores on disk, and make things better for you.
(In reply to Andreas Pehrson [:pehrsons] from comment #1)
Chris, is this the workings of the MediaCache, or possibly something else?
The media cache was written at a time when Firefox had only one process, so every process just creates a new one as needed. So in multi-process Firefox we end up with one media cache per content process. Each content process' cache can be up to 512MB in size. Data from active media elements in a content process is stored in the process' cache, and purged when the media element is shutdown.
So if someone ends up with a bunch of different tabs in different content process; which all start downloading large media files, we could potentially end up caching a lot of data in /tmp, potentially way more than 512mb.
I don't imagine the configuration with such a small(!) tmp storage would be common, but that's an untested assumption.
In the multi-e10s world, this gets worse. It would be interesting to collect telemetry to try to quantify how much of a problem this will be.
Comment 4•6 years ago
|
||
Thanks for the explanation.
It doesn't sound too bad given that the cache is purged on media element shutdown. I don't see it as very common to keep multiple tabs around with finished-but-not-yet-shutdown media elements in them. Still, I'm marking this confirmed and P3 for the sake of adding telemetry.
Comment 5•6 years ago
|
||
(In reply to Chris Pearce [:cpearce (GMT+13)] from comment #3)
Data from active media elements in a content process is stored in the process' cache, and purged when the media element is shutdown.
So if someone ends up with a bunch of different tabs in different content process; which all start downloading large media files, we could potentially end up caching a lot of data in /tmp, potentially way more than 512mb.
Thanks, Christopher, but what should be done to the settings to deal with kind of an opposite issue?
Sometimes sites like Reddit are so slow in terms of delivering their videos that it can take forever to load them even though the video itself is small (like here it is just two and a half minutes: https://www.reddit.com/r/PewdiepieSubmissions/comments/amvsf2/i_remade_bitch_lasagna_in_fortnite_using_the_new/)?
The goal is to make FF to load the whole video into the cache -- however slowly it might happen -- while user is doing something else in other tabs. Then the user should be able to see the whole video.
As it is now HTML5 video playback only works by loading small "blobs" and then stops requesting new data until the nearest few seconds are played by the viewer. And, what is even worse, it quickly purges all of the previous data that was already played back so there is no way for users to eventually see the video in its entirety in a continuous playback once it will finally load up to its very last second.
What settings in "about:config" can be changed to force FireFox to keep small videos fully cached (maybe up to certain size limit)? Better yet, FF should see that he video is loaded very slowly so it can adjust the caching rules for both forwards (to never stop loading more until the end of video is reached) and backwards (to not clear it) on the fly. For that, the byte-stamps that define the blob batches via "m3u8" file for videos should be ingored.
Otherwise to watch the slow Reddit videos I have to do this:
-
use Web Inspector on the video tag element to find the source for the video tag, which "HLSPlaylist.m3u8",
-
download it, find in it a name of files with the settings list with the best bitrate/resolution version of the video: "HLS_540_v4.m3u8" (yes, Reddit is this bad, this is the best resolution it can do; this is the file which FF would eventually use as a guideline about caching, and it is a disaster; it should be overruled if some setting is activated) and "HLS_AUDIO_160_K_v4.m3u8" for audio,
-
download them, and find the name of the actual video and audio files for the chosen resolution: "HLS540.ts" and "HLS_AUDIO_160_K.ts"
-
download them, and concat/joinmux them with tsMuxeR_2.6.12 utility.
The whole process it takes time, but is the entire video and it can be watched it continusouly and smoothly from the very beginning to its end without interruptions and endlessly waiting for when/if the next part of the "blob" will be loaded.
Thank you in advance.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•2 years ago
|
Description
•