Memory leak starves playback

[nicolaberndt]

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.

output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• 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.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[llyyr]

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.

[nicolaberndt]

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?

[guidocella]

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.

[nicolaberndt]

Cool, many thx for the hint! Will try right away and report back.

[nicolaberndt]

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...

[nicolaberndt]

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?