mpv
mpv copied to clipboard
mpv-player
Huge memory usage with OSD always on and some web streams
Important Information
Provide following Information:
- mpv version: 0.33.1
- Platform and Version: Currently I'm on Mac OS X but this happens on Windows and Linux as well
- Source of the mpv binary: I installed mpv using Homebrew, but it happens also with shinchiro builds and on my own Linux builds.
Reproduction steps
Just run this:
mpv --no-config --player-operation-mode=pseudo-gui --script-opts=osc-visibility=always http://vps.radioduepuntozero.it:9080
Expected behavior
The memory usage stays quite the same during playback
Actual behavior
The memory occupation starts growing, at first really fast (like 2MB per second) then it progressively slows down, but still growing. I've seen it up to more than 600MB after a few days of playback. It seems that some events actually drop the RAM usage, like on Mac it drops if I put another maximized window on top of the MPV one and then I focus back on the MPV windows. I did this before quitting MPV, in the log I attach.
Log file
https://0x0.st/-O73.txt
my guess is that it's the libass glyph cache.
@CounterPillow is libass used also to render the OSD graphic itself? Because this is an audio stream with no subtitles.
Yes, the entire pseudo-gui of mpv is rendered with ASS subtitles.
Got it, thanks for clarifying. Unfortunately I have little to no experience with C so it would take me ages to look into it :(
If someone is willing to help me I'd be really grateful, this is a major issue for me since I'd need to keep it open h24 and the RAM will eventually saturate.
the libass glyph cache is of limited size, so it's not going to exhaust all of your RAM.
It doesn't seem to be related to libass, even if you disable the pseudo-gui, RAM usage will keep increasing. This seems to be because the stream data is being integrated and cached in mpv, which allows seeking backwards in the stream,
run this:
mpv --no-config --player-operation-mode=pseudo-gui --script-opts=osc-visibility=always http://vps.radioduepuntozero.it:9080
The memory occupation starts growing, at first really fast (like 2MB per second) then it progressively slows down, but still growing. I've seen it up to more than 600MB after a few days of playback.
I don't doubt the observation (memory growth), but with the info we have so far, I don't see how you concluded that it's related to osc-visibility=always, or, as you put it: "Huge memory usage with OSD always on".
To reach this conclusion, you'd have to also try with osc-visibility=never (or just --no-osc to not even load the osc script) and confirm that the memory growth issue goes away.
Have you done that?
Hello,
actually, the RAM usage progressively increases also without the OSD, but also with no GUI at all, using MPV in the terminal.
However, the increase is slower and never goes over 250MB or so. It's still pretty much, but acceptable.
With the OSD on, it increases much faster. On one of the machines, where I have mpv running since about 3 days, it's now at 697MB. It could be me, but it seems it has an increase peak whenever the title changes.
I'm pretty sure the RAM increase only slows down but never really stop, since I used to run it on a Raspberry with 2 GB of RAM and it eventually saturated after 2 or 3 weeks.
Sure, with OSD/OSC it uses more ram (and grows quicker initially), because libass has a big cache. However, that should eventually stop growing. I don't know how big is the libass cache, but I think it's several hundreds megabytes.
So really, if you claim the issue is due to the OSC, then you need to provide more concrete evidence. For example, two instances of mpv playing the same source/stream, one with OSC and one without OSC, and the one with OSC keeps using more and more memory forever, while the one without stops growing after some time.
Leak bugs are of course possible, but so far you did not provide enough evidence to suggest either that it's related to the OSC, or that there's a leak at all.
Thank you @avih , I will try to produce everything that could be needed to track down the issue.
Over at https://github.com/jaseg/python-mpv/issues/233 someone observed a simililar issue. What I noticed there is that on the following stream: https://media-ice.musicradio.com/CapitalMP3 mpv still seems to grow by a few hundred kB every other minute even with --demuxer-max-bytes=100k --demuxer-max-back-bytes=100k. It seems that that might be in part due to mpv's processing of the stream's Icy metadata, since it seemed to slow down (but did not stop) when also passing --http-header-fields='Icy-MetaData: 0' (which the stream server seemed to respect, since mpv did no longer output the stream title metadata).
