[FFmpeg-trac] #7690(undetermined:new): FFmpeg QSV decode + VPP performance is just a fraction of what one gets with VA-API and MediaSDK

[FFmpeg]

#7690: FFmpeg QSV decode + VPP performance is just a fraction of what one gets
with VA-API and MediaSDK
-------------------------------------+-------------------------------------
             Reporter:  eero-t       |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  qsv          |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by lizhong1008):

 Replying to [comment:2 eero-t]:
 > I transcoding the 10-bit video used in this ticket to 8-bit (with Ubuntu
 18.04 FFmpeg):
 > {{{ffmpeg -i 1920x1080_10bit_60fps.h265 -pix_fmt yuv420p
 1920x1080_8bit_60fps.h265}}}
 >
 > And repeated the above test-cases using that video, with hwupload format
 changed to nv12.
 >
 > => Results are similar, iHD & i965 drivers VA-API backend, and MediaSDK
 sample application are all 3x-4x faster than using QSV.

 I suppose this an issue of qsv hwdownloading. FFmpeg-vaapi can get an
 image directly via vaDeriveImage()
 (https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_vaapi.c#L788).
 But possibly MSDK is via vaGetImage()
 (https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_vaapi.c#L815)
 thus making a copy cause performance drop. MSDK sample is working in
 system memory thus no need an action of hwdownloading.

 I will take a deeper look and go back to this issue.

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