[FFmpeg-trac] #8328(undetermined:new): QSV gives much worse PSNR/SSIM for HEVC transcode than VA-API or MediaSDK

[FFmpeg]

#8328: QSV gives much worse PSNR/SSIM for HEVC transcode than VA-API or MediaSDK
-------------------------------------+-------------------------------------
             Reporter:  eero-t       |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by eero-t):

 Replying to [comment:8 fulinjie]:
 > BTW, I did some tests locally with a 4K, yuv420p10 clips, and this psnr
 issue is not reproduced with ffmpeg of either latest version or the commit
 at end of 2018.
 > Clips:
 ​>
 https://drive.google.com/file/d/1k0e5bBPs2JDHwJZdT8qBkpMdcwHywnSq/view?usp=sharing

 Is this original 4K content, or upscaled 2K content (i.e. lacking details,
 which would affect quality metrics)?

 I tried to reproduce your results with a version of that video that I know
 to have 4K of details, but ran into another Ffmpeg bug:
 https://trac.ffmpeg.org/ticket/8342


 Replying to [comment:7 eero-t]:
 > While "-bf 2" option didn't do anything for VA-API, giving "-bf 6"
 option for it, dropped VA-API PSNR marginally (<1%).

 Whereas giving -bf 8 to VA-API, drops it to 32 (from 41), which is still
 noticeably better than 25 from QSV.


 Replying to [comment:8 fulinjie]:
 > It's not an issue IMHO.
 >
 > For VAAPI hevc encoder, the default parameter for bf is 2:
 >
 https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vaapi_encode_h265.c#L1265
 >
 > For QSV hevc encoder, the default parameter for bf is 8:
 >
 https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc_hevc.c#L261
 >
 > And for some historical reasons, it was set to 8 on purpose:
 >
 https://github.com/FFmpeg/FFmpeg/commit/a43905f4ae261bdde87c300901d867b31961f57b

 QSV backend comment seems a bit dubious.  GOP has also P-frames, so number
 of B-frames isn't going to evenly match GOP anyway, especially if driver /
 HW can also automatically adapt the number of B-frames like x264 & x265
 do.

 Looking at the history, earlier values (250 gop, 3 bf) were the same as
 what's used in qsvenc_h264.c, and which are stated to be defaults for
 x264.

 Therefore same values that x265 might be relevant also for qsvenv_hevc.c.
 According to x265 docs, it defaults to 4:
   https://x265.readthedocs.io/en/default/cli.html#slice-decision-options

 I tested different -bf values:
 * 2: PSNR=41
 * 4: PSNR=41
 * 6: PSNR=41
 * 7: PSNR=41
 * 8: PSNR=25
 * 12: PSNR=25
 * 16: PSNR=25

 (Setting GOP size to original 250, gave same PSNR=25 with -bf 8.)

 I tested also another HEVC video (Crown Run) which is marginally smaller
 (3840x2160), 8-bit, and has less details than the FoodMarket video. With
 that, PSNR dropped from 35 to 24, when -bf was increased from 11 to 12.

 Then I tried couple of 10-bit HEVC videos in quarter size (1920x1080).
 PSNR for those didn't drop even with -bf 16.

 From above it would seem that large B-frame numbers could be problem in
 larger resolutions, especially with videos where content has a lot of
 details & their changes.


 > Hence in this performance test, a better choice could be setting "-bf"
 with the same value explicitly for both VAAPI and QSV, instead of using
 the default settings of codecs(usually parameters are different between
 each codec).

 My small testing seems to indicate that current default value may be badly
 chosen for more demanding content.

 Could you discuss this with the driver team, what is their recommendation
 on these nowadays?

 Maybe do also your own testing on whether you see large quality drops when
 content is large & detailed enough and B-frame count goes over some
 threshold?  If you have good (not upscaled) 8K content, it would be good
 to test that too.

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