3

I have 2 instances of vlc running. One is playing. One is paused (and mostly swapped out).

top - 14:25:01 up 23 days, 19:19, 69 users,  load average: 2.36, 2.61, 4.19
Tasks: 905 total,   3 running, 894 sleeping,   2 stopped,   6 zombie
%Cpu(s): 11.9 us,  6.5 sy,  0.1 ni, 81.0 id,  0.4 wa,  0.0 hi,  0.0 si,  0.0 st
GiB Mem :     31.2 total,      0.8 free,     27.4 used,      2.9 buff/cache
GiB Swap:    158.3 total,     82.4 free,     75.8 used.      1.5 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND            
 420221 tange     20   0 4066448 601160  28444 S  30.3   1.8   8:55.51 vlc <-- playing
1329863 tange     20   0 2640256 131980  42300 S   0.7   0.4  11:47.28 vlc <-- paused

The video is 1280x720 px 30 fps, and when I force swapping out, only around 100 MB is swapped back in.

Why are they taking up so massive amounts of memory? (600 MB for playing seems ridiculous) What can I change to lower this usage?

Edit:

I have investigated further.

The numbers below are in kbytes and measured with 'time -v'. They agree with 'top'.

These are resident and they are at their max when I close VLC (in other words: They do not temporarily spike shortly to find a lower level).

"Playing" means play the full video. "Pausing" means play the first few seconds and then pausing until memory usage stabilizes.

Here is the graph of "Playing 1280x720 with 2087 big videos in list" (measured with ps aux every second for 600 sec):

RSS/VSize/CPU 2087 in list

Here is the graph of "Playing 1280x720 with 0 big videos in list" (measured with ps aux every second for 100 sec):

RSS/VSize/CPU 0 in list

This shows the usage of the "0 in list" is slightly overestimated: The RSS tops shortly after start and drops a little after 15 secs.

VSize is pretty constantly 2.3GB bigger than RSS.

Playing 640x360 with 5400 videos in list: Maximum resident set size (kbytes): 1096232

Pausing 640x360 with 5400 videos in list: Maximum resident set size (kbytes): 1101840

Playing 640x360 with 0 videos in list: Maximum resident set size (kbytes): 333228

Pausing 640x360 with 0 videos in list: Maximum resident set size (kbytes): 303792

Playing 1280x720 with 2087 big videos in list: Maximum resident set size (kbytes): 1273936

Pausing 1280x720 with 2087 big videos in list: Maximum resident set size (kbytes): 1190252

Playing 1280x720 with 0 videos in list: Maximum resident set size (kbytes): 185204

Pausing 1280x720 with 0 videos in list: Maximum resident set size (kbytes): 185352

This seems to indicate that the playlist has a huge impact on the RSS, whereas the resolution of the video does not.

It is unclear why.

VLC clearly caches the length of each video: their lengths slowly show up in the list, and this explains the slow increase in memory as shown in the graph. But the length ought to be only a few bytes: Whatever VLC is doing is takes up 150 kb-500 kb resident RAM per video in the list.

I find 200 MB RSS to play a 1280x720 reasonable, but not adding 800 MB RSS just keep the playlist in RAM.

Can I ask VLC not to cache that in RAM (and still keep my list)?

1
  • 2
    Playing a 4K video with B frames? You've got your disk buffers, video input/output buffers, etc. etc. 600MB sounds perfectly normal though mpv must be a lot more frugal. Jan 7, 2023 at 13:38

3 Answers 3

2

