Emby server 4.6.0.50: no advanced support for Intel gen11 GPU (Iris Xe) ?

[GPFocus17 0]

Hello,

I just upgraded my Emby server to latest 4.6.0.50, on a NUC11TNHi5 (Intel gen11 mini-PC), running Ubuntu server 20.04.2

When selecting:   Transcoding -> Enable hardware acceleration when available -> Advanced ,

I don't see anything listed under:

"Preferred Hardware Decoders" and "Preferred Hardware Encoders".

See attached hardware detection log.

Is "advanced hardware acceleration" supported for Intel Gen11 GPUs ?

If not, is this feature scheduled to be added?

Thanks,

GP

PS: I have an "Emby Premiere" subscription

hardware_detection-63757133052.txt

[Luke 37220]

Hi there, have you followed our hardware acceleration setup guide?

https://support.emby.media/support/solutions/articles/44001160148-hardware-acceleration-overview

[Q-Droid 670]

Was it working before the Emby upgrade? What version of the Linux kernel are you running?

[rouq 23]

From the logs you are running ubuntu 20.04 on kernel 5.4.  This kernel doesn't have the support for this iGPU.

 

You need to install kernel 5.10 or later to get the hardware acceleration working.

Regards

[GPFocus17 0]

Thanks rouq, that did it!

I upgraded the Linux kernel from "5.4.0-73-generic" to "5.12.6-051206-generic", and now I have access to the advanced hardware acceleration settings (sample attached).

So it was not an Emby problem after all, you guys did a great job with this new version! 

[Luke 37220]

Thanks for the feedback !

[hooray4me 52]

9 minutes ago, GPFocus17 said:

Thanks rouq, that did it!

I upgraded the Linux kernel from "5.4.0-73-generic" to "5.12.6-051206-generic", and now I have access to the advanced hardware acceleration settings (sample attached).

So it was not an Emby problem after all, you guys did a great job with this new version! 

Make sure you flip your preference order of those codecs... move quickSync to the top in each category... much better performance... so far

[chrissi55 2]

On 5/21/2021 at 4:48 AM, Luke said:

Hi there, have you followed our hardware acceleration setup guide?

https://support.emby.media/support/solutions/articles/44001160148-hardware-acceleration-overview

Is there any Guide that tells us how to get it working on VMware ESXi Hosts?

Thanks

[Luke 37220]

7 hours ago, chrissi55 said:

Is there any Guide that tells us how to get it working on VMware ESXi Hosts?

Thanks

No but you can probably find helpful info here in the community. Generally speaking first thing you'll need to do is configure the VM to allow direct access to the gpu.

[ivybridge0 1]

I also have a gen11 mini pc,its n5095-AIO platform,intel named it as Japer lake/Elkhart lake.I think emby didn't patch ffmpeg for hardware acceleration of this platform in Ubuntu.Both I install emby 4.7.0 from deb package and docker,emby is able to show intel QSV/vaapi,I enabled them,and run emby as root user.However ,when I played format movies like h265 and vp9,n5095 cpu was fully loading,gpu was free.In order to investigate it,I compiled and installed libva,media driver,media SDK,and ffmpeg from source code,and run this ffmpeg with -hwacc -qsv,its working,cpu loads was low.So I think the intel media drivers and ffmpeg in emby are not patched for jasper lake/elkhart lake platform.

In addition,I tried docker pull nyanmisaka/jellyfin,its working perfectly with hw acceleration.

Ubuntu20.04lts,with 5.16  linux kernal

Edited February 19, 2022 by ivybridge0

[Luke 37220]

3 hours ago, ivybridge0 said:

I also have a gen11 mini pc,its n5095-AIO platform,intel named it as Japer lake/Elkhart lake.I think emby didn't patch ffmpeg for hardware acceleration of this platform in Ubuntu.Both I install emby 4.7.0 from deb package and docker,emby is able to show intel QSV/vaapi,I enabled them,and run emby as root user.However ,when I played format movies like h265 and vp9,n5095 cpu was fully loading,gpu was free.In order to investigate it,I compiled and installed libva,media driver,media SDK,and ffmpeg from source code,and run this ffmpeg with -hwacc -qsv,its working,cpu loads was low.So I think the intel media drivers and ffmpeg in emby are not patched for jasper lake/elkhart lake platform.

