Login

Jey Forey

Hi and thank you in advance for taking time to help.

I just put together a brand new server with an intel ultra 7 265k/nvme ssd's to leverage the igpu quicksync and transcodes are running at around 24 fps which is far slower than I would have expected (with some video stuttering).

Jellyfin is running in docker (Main server hosting docker runs on Ubuntu Desktop), using the standard docker image and /dev/dri/renderD128 has been passed through and quicksync enabled (VAAPI also works but no performance improvement). Using the Jellyfin build of ffmpeg.

I see the following in the transcode logs for an example movie file:

Stream mapping:
Stream #0:0 -> #0:0 (hevc (hevc_qsv) -> av1 (av1_qsv))
Stream #0:1 -> #0:1 (eac3 (native) -> aac (libfdk_aac))

My basic understanding is it's correctly using hardware transcoding and I do see the video play back in the browser.

That being said, I would have expected far more fps given it's a modern cpu and quicksync is enabled?

frame= 145 fps= 24 q=-0.0 size=N/A time=00:00:05.83 bitrate=N/A speed=0.972x
frame= 157 fps= 24 q=-0.0 size=N/A time=00:00:06.33 bitrate=N/A speed=0.974x
frame= 165 fps= 24 q=-0.0 size=N/A time=00:00:06.66 bitrate=N/A speed=0.952x
frame= 177 fps= 24 q=-0.0 size=N/A time=00:00:07.16 bitrate=N/A speed=0.955x

I've tried ticking/unticking the 'prefer OS native' option and the intel low power mode settings, no changes in performance. Disabling hardware transcoding actually makes the transcoding much faster. I've attached some logs and a dump of intel_gpu_top, not sure if thats supposed to be showing higher video utilisation instead of Render/3D.
I'm completely out of ideas and hoping someone might be able to help? Hoping I haven't wasted thousands of $$ on this setup. Thanks so much.

**nyanmisaka** · Yesterday, 08:13 AM

ArrowLake iGPU requires a minimum Linux kernel version of 6.12. Is this already met?

Can you also run "sudo dmesg | grep i915" and check if the output contains FAIL or ERROR?

Jey Forey

(Yesterday, 08:13 AM)nyanmisaka Wrote: ArrowLake iGPU requires a minimum Linux kernel version of 6.12. Is this already met?

Can you also run "sudo dmesg | grep i915" and check if the output contains FAIL or ERROR?

Thank you for jumping in to help out, you might be my only hope with this.

I'm running Ubuntu 24.04.3 LTS which I think has kernel 6.14?, This is a new, clean install and I only added rustdesk remote desktop client, samba and docker.
I don't see any line items with error or fail running the command you mentioned:

3.323337] i915 0000:00:02.0: [drm] Found meteorlake (device ID 7d67) integrated display version 14.00 stepping D0
[ 3.324689] i915 0000:00:02.0: [drm] VT-d active for gfx access
[ 3.466026] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 3.466057] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[ 3.478710] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem Face-with-open-mouth

wns=io+mem
[ 3.484879] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/mtl_dmc.bin (v2.21)
[ 3.509566] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.36.0
[ 3.519359] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
[ 3.519361] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
[ 3.519608] i915 0000:00:02.0: [drm] GT0: GUC: RC enabled
[ 3.524026] mei_gsc_proxy 0000:80:16.0-0f73db04-97ab-4125-b893-e904ad0d5464: bound 0000:00:02.0 (ops i915_gsc_proxy_component_ops [i915])
[ 3.524451] i915 0000:00:02.0: [drm] GT1: GuC firmware i915/mtl_guc_70.bin version 70.36.0
[ 3.524452] i915 0000:00:02.0: [drm] GT1: HuC firmware i915/mtl_huc_gsc.bin version 8.5.4
[ 3.776609] i915 0000:00:02.0: [drm] GT1: HuC: excessive auth time: 98ms! [status = 0x0000C1DC, count = 0, ret = 0]
[ 3.776618] i915 0000:00:02.0: [drm] GT1: HuC: excessive auth time: [freq = 100MHz, before = 100MHz, perf_limit_reasons = 0x01000100]
[ 3.776620] i915 0000:00:02.0: [drm] GT1: HuC: authenticated for clear media
[ 3.779713] i915 0000:00:02.0: [drm] GT1: GUC: submission enabled
[ 3.779717] i915 0000:00:02.0: [drm] GT1: GUC: SLPC enabled
[ 3.779944] i915 0000:00:02.0: [drm] GT1: GUC: RC enabled
[ 3.787182] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized
[ 3.831533] [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1
[ 3.868677] fbcon: i915drmfb (fb0) is primary device
[ 3.868680] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[ 3.868626] snd_hda_intel 0000:80:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 3.926970] i915 0000:00:02.0: [drm] GT1: Loaded GSC firmware i915/mtl_gsc_1.bin (cv1.0, r102.1.15.1926, svn 1)
[ 3.948107] i915 0000:00:02.0: [drm] GT1: HuC: authenticated for all workloads

Jey Forey

nvm comment outdated, still same problem, quicksync has this weird fps cap and underperforming badly. Appreciate any further help with this.

**nyanmisaka**

This is quite strange, especially since ArrowLake has been available for a while and this is the first report of performance limitations.

Can you run the following command to test which stage of the transcoding process is limiting performance? Observe and report the FPS.

Code:
# Test Decoder

/usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv -noautorotate -c:v hevc_qsv -i file:"/movies/The Amateur [2025] tt0899043/The Amateur [2025] tt0899043.mkv" -noautoscale -an -sn -dn -vframes 5000 -f null -

