[Webkit-unassigned] [Bug 235535] New: Network Cache: do not use disk cache for Fetch media loads

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jan 24 12:39:39 PST 2022


https://bugs.webkit.org/show_bug.cgi?id=235535

            Bug ID: 235535
           Summary: Network Cache: do not use disk cache for Fetch media
                    loads
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: olivier.blin at softathome.com
                CC: cdumez at apple.com, darin at apple.com, eocanha at igalia.com,
                    jer.noble at apple.com, koivisto at iki.fi,
                    loic.yhuel at softathome.com, mcatanzaro at gnome.org,
                    pnormand at igalia.com, zdobersek at igalia.com

In r183467, checks have been added to avoid putting media resources from XHR requests in the disk cache, since they are likely specific to MSE streaming.
But this does not check for Fetch requests, which can also be used for MSE streaming.

This has been found by using Shaka Player on a low-end device.
Playing high quality MSE content was pushing to the disk cache faster than the device could handle.
Media data was accumulating in the the background IOQueue thread, and the NetworkProcess memory was constantly increasing.

Recently, similar checks have been added for the MSE IPC overhead in r282003.
Loïc found a few differences:
- it supports ResourceLoadInfo::Type::XMLHTTPRequest and ResourceLoadInfo::Type::Fetch, but not ResourceLoadInfo::Type::Media
- it has a different definition of isMediaMIMEType, which adds application/octet-stream to the audio/* and video/* we have in makeStoreDecision()

Should we attempt to factorize these checks?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220124/2feaf69b/attachment.htm>


More information about the webkit-unassigned mailing list