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

[FFmpeg]

#7943: Ffmpeg QSV backend uses >2x more GPU memory compared to VAAPI or MSDK
-------------------------------------+-------------------------------------
             Reporter:  eero-t       |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by eero-t):

 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 Replying to [comment:4 fulinjie]:
 > Resolution set to wontfix

 Why QSV backend can't be made to do whatever MSDK sample transcode
 application does?

 ----

 Replying to [comment:1 fulinjie]:
 > It could be verified by gpu_copy decode which do not allocate memory
 internally:

 This workaround option seems to require very latest FFmpeg git version,
 but it doesn't help, neither with the original transcode command, nor when
 doing just decode.  Memory usage is the same, and FFmpeg outputs this
 warning:
 {{{
 [hevc_qsv @ 0x5638f71fd840] GPU-accelerated memory copy only works in
 MFX_IOPATTERN_OUT_SYSTEM_MEMORY.
     Last message repeated 1 times
 }}}

 (Above output is with last night Git versions of drm-tip kernel, media-
 driver, MSDK and FFmpeg.)

 ----

 Replying to [comment:3 fulinjie]:
 > However, a small initial_pool_size may lead to some unexpected errors
 like:

 Why VA-API doesn't fail to those errors when using same sized initial pool
 size?

 (Smaller '''initial''' pool size causing alloc errors sounds like bug,
 normally such things should affect only performance.)

 ----

 PS. IMHO wontfix would be acceptable resolution if QSV backend would be
 dropped and the few extra things provided by it [1] would be added to VA-
 API backend (besides QSV being slower and using 2x GEM memory, it lacks
 support for most of the formats supported by VA-API, listed in #7691, and
 need to identify & specify decoding codec is annoying).

 [1] low power mode & extra bit-rate control modes with HuC.  Is there
 anything else QSV provides over VA-API with the iHD Media driver?

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