In addition,I tried docker pull nyanmisaka/jellyfin,its working perfectly with hw acceleration.

Ubuntu20.04lts,with 5.16  linux kernal

HI there, please attach the emby server log file, hardware detection log file and example ffmpeg transcoding log file from 4.7. Thanks !

[ivybridge0 1]

7 hours ago, Luke said:

HI there, please attach the emby server log file, hardware detection log file and example ffmpeg transcoding log file from 4.7. Thanks !

Ok,I run a new test emby-server,here are logs when I played a h265 movie.Thanks!

embyserver.txt ffmpeg-transcode-7bc62531-9560-46c3-91fd-9f47568c636a_1.txt hardware_detection-63780924139.txt

[softworkz 3348]

@ivybridge0 - Thanks for the logs?

Are those from a Docker image? The binary locations are different from the regular Debian installation package.
It would be great to have a log from a direct installation.

The Intel Media Driver that we are shipping is a few months old. Do you have a reference to an issue regarding ELK that was recently fixed?

PS: Normally I had asked to disable the VAAPI decoder to avoid mixing VAAPI and QSV (even though that is supposed to work. But there are no encoders detected for VAAPI and only h264 for MSDK, so there's clearly something wrong and first of all we'll need to take Docker out of the game when testing.

Thanks,
softworkz

 

[ivybridge0 1]

1 hour ago, softworkz said:

@ivybridge0 - Thanks for the logs?

Are those from a Docker image? The binary locations are different from the regular Debian installation package.
It would be great to have a log from a direct installation.

The Intel Media Driver that we are shipping is a few months old. Do you have a reference to an issue regarding ELK that was recently fixed?

PS: Normally I had asked to disable the VAAPI decoder to avoid mixing VAAPI and QSV (even though that is supposed to work. But there are no encoders detected for VAAPI and only h264 for MSDK, so there's clearly something wrong and first of all we'll need to take Docker out of the game when testing.

Thanks,
softworkz

 

Thanks for your reply!I tried to disable every VAAPI option in emby,hwacc is working fluently in docker now!!

In Debian/Ubuntu,I think both docker container and deb binary are able to access linux kernal,there is no much difference.

Thanks again for your patiently replys!!I just thanks for your hard work and patience,no other meaning XD.

 

Edited February 20, 2022 by ivybridge0

[softworkz 3348]

28 minutes ago, ivybridge0 said:

In Debian/Ubuntu,I think both docker container and deb binary are able to access linux kernal,there is no much difference.

If that would be true, we wouldn't have so many support requests about it...  

When it's all good for you now, then it'll be for me. But further investigation will require installation on the host OS.

Thanks,
sw

[ivybridge0 1]

According to Nyanmisaka---Jellyfin developer, focusing on video streaming via FFmpeg, https://github.com/nyanmisaka .

In https://www.chiphell.com/thread-2375777-1-1.html  , he also said:

Enabling Low-Power low voltage mode can improve Intel's transcoding and tone mapping performance. This function can be enabled directly under Windows, but under Linux, you need to manually add the kernel parameter i915.enable_guc=2 to use it. Processors before the 11th generation only support Low-Power H.264. Under Linux, for Intel graphics, it is recommended to use QSV instead of VAAPI. QSV usually provides higher throughput.

I think intel turn their new MSDK to support QSV,but VAAPI support is out of date for these new devices.We even need manually add the kernel parameter i915.enable_guc=2,its so complex for nomal users..To fix them,maybe we should wait updates/patches about intel-media and linux mainline kernal.

[softworkz 3348]

1 hour ago, ivybridge0 said:

Enabling Low-Power low voltage mode can improve Intel's transcoding and tone mapping performance

Yes, but not necessarily with equal or better quality. "Low-Power" means that encoding is done by a fixed-function block on the CPU die, while the "normal" mode works by employing a mix of hardware features like (video motion estimation) and GPU kernel shaders which can be loaded and are part of the driver (for VAAPI) or external (MSDK - has its own shader kernels). 
see "two modes": https://github.com/intel/media-driver#components-and-features

 

1 hour ago, ivybridge0 said:

processors before the 11th generation only support Low-Power H.264

This is not true. Almost all generations had support for both ways. There's also no change about that for future generations, only this specific platform (Elkhart/Jasper) doesn't support the "normal" mode, because it doesn't have the VME component in the GPU.
see: https://github.com/intel/media-driver#decodingencoding-features 

 

1 hour ago, ivybridge0 said:

Under Linux, for Intel graphics, it is recommended to use QSV instead of VAAPI. QSV usually provides higher throughput.

Yes, QSV usually provides better quality and performance in general, because it does a number of things differently compared to plain VAAPI use.

 

1 hour ago, ivybridge0 said:

I think intel turn their new MSDK to support QSV,

IIRC, MSDK always had it's own VME implementation (don't know whether as shaders or in software), and that's why it can overcome the limitation with the missing VME component without much effort.

1 hour ago, ivybridge0 said:

but VAAPI support is out of date for these new devices

No, it's not. It's only a hardware limitation, not a VAAPI limitation and it's not about "new" devices it's only about that special target platform (low cost, low power consumption).

 

1 hour ago, ivybridge0 said:

We even need manually add the kernel parameter i915.enable_guc=2,its so complex for nomal users..

I think the process is not that difficult. You need to run a single command only. When you do Linux, this shouldn't be an exciting task.
see #3: https://github.com/intel/media-driver#known-issues-and-limitations

 

1 hour ago, ivybridge0 said:

To fix them,maybe we should wait updates/patches about intel-media and linux mainline kernal.

To me, it rather looks like it is intentional to have it disabled by default, I wouldn't expect this to change. Interestingly, for ADL-P+, it IS enabled by default.
At some place they are calling this functionality "unsafe", so there most be something they are afraid of and hence the disabled-by-default. 
see: https://01.org/linuxgraphics/downloads/firmware?langredirect=1

 

What I would be curious about is

How does your HW detection log look like after you have set this kernel option?

Edited February 20, 2022 by softworkz

[ivybridge0 1]

35 minutes ago, softworkz said:

 

I think the process is not that difficult. You need to run a single command only. When you do Linux, this shouldn't be an exciting task.
see #3: https://github.com/intel/media-driver#known-issues-and-limitations

 

To me, it rather looks like it is intentional to have it disabled by default, I wouldn't expect this to change. Interestingly, for ADL-P+, it IS enabled by default.
At some place they are calling this functionality "unsafe", so there most be something they are afraid of and hence the disabled-by-default. 
see: https://01.org/linuxgraphics/downloads/firmware?langredirect=1

 

What I would be curious about is

How does your HW detection log look like after you have set this kernel option?

Thanks for your professional explains. I set the kernal option i915.enable_guc=3 three days ago,when I upgraded the kernal from ubuntu20.04lts original 5.13 to mainline 5.16.

I remember I see something in github,which is about setting guc=3 means to enable both huc and guc,then I did it.Nothing is wrong for now.

Here are logs when emby-ffmpeg transcoded normally with hwacc.

ffmpeg-transcode-36163a6d-5fc3-49b3-b85e-f3daf4677bd1_1.txt

[softworkz 3348]

Thanks.

According to the table, you need to set it to 2:

[softworkz 3348]

9 minutes ago, ivybridge0 said:

Here are logs when emby-ffmpeg transcoded normally with hwacc.

What I had actually meant was a hw detection log after setting the Kernel option, because then - by theory - we should also see VAAPI encoders being detected.
But this should be ideally tried with Emby being installed on the host OS to be sure about the results.

Though, if you're happy with your current state, you don't need to bother of course. I'd just be curious because we don't have any device available with those CPUs.

Thanks,
sw

[softworkz 3348]

9 minutes ago, softworkz said:

I'd just be curious

because we do have a brand new ffmpeg and low-power modes have just been added very recently for both, QSV and VAAP encoding of H.264 and to be honest, I never tried those yet.

[ivybridge0 1]

1 hour ago, softworkz said:

because we do have a brand new ffmpeg and low-power modes have just been added very recently for both, QSV and VAAP encoding of H.264 and to be honest, I never tried those yet.

Okay,I have tried to dpkg --install emby-beta-47024.deb.

Sorry,I m lazy to reset a new server XD.I just copy logs from /var/lib/emby-server/logs.And I didn't change the parameter about guc=3.

Here are logs.

embyserver.txt hardware_detection-63780978735.txt

[softworkz 3348]

Thanks again for the logs.

It's weird that there are almost no differences in the hw detection log. I've never seen that when comparing Docker vs. "bare metal" installations.

It's weird that no VAAPI encoders are detected. You said you had compiled all the latest drivers and Intel components and it worked that way.
What was actually working with that test - VAAPI or QSV?

[ivybridge0 1]

5 hours ago, softworkz said:

It's weird that no VAAPI encoders are detected. You said you had compiled all the latest drivers and Intel components and it worked that way.
What was actually working with that test - VAAPI or QSV?

Okay,let me show u.

Here is vainfo:

root@N5095:~# vainfo
error: can't connect to X server!
libva info: VA-API version 1.15.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri//iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_15
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.15 (libva 2.13.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.2.1 (7e357b4be)
vainfo: Supported profile and entrypoints
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileNone                   :	VAEntrypointStats
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSliceLP
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSliceLP
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSliceLP
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSliceLP
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointEncSliceLP
      VAProfileVP9Profile1            :	VAEntrypointVLD
      VAProfileVP9Profile1            :	VAEntrypointEncSliceLP
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointEncSliceLP
      VAProfileVP9Profile3            :	VAEntrypointVLD
      VAProfileVP9Profile3            :	VAEntrypointEncSliceLP
      VAProfileHEVCMain422_10         :	VAEntrypointVLD
      VAProfileHEVCMain444            :	VAEntrypointVLD
      VAProfileHEVCMain444            :	VAEntrypointEncSliceLP
      VAProfileHEVCMain444_10         :	VAEntrypointVLD
      VAProfileHEVCMain444_10         :	VAEntrypointEncSliceLP

When I run ffmpeg with qsv,

ffmpeg -hwaccel qsv -c:v vp9_qsv -i input.webm -vf hwdownload,format=nv12 -pix_fmt yuv420p output.yuv

output logs:

root@N5095:~# ffmpeg -hwaccel qsv -c:v vp9_qsv -i input.webm -vf hwdownload,format=nv12 -pix_fmt yuv420p output.yuv
ffmpeg version N-105688-g0d34e21282 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)
  configuration: --arch=x86_64 --disable-yasm --enable-vaapi --enable-libmfx
  libavutil      57. 21.100 / 57. 21.100
  libavcodec     59. 21.100 / 59. 21.100
  libavformat    59. 17.102 / 59. 17.102
  libavdevice    59.  5.100 / 59.  5.100
  libavfilter     8. 27.100 /  8. 27.100
  libswscale      6.  5.100 /  6.  5.100
  libswresample   4.  4.100 /  4.  4.100
WARNING: defaulting hwaccel_output_format to qsv for compatibility with old commandlines. This behaviour is DEPRECATED and will be removed in the future. Please explicitly set "-hwaccel_output_format qsv".
Input #0, matroska,webm, from 'input.webm':
  Metadata:
    COMPATIBLE_BRANDS: qt  
    MAJOR_BRAND     : qt  
    MINOR_VERSION   : 537199360
    ENCODER         : Lavf58.34.101
  Duration: 00:02:17.70, start: 0.000000, bitrate: 9644 kb/s
  Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn (default)
    Metadata:
      HANDLER_NAME    : Apple Video Media Handler
      TIMECODE        : 00:16:14:29
      ENCODER         : Lavc58.61.100 libvpx-vp9
      DURATION        : 00:02:17.704000000
Stream mapping:
  Stream #0:0 -> #0:0 (vp9 (vp9_qsv) -> rawvideo (native))
Press [q] to stop, [?] for help
Output #0, rawvideo, to 'output.yuv':
  Metadata:
    COMPATIBLE_BRANDS: qt  
    MAJOR_BRAND     : qt  
    MINOR_VERSION   : 537199360
    encoder         : Lavf59.17.102
  Stream #0:0(eng): Video: rawvideo (I420 / 0x30323449), yuv420p(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 745750 kb/s, 29.97 fps, 29.97 tbn (default)
    Metadata:
      HANDLER_NAME    : Apple Video Media Handler
      TIMECODE        : 00:16:14:29
      DURATION        : 00:02:17.704000000
      encoder         : Lavc59.21.100 rawvideo
[vp9_qsv @ 0x559d62b073c0] A decode call did not consume any data: expect more data at input (-10) 
    Last message repeated 1 times
[vp9_qsv @ 0x559d62b073c0] A decode call did not consume any data: expect more data at input (-10) 
frame= 4127 fps= 69 q=-0.0 Lsize=12535762kB time=00:02:17.70 bitrate=745750.3kbits/s speed= 2.3x    
video:12535762kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

with intel_gpu_top(picture 1),gpu was working.

 

Then,I tried 

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.webm -c:v h264_vaapi -b:v 2M -maxrate 2M output.mp4

output logs:

root@N5095:~# ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.webm -c:v h264_vaapi -b:v 2M -maxrate 2M output.mp4
ffmpeg version N-105688-g0d34e21282 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)
  configuration: --arch=x86_64 --disable-yasm --enable-vaapi --enable-libmfx
  libavutil      57. 21.100 / 57. 21.100
  libavcodec     59. 21.100 / 59. 21.100
  libavformat    59. 17.102 / 59. 17.102
  libavdevice    59.  5.100 / 59.  5.100
  libavfilter     8. 27.100 /  8. 27.100
  libswscale      6.  5.100 /  6.  5.100
  libswresample   4.  4.100 /  4.  4.100
