Opened 4 years ago

Closed 10 months ago

Last modified 10 months ago

#8342 closed defect (needs_more_info)

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

Reported by: eero-t Owned by:
Priority: important Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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
    
  1. 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
    
  1. 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.

Change History (8)

comment:1 by Elon Musk, 4 years ago

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.

comment:2 by eero-t, 4 years ago

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.

comment:3 by Elon Musk, 4 years ago

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

comment:4 by eero-t, 4 years ago

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?

in reply to:  4 comment:5 by eero-t, 4 years ago

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?
Last edited 4 years ago by eero-t (previous) (diff)

comment:6 by Elon Musk, 3 years ago

Reproduced by developer: set
Status: newopen

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.

Last edited 3 years ago by Carl Eugen Hoyos (previous) (diff)

comment:7 by Elon Musk, 10 months ago

Resolution: needs_more_info
Status: openclosed

Feel free to reopen if still happens.

comment:8 by eero-t, 10 months ago

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.)

Last edited 10 months ago by eero-t (previous) (diff)
Note: See TracTickets for help on using tickets.