Memory leak starves playback
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 37k
- Forks
- 3.5k
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 22
Description
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:
- 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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the memory growth while looping the reported large video with gpu-next, both with and without hardware decoding, using the attached output.txt for baseline details. Compare behavior with mpv 0.32 and 0.35.1, and narrow the regression to the playback or rendering path. Done means extended looping no longer steadily increases memory or triggers the OOM killer.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100