Input #0, matroska,webm, from 'input.webm':
  Metadata:
    COMPATIBLE_BRANDS: qt  
    MAJOR_BRAND     : qt  
    MINOR_VERSION   : 537199360
    ENCODER         : Lavf58.34.101
  Duration: 00:02:17.70, start: 0.000000, bitrate: 9644 kb/s
  Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn (default)
    Metadata:
      HANDLER_NAME    : Apple Video Media Handler
      TIMECODE        : 00:16:14:29
      ENCODER         : Lavc58.61.100 libvpx-vp9
      DURATION        : 00:02:17.704000000
File 'output.mp4' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (vp9 (native) -> h264 (h264_vaapi))
Press [q] to stop, [?] for help
[mp4 @ 0x563fb9942f80] Application provided duration: -9223372036854775808 / timestamp: -9223372036854775808 is out of range for mov/mp4 format
[mp4 @ 0x563fb9942f80] pts has no value
Output #0, mp4, to 'output.mp4':
  Metadata:
    COMPATIBLE_BRANDS: qt  
    MAJOR_BRAND     : qt  
    MINOR_VERSION   : 537199360
    encoder         : Lavf59.17.102
  Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), vaapi(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 2000 kb/s, 29.97 fps, 30k tbn (default)
    Metadata:
      HANDLER_NAME    : Apple Video Media Handler
      TIMECODE        : 00:16:14:29
      DURATION        : 00:02:17.704000000
      encoder         : Lavc59.21.100 h264_vaapi
frame= 4127 fps=153 q=-0.0 Lsize=   33586kB time=00:02:17.67 bitrate=1998.5kbits/s speed=5.09x       
video:33568kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.053766%

with intel_gpu_top(picture 2),gpu was working,too.

[ivybridge0 1]

In addition,for some kernal error logs about bpfilter,I change kernal to ubuntu origin 5.13.0-30,and set guc=2 yesterday.