[FFmpeg-trac] #7943(undetermined:new): Ffmpeg QSV backend uses >2x more GPU memory compared to VAAPI or MSDK

FFmpeg trac at avcodec.org
Wed Jun 5 18:01:24 EEST 2019

#7943: Ffmpeg QSV backend uses >2x more GPU memory compared to VAAPI or MSDK
             Reporter:  eero-t       |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:  git-
  undetermined                       |  master
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
 Summary of the bug:

 GPU accelerated Video transcoding can use GBs of RAM, but it's in DRI/GEM
 objects which don't show up anywhere, can't be limited, can't be swapped
 out, and can therefore easily cause OOM-kill havoc in the rest of the

 FFmpeg QSV backend uses way too much of these resources.

 How to reproduce:
 1. monitor GEM object usage
 {{{# watch cat /sys/kernel/debug/dri/0/i915_gem_objects}}}
 2. Transcode with FFmpeg / QSV
 {{{$ LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel qsv -qsv_device
 /dev/dri/renderD128 -c:v hevc_qsv -i
 Netflix_FoodMarket_4096x2160_10bit_420_100mbs_600.h265 -c:v hevc_qsv -b:v
 20M -async_depth 4 output.h265}}}
 2. Transcode with MediaSDK sample app:
 {{{LIBVA_DRIVER_NAME=iHD $ sample_multi_transcode -i::h265
 Netflix_FoodMarket_4096x2160_10bit_420_100mbs_600.h265 -o::h265
 output.h265 -b 20000 -async 4 -hw}}}
 3. Transcode with FFmpeg / VAAPI
 {{{$ LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel vaapi -vaapi_device
 /dev/dri/renderD128 -hwaccel_output_format vaapi -i
 Netflix_FoodMarket_4096x2160_10bit_420_100mbs_600.h265 -c:v hevc_vaapi
 -b:v 20M output.h265}}}

 Expected outcome:
 * Both FFmpeg backends take about same amount of GPU resources as they do
 about the same thing, and that resource usage is reasonable
 * Reasonable being along lines of some (tens of) frames for prediction
 i.e. 4K * 16-bit * frames = few hundreds of MBs

 Actual outcome:
 * VAAPI backend uses ~1.1GB of GEM resources
 * QSV backend uses ~2.5GB of GEM resources, more than double
 * MSDK app uses ~1.1GB of GEM resources like VAAPI backend, so the QSV
 backend issue doesn't seem to be due to MSDK

 I tried playing with -async/-async_depth option, and I was able to raise
 MSDK app GEM object usage to 2.5GB with "-async 20" option, but even with
 "-async_depth 1" option QSV backend lowered only to 2.2GB of GEM objects,
 so it must be something else.

Ticket URL: <https://trac.ffmpeg.org/ticket/7943>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list