Opened 2 weeks ago

Last modified 3 days ago

#7649 new defect

FFmpeg QSV initialization fails on KBL HadesCanyon (= both Intel & AMD GPUs) when DISPLAY is set

Reported by: eero-t Owned by:
Priority: normal Component: avutil
Version: git-master Keywords: qsv
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Setup:

To reproduce, use FFmpeg QSV backend. For example:

ffmpeg -hwaccel qsv -c:v mpeg2_qsv -i 1920x1080i_29.97_20mb_mpeg2_high.mpv -c:v h264_qsv -b:v 6M 0024_HD17i7_1.0.h264
...
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (mpeg2_qsv) -> h264 (h264_qsv))
Press [q] to stop, [?] for help
DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [2]
param: 4, val: 0
[AVHWDeviceContext @ 0x55a0ad0ee600] Failed to initialise VAAPI connection: 1 (operation failed).
Error creating a QSV device
qsv hwaccel requested for input stream #0:0, but cannot be initialized.
Error while decoding stream #0:0: Operation not permitted
[mpeg2_qsv @ 0x55a0ad0f8e80] video_get_buffer: image parameters invalid
[mpeg2_qsv @ 0x55a0ad0f8e80] get_buffer() failed
Error while decoding stream #0:0: Invalid argument
[mpeg2_qsv @ 0x55a0ad0f8e80] video_get_buffer: image parameters invalid
[mpeg2_qsv @ 0x55a0ad0f8e80] get_buffer() failed
...
[mpeg2_qsv @ 0x55a0ad0f8e80] Too many errors when draining, this is a bug. Stop draining and force EOF.
Error while decoding stream #0:0: Internal bug, should not have happened
[h264_qsv @ 0x55a0ad0fa2c0] Selected ratecontrol mode is unsupported
[h264_qsv @ 0x55a0ad0fa2c0] Current frame rate is unsupported
[h264_qsv @ 0x55a0ad0fa2c0] Current picture structure is unsupported
[h264_qsv @ 0x55a0ad0fa2c0] Current resolution is unsupported
[h264_qsv @ 0x55a0ad0fa2c0] Current pixel format is unsupported
[h264_qsv @ 0x55a0ad0fa2c0] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!

It's expected to work, because it works:

  • on other KBL devices (GT2, GT3e)
  • using FFmpeg with VA-API acceleration instead of QSV with same drivers
  • using MediaSDK sample transcode application to do the same thing

QSV backend works if DISPLAY environment variable is unset.

From "strace -f -e openat" output I can see following files to have been opened, when DISPLAY is not set:

...
<input video>
<output video>
/dev/dri/renderD128
/path/to/iHD_drv_video.so

Whereas with DISPLAY set, following are opened instead:

...
<input video>
<output video>
/home/user/.Xauthority
/dev/dri/card1
/path/to/iHD_drv_video.so

When using "latrace" to trace library calls, without DISPLAY I see following:

...
XOpenDisplay(nil)
XDisplayName(0, , , 4720)
vaGetDisplayDRM(5, , 2, 0)
vaSetErrorCallback(, , , )
vaSetInfoCallback(, , , )
vaInitialize(, , , ) = 0

Whereas with DISPLAY set, it goes:

...
XOpenDisplay(nil)
vaGetDisplay(, 85, , 0)
XDisplayName(0, 0, , )
vaSetErrorCallback(, , , )
vaSetInfoCallback(, , , )
vaInitialize(, , , ) = 1

Above differences seem to come from "vaapi_device_create":
https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_vaapi.c#L1482

Even if user specifies correct device for FFmpeg with -hwaccel_device /dev/dri/renderD128, same thing is done when DISPLAY is set, although X doesn't have anything to do with video transcoding.

Change History (7)

comment:1 Changed 8 days ago by lizhong1008

hwaccel_device is ignored to create a vaapi device: https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_qsv.c#L1232, vaapi_device_create() always receives a NULL device. Thus is a problem for multi-gpu case.
Actually hwaccel_device for qsv just means "device selects a value in ‘MFX_IMPL_*’".

comment:2 Changed 8 days ago by lizhong1008

Please use "qsv_device" to specify the child_device, and try again:
fmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -c:v mpeg2_qsv -i 1920x1080i_29.97_20mb_mpeg2_high.mpv -c:v h264_qsv -b:v 6M 0024_HD17i7_1.0.h264

comment:3 Changed 8 days ago by cehoyos

  • Keywords qsv added

comment:4 follow-up: Changed 7 days ago by eero-t

Specifying qsv_device makes it work, as does unsetting $DISPLAY.

As I need to specify device already for VA-API to work, it's fine for me to do that also for QSV.

Before fixing the render node selection in code, please document "qsv_device" usage (for multi-card use-cases) in FFmpeg QSV examples: https://trac.ffmpeg.org/wiki/Hardware/QuickSync

comment:5 in reply to: ↑ 4 Changed 6 days ago by lizhong1008

Replying to eero-t:

Specifying qsv_device makes it work, as does unsetting $DISPLAY.

Unsetting $DISPALY is just a workaround as you meantioned. But specifying qsv child device is necessary when you have multiple GPU devices, and this is a real solution.

As I need to specify device already for VA-API to work, it's fine for me to do that also for QSV.

So, is it ok to close this ticket now?

Before fixing the render node selection in code, please document "qsv_device" usage (for multi-card use-cases) in FFmpeg QSV examples: https://trac.ffmpeg.org/wiki/Hardware/QuickSync

Good suggestion, will add it later. Thanks for remind.

Last edited 6 days ago by lizhong1008 (previous) (diff)

comment:6 follow-up: Changed 4 days ago by eero-t

On devices which have only single Intel GPU, it should be possible for a driver of that HW to be able to find the correct one without user needing to specify it.

For example, if /sys/class/drm/renderD128/device/vendor isn't Intel, /dev/dri/renderD128 is unlikely to be a suitable device for Intel video driver.

And if on some machine multiple GPUs identify themselves with Intel vendor, driver could default to first which /sys/class/drm/<rendernode>/device/device ID matches a supported HW ID, unless user specifies something else.

I guess correct place for these checks would be in the libva backend, as it's the one that knows what HW it supports. If there isn't any support for that, could you file a bug about that to appropriate place, and link it here as a blocker?

comment:7 in reply to: ↑ 6 Changed 3 days ago by lizhong1008

Replying to eero-t:

And if on some machine multiple GPUs identify themselves with Intel vendor, driver could default to first which /sys/class/drm/<rendernode>/device/device ID matches a supported HW ID, unless user specifies something else.

I guess correct place for these checks would be in the libva backend, as it's the one that knows what HW it supports. If there isn't any support for that, could you file a bug about that to appropriate place, and link it here as a blocker?

https://github.com/intel/media-driver is the driver used by MSDK and FFmpeg-qsv. You can report an issue there.
However, I don't think it is helpful When you set a AMD GPU as display device but the libva driver is to get a device from a X11 display. The only way in my mind is to make FFmpeg connect to a drm device directly, this is not a default path and should be set manually (you suggestion is just to chose an appropriate default drm device automatically)

Last edited 3 days ago by lizhong1008 (previous) (diff)
Note: See TracTickets for help on using tickets.