Philip Langdale
Philip Langdale
It's basically just fossilize itself. Here is the state of affairs just before I run out of 64GB on my system: 
FWIW, when all is said and done, my on disk cache size for SotTR is 1.3GB.
This is an Ubuntu system with the standard deb bootstrap package that is then downloading and running the client. No flatpak cleverness or anything like that. I have not tried...
Just for fun, I added 128GB of swap and it was still happy to OOM.
Latest update. With a 6.0.x kernel, the OOM killer no longer kicks in. I still experience multiple seconds of system unresponsiveness when memory is exhausted but the fossilize processes do...
addExclusion is generated code in core maven. That’s also why Exclusions don’t have an equals() implementation. I’d add a test case if I could come up with a repro case...
Note, that the fix in #15 looks like the fix for why exclusions get reevaluated. Even if that is merged, this fix should be taken too for correctness.
I tried it out on a pixel 6 which can actually do 10bit hwdec for hevc and vp9 with HDR (maybe it can do av1 too but ffmpeg doesn't have...
Why would you wan to encode with mpv rather than `ffmpeg`? You're also pointlessly trying to download the frames to system memory instead of passing them directly from the decoder...
Added a second change that gets rid of the "shit list" in hwtransfer, which was hard-coding supported formats in vaapi. It's not required anymore.