Memory accumulation using x11grab under unclear circumstances

[Stephan]

Summary of the bug: Memory accumulation using x11grab under unclear circumstances.

The recording works fine until I start doing things in parallel.
That might be more demanding web-pages, starting a movie, etc.

Then the memory footprint starts to increase until I stop the activity or the RAM is full and everything freezes.
If I stop with whatever I was doing, the footprint stays constant until the end of the recording.

I have trouble to reliably reproduce it but it "seems" to appear when the ffmpeg process goes above 100 % CPU usage as listed by ps.

It does not seem to be related to the overall CPU usage, since /usr/bin/stress -c 8 does not seem to affect this.

How to reproduce: Using the below command and e.g. browse on demanding web-pages (e.g. Google News).

% ffmpeg -v 9 -loglevel 99 -report \
  -probesize 100M -thread_queue_size 1024 \
  -framerate 25 -video_size 2560x1440 \
  -init_hw_device qsv=hw -filter_hw_device hw \
  -f x11grab -i :0.0+0,2160 \
  -thread_queue_size 4096 \
  -use_wallclock_as_timestamps 1 -fflags +genpts \
  -f pulse -i alsa_input.pci-0000_00_1f.3.analog-stereo \
  -c:a aac -b:a 196k -ar 48000 \
  -vf format=yuv420p,hwupload=extra_hw_frames=64,format=qsv,vpp_qsv=detail=50:framerate=25 \
  -global_quality:v 40 -look_ahead 1 -look_ahead_depth 25 \
  -c:v h264_qsv -profile:v high -level:v 5.1 \
  -preset veryslow -bf 16 -trellis 2 \
  -movflags +faststart \
  ~/Downloads/test.mp4

ffmpeg version: 4.3.1
built on gcc 10.1.0

[Stephan]

-report file

[Marton Balint]

Well, if you specify a thread queue size of 1024, then if encoding can't keep up with capturing then you eventually get 1024 uncompressed frames in RAM meaning 1024*2560*1440*4 bytes which is roughly 14 GB. You either should reduce the CPU load (use a faster preset, decrease resolution, etc) or decrease thread_queue_size to a 10-20 frames if you accept a lower framerate if encoding can't keep up.