[FFmpeg-trac] #7706(avcodec:closed): 20-30% perf drop in FFmpeg (H264) transcode performance with VAAPI

FFmpeg trac at avcodec.org
Mon Apr 4 13:03:58 EEST 2022


#7706: 20-30% perf drop in FFmpeg (H264) transcode performance with VAAPI
-------------------------------------+-------------------------------------
             Reporter:  eero-t       |                    Owner:  (none)
                 Type:  defect       |                   Status:  closed
             Priority:  important    |                Component:  avcodec
              Version:  git-master   |               Resolution:  fixed
             Keywords:  vaapi        |               Blocked By:
  regression                         |
             Blocking:               |  Reproduced by developer:  1
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by eero-t):

 >> For parallel transcode operations which (more than) fill whole GPU,
 there can be up to couple of percent regression
 >
 > Command?

 The general use-case for them is:
 * Start dozen(s) of *identical* FFmpeg transcode operations in parallel
 * Calculated resulting average FPS over all of them

 (Tested transcode use-cases are HEVC->HEVC, AVC->AVC, AVC->MPEG2, and
 include several different resolutions.)

 While one use-case goes couple of percent down on one HW, it goes up on
 another HW, and for another use-case, the change is the other way round.
 For all use-cases where there's some HW where result goes marginally down,
 it goes marginally up on another HW.  While results are reproducible,
 there's no uniform regression from the fix, i.e. you should ignore that
 effect.

 (With slightly more work being done by commit
 d165ce22a4a7cc4ed60238ce8f3d5dcbbad3e266, but it improving perf, that kind
 of behaviour could even be expected, as both will affect kernel
 scheduling.)

 Note that after this fix to a huge perf regression, which in some cases
 even improves things more than just fixing the regression, VA-API is now
 faster in *all* of those cases than doing indetical thing using QSV API.
 IMHO what should be looked at now, is QSV perf.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/7706#comment:17>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list