FFmpeg kills machine with infinitely increasing memory usage at end of PSNR calculation

[eero-t]

Summary of the bug:
With some video inputs, FFmpeg starts taking rapidly increasing amounts of memory at the end of the quality metrics calculation, and if left running, it takes all memory and renders device unusable.

Use-case example:

1. Get 4K video:

   $ wget http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_2160p_30fps_normal.mp4
   

2. Transcode it to HEVC with FFmpeg:

   ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v hevc_vaapi -frames 330 output.h265
   

3. Check the resulting quality difference:

   ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -i output.h265  -filter_complex psnr -frames 300 -f null -
   

Expected outcome:

• FFmpeg decodes all frames and outputs PSNR value

Actual outcome:

• Around frame 287, FFmpeg resident memory usage starts to rocket up from megabytes to gigabytes
• Unless FFmpeg is interrupted within few seconds, machine freezes [1]

Note that same happens also when:

• "-lavfi 'ssim;[0:v][1:v]psnr'" is used instead of "-filter_complex psnr"
• Doing transcoding Ubuntu 18.04 FFmpeg & i965 VA-driver
• Doing transcoding with latest Git version of FFmpeg and Intel iHD Media stack
• Using QSV instead of VA-API
• Doing metrics calculation with Ubuntu 18.04, or git version of FFmpeg

I.e. this is an old issue, not some recent regression, as Ubuntu FFmpeg version is:
​https://packages.ubuntu.com/bionic-updates/ffmpeg

I had no such issues when I used another, 4096x2160 10-bit HEVC video as input, instead of the above 3840x2160 8-bit AVC video. I.e. issue isn't related to how large resolution the video has.

[1] This is on Ubuntu 18.04 LTS with 8GB Kabylake machine not running anything else besides the desktop. Fmpeg not getting OOM-killed and machine freezing & not recovering is also a bug (in Linux 5.x / Ubuntu 18.04), but not relevant for this.

[Elon Musk]

Command you use is simply wrong, you can not compare files with different timestamps like that. Framesync expect nice timestamp from input frames and will bollocks on invalid timestamps.

[eero-t]

Where the transcode output would get different timestamps than the input? I don't have any frame rate options or other time skew in the command line.

[Elon Musk]

I'm telling you that issue are timestamps. Make sure that timebases between both inputs matches, and that there are not gaps between timestamps.

[eero-t]

How? And why FFmpeg would change the timebase for output from what's used in the input? Only difference between them is the selected codec (AVC vs. HEVC), doesn't HEVC support all timebases that AVC does?

Btw. I just noticed that PSNR calculation complained about "-frames" option, and if I use "-vframes" option instead, then FFmpeg behaves just fine. Resident memory usage keeps within 0.6GB, instead of going to 8GB and beyond. WTF?

[eero-t]

Replying to eero-t:

How? And why FFmpeg would change the timebase for output from what's used in the input? Only difference between them is the selected codec (AVC vs. HEVC), doesn't HEVC support all timebases that AVC does?

Btw. I just noticed that PSNR calculation complained about "-frames" option, and if I use "-vframes" option instead, then FFmpeg behaves just fine. Resident memory usage keeps within 0.6GB, instead of going to 8GB and beyond. WTF?

That warning was:
Applying unspecific -frames to non video streams, maybe you meant -vframes ?

Note that:

• "-frames" option isn't ignored by FFmpeg, if I make it smaller, FFmpeg goes haywire earlier
• using "-an" option instead of "-vframes" in metrics calculation will also make it behave sanely

So the problem seems to be related to redundant processing of audio. This is weird because AFAIK PSNR filter handles only video data (at least it outputs values only for YUV channels, not audio), and because "output.h265" file doesn't have any audio track (same issue happens if "-an" is applied only to transcoding).

Questions:

• Does "-vframes" imply "-an"? And if yes, could it be documented?
• How audio handling can affect video frame quality calculation, and why it explodes FFmpeg?

[Elon Musk]

vframes does not imply -an
it exploded ffmpeg, the tool. because it buffers frames for some reason.
One of workarounds if you want audio in output is to do:

-lavfi "psnr;anull" -frames 100 ...

or even better just disable audio processing with -an.

[Elon Musk]

Feel free to reopen if still happens.

[eero-t]

Tested with yesterday's FFmpeg (and Intel media stack) Git version.

Seems to be fixed, memory usage does not constantly grow any more.

Memory usage is higher than I would have thought (transcode takes 0.3GB, comparison 1.1GB of RSS), but is stable.

=> status should be set to fixed, not "needs_more_info".

(In general, closing bug with "needs_more_info" without actually asking anything seems odd.)