This looks relatively reasonable – assume this: we do software decoding (i.e., we're not just sending preprocessed video data to GPU buffers for decoding in hardware), we're dealing with Full HD, and we're working with MPEG4-era codecs.

Then, we need to keep a few frames readily rendered (i.e., broken down to still image format that can be transferred to the graphics card (or handled by whatever plays the role of output here)), to allow the transfer of the next frame sufficiently ahead of time, so that there's no stutter in playback – especially if the software decoding happens on a congested CPU, calculating a bunch of frames up ahead, writing them to RAM and then hoping the operating system re-schedules you before the thread or hardware unit that updates the screen by changing the currently displayed image is done.

Now, a full HD frames in 24 bit depth (assuming that's the texture format used, but that's likely) is around 6 MB. Having around a 100 MB as prepared imagery ready for transfer/blitting doesn't sound wasteful, considering that's just a buffer of maybe ¼ of a second.

But to render these frames, you need to decode the video, which consists of a lot of small local things (think about how MPEG-2 and on are not that dissimilar to JPEG, in that they do small image blocks where some transform allows for lesser quantization of certain coefficients, and hence, compression), but also, very long-range things, like maps of relative movement (movement compensation, even in quarter-pixel resolution), and interpolation between frames that are far apart – MPEG-4 AVC (H.264) uses up to 16 reference frames, to combine to get the new frame.
That means that a single frame might need to be used in different ways, and hence there will be intermediate results that are larger than just the still necessary reference frames.

Now, I do agree, it should be possible to write a decoder using less than 600 MB of such buffer; but I guess (no actual insight in the decoders) there might be intermediate results that can potentially be reused for other frames, and hence are preferably returned to a memory pool or overwritten late. That would "bloat" the decoding memory, but for the benefit of performance.

2
  • Unfortunately that's not an answer. It has all the right ingredients but unless you provide the raw data like memory mappings it sounds like a lot of speculation. Jan 8, 2023 at 9:32
  • I'd agree with you, bit off I hold myself up to that high standards of reproducing Ole's memory consumption, if need his system and his video file (and, admittedly, more time than I could spend in tracking memory allocations in a very complex piece of software). So, for now, this will have to do Jan 8, 2023 at 10:25
1

I found the culprit:

Tools > Preferences > Show settings > All > Playlist > Automatically preparse items

If this is on, VLC will read each file in the playlist and find the length of the video. Apparently it also reads much more.

My problem disappears (and VLC stays below 200 MB) when disabling it and reappears when enabling it again.

To me it looks like a bug in VLC: Why would keeping lengths of videos take up more than a few megs total?

-1

I just started a VLC instance on Ubuntu 20.04 without playing anything and ran pmap PID to see what it has mapped into memory. Some interesting excerpts:

000055ac2ba89000   1036K rw---   [ anon ]
00007f616c000000    132K rw---   [ anon ]
00007f616c021000  65404K -----   [ anon ]
00007f6170000000    132K rw---   [ anon ]
00007f6170021000  65404K -----   [ anon ]
00007f6174000000    132K rw---   [ anon ]
00007f6174021000  65404K -----   [ anon ]
   .
   .
   .
00007f617affd000      4K rw---   [ anon ]
00007f617affe000      4K -----   [ anon ]
00007f617afff000   8192K rw---   [ anon ]
00007f617b7ff000      4K -----   [ anon ]
00007f617b800000   8192K rw---   [ anon ]
00007f617c000000    132K rw---   [ anon ]
00007f617c021000  65404K -----   [ anon ]
00007f6180000000    132K rw---   [ anon ]
00007f6180021000  65404K -----   [ anon ]
00007f6184000000   8160K rw---   [ anon ]
00007f61847f8000  57376K -----   [ anon ]
00007f6188000000    132K rw---   [ anon ]
00007f6188021000  65404K -----   [ anon ]
   .
   .
   .
00007f6190000000  65536K rw-s- memfd:pulseaudio (deleted)
00007f6194000000  65536K rw-s- memfd:pulseaudio (deleted)
00007f6198000000  65536K rw-s- memfd:pulseaudio (deleted)
00007f619c000000  65536K rw-s- memfd:pulseaudio (deleted)
   .
   .
   .
 total           983604K

Given this is just from starting up VLC and not playing anything, I think one word can be used to accurately describes it: OINK

Almost 1 GB of RAM without doing anything? What can you do about it? Find something less, umm, hoggish of RAM?

1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – terdon
    Jan 7, 2023 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .