mpv-player
Memory leak starves playback
mpv Information
mpv 0.35.1 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
built on UNKNOWN
FFmpeg library versions:
libavutil 57.28.100
libavcodec 59.37.100
libavformat 59.27.100
libswscale 6.7.100
libavfilter 8.44.100
libswresample 4.7.100
FFmpeg version: 5.1.6-0+deb12u1
Other Information
- Linux version: Debian 12.7
- Kernel Version: 6.1.0-26-amd64
- GPU Model: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106GL [Quadro P2000] [10de:1c30] (rev a1)
- Mesa/GPU Driver Version: OpenGL version string: 4.6.0 NVIDIA 560.35.03
- Window Manager and Version: Xfwm4
- Source mpv: Debian package
- Introduced in version: not exactly known, issue was not present in 0.32, is all I know
Reproduction Steps
When playing videos in a loop, mpv memory usage increases endlessly and ends up using all the avalable RAM until the machine ist starved and the OOM killer kicks in and kills mpv. This happens with and without hardware-decoding. We use gpu-next as vo,
I came across this when updating our playout machines from debian 11 (mpv 0.32) to debian 12 (0.35.1). Ally our machines simply froze after a few hours, then OOM kicked in and playback crashed.
Since we only play large videos on multi-head-outputs it might happen faster. The smallest video I have is around 3000x3000 pixels, so that is around the pixel-amount of a regular HDR video and it shows the same problem, even when played out on a single screen.
The time it takes to crash of course also depends on the amount of memory installed. With our setup it takes roughly 18 hours, so testing is slooow.
Expected Behavior
I expect mpv to endlessly play the file.
Actual Behavior
mpv eats up all the memory and crashes or is being killed by the OOM watdog.
Log File
If I run mpv with the given options for the logfile it will be overwhelmingly huge, so please let me know how I can come up with something usefull. Here is the logfile right after startup, if that helps. I can see RAM of mpv increase constantly though right from the start.
Sample Files
No response
I carefully read all instruction and confirm that I did the following:
- [X] I tested with the latest mpv version to validate that the issue is not already fixed.
- [X] I provided all required information including system and mpv version.
- [X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of
--log-file=output.txt. - [X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
- [X] I attached the full, untruncated log file.
- [X] I attached the backtrace in the case of a crash.
mpv 0.35.1 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
We only provide support for the latest tagged release or newer. Update mpv and if the issue still exists open a new ticket.
Since I am in a production environment (museum) I have to use a stable distribution in order to prevent such problems where possible.
So for me and perhaps many more users this is "the last stable version" that we actually can install.
How can one debug such issues? If I'd ask the debian maintainers I am sure they will tell me to go ask here.
Could anyone with "the latest tagged release or newer" quickly fire up a video in a loop and watch RAM-use for a while?
This is an Nvidia+OpenGL bug. I reported it 1 year ago on IRC and was suprised no one else was complaining about it. It is still present on a rolling release. You can avoid it by using --gpu-api=vulkan.
OK, I let this run for a couple of hours. RAM usage did not grow as fast as without it, nonetheless it still gets more over time. 10 minutes after starting up it used around 200 MB and now its at 380. I will let it run overnight and report back on that.
I do have a new problem now, though: --gpu-api=vulkan prevents playback on my test-machine with 6 DP-Outputs spanned over two cards:
[vo/gpu-next/libplacebo] Probing for vulkan devices:
[vo/gpu-next/libplacebo] GPU 0: Quadro P2000 (discrete)
[vo/gpu-next/libplacebo] uuid: E2:0F:31:2A:8C:C0:4B:1F:71:2A:12:84:BE:F7:9E:18
[vo/gpu-next/libplacebo] GPU 1: Quadro P2000 (discrete)
[vo/gpu-next/libplacebo] uuid: 67:66:DD:D1:01:7A:E4:A6:0A:11:5E:D3:B1:8E:2D:8A
[vo/gpu-next/libplacebo] GPU 2: Intel(R) UHD Graphics 630 (CFL GT2) (integrated)
[vo/gpu-next/libplacebo] uuid: 81:EF:55:43:6E:60:4D:53:8A:18:6B:B0:D0:81:DD:EB
[vo/gpu-next/libplacebo] GPU 3: llvmpipe (LLVM 15.0.6, 256 bits) (software)
[vo/gpu-next/libplacebo] uuid: 6D:65:73:61:32:32:2E:33:2E:36:00:00:00:00:00:00
[vo/gpu-next/libplacebo] Found no suitable device, giving up.
[vo/gpu-next/libplacebo] Failed initializing vulkan device
This happens with and without hwdec option and of course with vo=gpu-next. Using only one of these cards work fine with gpu-next.
vo=gpu does not have this issue but of course I was looking forward to using gpu-next. Well, it might work with the latest release, I cannot look into that, sadly..
Edit: I should add that this might also be a configuration option regarding the nvidia-driver with it's gazillion ever changing config-options. I will have to dive into that, once again...
Update on the Memory-issue: The player ran overnight and has a RAM usage of 480MB right now. Not critical for most but may be an issue for machines that run forever in a loop. I will have to turn this machine off at some point today to go on with other tests. Our machines do not run forever, but out of interest I might set up something that does. If so, I will keep reporting..
Regarding the Nvidia-multihead issue I tested every multihead-configuration I ever came up with and so far did not get gpu-hq to work when using more than one GPU. Where should I address this? Is it an mpv issue or straight away libplacebo? Maybe @haasn can shine some light on this?
This is an Nvidia+OpenGL bug. I reported it 1 year ago on IRC and was suprised no one else was complaining about it. It is still present on a rolling release. You can avoid it by using
--gpu-api=vulkan.
Link?
@guidocella
I'm sorry to bother you. But could we confirm that this is a platform-specific issue occurring only on Linux? I've encountered the same problem on Windows. I'm embedding mpv into my application using the libmpv renderAPI, which limits me to using OpenGL as the GPU API. This issue is causing severe performance degradation.
No idea I don't use Windows. Ideally you would use wid embedding on Windows to get d3d11 and gpu-next but I see how that is problematic for a multi-platform application.
No idea I don't use Windows. Ideally you would use wid embedding on Windows to get d3d11 and gpu-next but I see how that is problematic for a multi-platform application.
Thank you for your prompt reply. Given that we're using renderAPI and OpenGL, are there any measures we can take to mitigate this issue? I cannot use wid, flutter currently does not support passing an HWND handle on the Windows to directly implement PlatformView. I am therefore limited to using the OpenGL textures provided by renderAPI.
This is happening to me as well on Wayland (sway). after 20 hours, it reserved 25GB memory, but only used 200MB, and at launch it was at 200MB reserved. btop shows 200MB usage as well.
This is happening to me as well on Wayland (sway). after 20 hours, it reserved 25GB memory, but only used 200MB, and at launch it was at 200MB reserved. btop shows 200MB usage as well.
Open a new issue