# Test Decoder+Filter

/usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv -noautorotate -c:v hevc_qsv -i file:"/movies/The Amateur [2025] tt0899043/The Amateur [2025] tt0899043.mkv" -noautoscale -an -sn -dn -vf "setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,vpp_qsv=format=nv12" -f null -

# Test Encoder

/usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -f lavfi -i nullsrc=s=3840x1600,format=nv12 -codec:v:0 av1_qsv -preset veryfast -b:v 15634401 -maxrate 15634401 -bufsize 31268802 -profile:v:0 main -level 53 -g:v:0 72 -keyint_min:v:0 72 -vframes 5000 -f null -

You can also use this command to update the jellyfin-ffmpeg7 package and media-driver in Docker to the latest versions and see if there's any performance difference.

Code:
sudo docker exec -it jellyfin apt update

sudo docker exec -it jellyfin apt upgrade -y jellyfin-ffmpeg7

Jey Forey

(Yesterday, 01:40 PM)nyanmisaka Wrote: This is quite strange, especially since ArrowLake has been available for a while and this is the first report of performance limitations.

Can you run the following command to test which stage of the transcoding process is limiting performance? Observe and report the FPS.

Code:
# Test Decoder /usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv -noautorotate -c:v hevc_qsv -i file:"/movies/The Amateur [2025] tt0899043/The Amateur [2025] tt0899043.mkv" -noautoscale -an -sn -dn -vframes 5000 -f null - # Test Decoder+Filter /usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv -noautorotate -c:v hevc_qsv -i file:"/movies/The Amateur [2025] tt0899043/The Amateur [2025] tt0899043.mkv" -noautoscale -an -sn -dn -vf "setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,vpp_qsv=format=nv12" -f null - # Test Encoder /usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -f lavfi -i nullsrc=s=3840x1600,format=nv12 -codec:v:0 av1_qsv -preset veryfast -b:v 15634401 -maxrate 15634401 -bufsize 31268802 -profile:v:0 main -level 53 -g:v:0 72 -keyint_min:v:0 72 -vframes 5000 -f null -

You can also use this command to update the jellyfin-ffmpeg7 package and media-driver in Docker to the latest versions and see if there's any performance difference.

Code:
sudo docker exec -it jellyfin apt update sudo docker exec -it jellyfin apt upgrade -y jellyfin-ffmpeg7

Can't tell you how much I appreciate your help, I'm stuck here with a paperweight server without your assistance so i'm very grateful.

The docker jellyfin apt update/upgrade commands were throwing errors gaining access to the directory to read/write the temp files so I went into the container and ran 'jellyfin apt update' and 'jellyfin apt upgrade -y jellyfin-ffmpeg7' which I assume does the same thing, It's showing the version in jellyfin transcoding logs as follows:
ffmpeg version 7.1.1-Jellyfin Copyright © 2000-2025 the FFmpeg developers

Unfortunately this did not improve things, still seeing sub 30 fps.

The first 15 minutes of running the test you provided above is also showing similar fps unfortunately (around 40 fps) but I'll keep watching and report back.

**nyanmisaka** · Yesterday, 03:02 PM

The three commands correspond to different hardware modules. Please report their FPS separately.

Jey Forey

Code:
/usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv -noautorotate -c:v hevc_qsv -i file:"/movies/The Amateur [2025] tt0899043/The Amateur [2025] tt0899043.mkv" -noautoscale -an -sn -dn -vframes 5000 -f null -

45 fps

Code:
/usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv -noautorotate -c:v hevc_qsv -i file:"/movies/The Amateur [2025] tt0899043/The Amateur [2025] tt0899043.mkv" -noautoscale -an -sn -dn -vf "setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,vpp_qsv=format=nv12" -f null -

48 fps

Code:
/usr/lib/jellyfin-ffmpeg/ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD128,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -f lavfi -i nullsrc=s=3840x1600,format=nv12 -codec:v:0 av1_qsv -preset veryfast -b:v 15634401 -maxrate 15634401 -bufsize 31268802 -profile:v:0 main -level 53 -g:v:0 72 -keyint_min:v:0 72 -vframes 5000 -f null -

24 fps

Also included a log of test 1 and 3 for you to verify in case that's helpful, didn't include 2 as it went for over an hour but I didn't grab the logs so I didn't re-run it. Looks like it's all slow... What in the world could be causing this slowness?

**nyanmisaka** · Yesterday, 03:55 PM

This indicates that all three video components in the transcoding process are performing below expectations. I suspect this is related to clock or driver issues.

Can you disable the Intel iGPU's power saving mode RC6 or something similar in the BIOS to see if that changes anything?

Jey Forey

(Yesterday, 03:55 PM)nyanmisaka Wrote: This indicates that all three video components in the transcoding process are performing below expectations. I suspect this is related to clock or driver issues.

Can you disable the Intel iGPU's power saving mode RC6 or something similar in the BIOS to see if that changes anything?

I have the MSI Mag Z890 Tomahawk Wifi motherboard, they have a search function for settings and unfortunately there were no results for RC6 or Power Saving that are related, I also went looking through the settings manually but could not see a power related option for the iGPU.
Just ran a CPU bechmark (Geekbench) and the CPU was at or above the average.

Hoping it's not a limitation of this motherboard that quicksync would underperform.

I tried disabling RC6 within linux by using the following in the grub config but that didn't work either:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_dc=0"

You mentioned a potential driver issue as well?

Login

Username/Email:
Password:


Or login with a social network below

Login

Username/Email:
Password:


Or login with a social network below

Terribly slow transcode on modern Intel 265k iGPU