Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#8992 closed defect (invalid)

Memory accumulation using x11grab under unclear circumstances

Reported by: Stephan Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: x11grab
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Attachments (1)

ffmpeg-20201118-122459.log.tar.gz (178.7 KB ) - added by Stephan 4 years ago.
-report file

Download all attachments as: .zip

Change History (3)

by Stephan, 4 years ago

-report file

comment:1 by Marton Balint, 4 years ago

Resolution: invalid
Status: newclosed

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.

Last edited 4 years ago by Marton Balint (previous) (diff)

comment:2 by Carl Eugen Hoyos, 4 years ago

Component: ffmpegundetermined
Keywords: ram memory removed
Version: unspecified
Note: See TracTickets for help on using tickets.