[Issue]: EncodingHelper: avoid hardcoding `i915` as driver name in `GetQsvDeviceArgs` about jellyfin HOT 6 CLOSED

Hi, it seems like your issue report has the following item(s) that need to be addressed:

• The format of the environment section has been altered from the template.
• You have not provided the ffmpeg log unaltered from the server. Please provide a valid ffmpeg log.

This is an automated message, currently under testing. Please file an issue here if you encounter any problems.

from jellyfin.

i915 is required because the experimental xe driver does not implement all features used by Jellyfin: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/234

You may also facing other user space runtime lib compatibility issues from intel oneVPL library which jellyfin uses for certain video processing filters if you are not using i915

from jellyfin.

i915 is required because the experimental xe driver does not implement all features used by Jellyfin: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/234

Yes, currently i915 works well on most scenarios and devices. But xe works better on some hardware (like my DG1 on latest kernel).
It will eventually become mature and come into production. Thus I believe an timely fix is good for potential users.

As another point, no matter what driver they are using, users should also be able to specify the device with QSV enabled, in case they have multiple GPUs to choose from.

You may also facing other user space runtime lib compatibility issues from intel oneVPL library which jellyfin uses for certain video processing filters if you are not using i915

Still, I'm not saying about abandoning i915, but allowing xe to be an option.

from jellyfin.

As suggested above Xe isn't feature complete enough for Jellyfin and supporting it would put more burden on the Jellyfin team.

As another point, no matter what driver they are using, users should also be able to specify the device with QSV enabled, in case they have multiple GPUs to choose from.

You cannot chose which QSV device you want to use with ffmpeg, that's just how it is and there is nothing we can do about it.

from jellyfin.

You cannot chose which QSV device you want to use with ffmpeg, that's just how it is and there is nothing we can do about it.

I don't think so. Per my observation, when using qsv=@va, the QSV device is the previously selected VAAPI device.

For this specific case, all of the following options can work with xe, but the command that Jellyfin currently generates (-init_hw_device vaapi=va:,kernel_driver=i915,driver=iHD -init_hw_device qsv=qs@va) doesn't.

• -init_hw_device vaapi=va,kernel_driver=xe,driver=iHD -init_hw_device qsv=qs@va
• -init_hw_device vaapi=va,driver=iHD -init_hw_device qsv=qs@va (auto-detection for any device supported by intel media driver)
• -init_hw_device vaapi=va:/dev/dri/renderD128,kernel_driver=i915,driver=iHD -init_hw_device qsv=qs@va (when device path is used, any following filters are simply ignored.)

Again, I am not seeking any additional support for xe at the moment. But device selection for QSV is not "how it is and there is nothing we can do about it”.

from jellyfin.

We will reconsider this after several Linux kernel version iterations, and after both media-driver and VPL runtime declared non-experimental support for Xe KMD in the release docs.

For the time being, Xe KMD is still guarded by the xe.force_probe kernel parameter, and the QSV hwcontext in FFmpeg is still hardcoded to be supported only by i915 KMD. So I wouldn't jump in until Intel devs decide to officially use them.

from jellyfin.