Server Version#: unknown
Player Version#: 1.48.2.3124-647ff031
I haven’t tested the newest version yet but I haven’t noticed any announcements relating to this issue.
I often use videos playing on Plex as a background. Since like 3 months ago I noticed that Plex after playing for couple hours starts using substantial amounts of VRAM.
Today it was using a bit over 3GB before closing.
I looked at logs and found nothing that could be of use.
OS: Windows 10 Version 2009 [10.0.19043] x86_64
GPU: NVIDIA GTX 1080
GPU Drivers: 516.59
Hardware Decoding at Normal Quality, Rate Switching disabled
This was also present in Plex HTPC but has been fixed there. I thought it was also fixed in the Desktop Player.
Are you running the latest version? (The video shown above shows version 1.44)
That’s not what your screen recording shows; it shows a considerably older version. We fixed this in the MPV that we ship (both in HTPC and Plex for Windows) a couple of months ago so you should update your version.
That line was on 1.48.2.3124-647ff031. The video showed the biggest leak I experienced.
Today I made a test on 1.49.1.3146-73559c78:
The test consisted of playing 8 Full HD 25 minute episodes (closing after like 10 seconds of watching) and then watching a 4k movie for 5 minutes. At a peak it was using close to 4GB of VRAM before closing the movie.
Also worth to mention is that with the same 4k content, Plex on Edge browser uses around 500MB of VRAM (with hardware decoding) meanwhile Plex for Windows is using around 1.2GB.
Do you want me to test a specific version of mpv library?
I tried mpv-dev-x86_64-20220717-git-70fa950 using instructions in the thread you provided and the issue is still there.
Out of curiosity I tried Plex HTPC as well and results are the same.
Also I downloaded the media I used to test with to my computer and played them in playlist mode with mpv-x86_64-20220717-git-70fa950 with --hwdec=auto. With 4k movie VRAM usage jumped to 500MB (less than 1.2GB through Plex) but after switching to episodes it dropped to 110MB and held steady even with 20 episode switches (on Plex it was raising by 150-300MB per episode). Don’t know if that info would be of any use, though.
My bad, I should have linked to the newest build. The fix provided by @gbooker02 was just merged yesterday into the mpv upstream repo and the build provided via SourceForge isn’t updated yet.
Please try this build Release 20220722 · shinchiro/mpv-winbuild-cmake · GitHub. (#update: it should include it - it has the commit hash “git-9931538” in the mpv archive name.) If the issue is still there then, it’s a new one. I will also try this on my setup when I got some spare time in about 1 week.
Well, this is strange. So you see this behavior only in Plex for Windows (no matter what version) but not in Plex HTPC?
Have you tried removing Plex for Windows (+ manually removing the Folder under the Appdata dir and the leftover parts in ProgramFiles) and reinstalling it?
Presuming that you are talking about standalone MPV, this isn’t testing the same codepaths. To actually test it properly you need to use --idle=yes with no other options. Then use the console (hit the backtick key) and type loadfile filename. Play/skip to the end. Hit backtick again and hit the up-arrow/return to execute the command again. Repeat. Monitor the VRAM usage during this time. Try with and without hardware decoding and if you are adventurous with other gpu contexts (such as winvk).
The difference in memory usage is almost certainly due to the fact that you aren’t running MPV with the same options. These options can create different memory usage through the swapchain. Your Plex for Windows logs does indicate what options it gives to MPV.
VRAM was staying at ~150MB after playback end, but on loading the next file memory seemed to be cleaned before starting the playback (4k movie was always using ~660MB, episode ~170MB).
Another thing I noticed is that scaling the standalone mpv window does not change VRAM usage, scaling the Plex window results in 300-500MB difference in VRAM usage (WQHD screen).
Is there a reason you are using dxva2? I expect that if you are using auto it will end up using d3d11. You can see what it does by adding the option msg-level=all=v.
There are also some options set when the app starts up though gpu-hwdec-interop=auto may be the only important one.
This is normal in that it holds some memory until the next playback starts. The difference in memory appears to be proportional to the decoded picture size. A file that’s in SD is difficult to notice in memory usage.
This is odd. Perhaps something in the embedding code in MPV is causing this but I’m starting to question drivers. It may be worth:
Changing the video quality setting in Plex for Windows/HTPC to one of the ANGLE ones to see if that makes a difference.
Turn off hardware decoding to see if it makes a difference
On auto it uses d3d11va, I thought dxva2 is the one. My bad.
Second test used auto, though.
Now it’s interesting. With hardware decoding off, I get the leak only on ANGLE renderer (200MB per full hd episode). With hardware decoding on, I get the leak on both renderers. Tested mpv with --idle=yes --hwdec=no --gpu-context=angle (confirmed with logs that it uses GLES) and there’s no leak.
About resizing:
With both renderers and hardware decoding off I still get that 300MB VRAM increase when maximizing. I forgot to mention that resizing one is not a leak, VRAM reduces by that 300MB when unmaximizing, it’s still quite a chunk IMO.
I’m not sure what else to try here or what the resolution might be in your case. I am not seeing the leaks you see nor has anyone else reported it that I’ve seen. This really seems to be something that’s exclusive to something in your system. The only leak we’ve ever seen was the one linked in the second comment which has since been fixed.
I tried it on my end and I also have this issue but not with an out-of-the-box install. On my end it seems to be vo=gpu-next + d3d11 related. vo=gpu with d3d11 is working as it should, with the shipped or with a different dll. Note this is not visible with Vulkan.
This time it is also different. When playing back a file, more VRAM is used, after that, it is flushed except for a small amount (in my case 150mb with each file) - do this 7 times and 1 additional Gig of VRAM is used… The mpv lib I used for testing includes the patch linked in this thread*
