![]() |
Intel iGPU Platform, QSV higher GPU usage than VAAPI? - Printable Version +- Jellyfin Forum (https://forum.jellyfin.org) +-- Forum: Support (https://forum.jellyfin.org/f-support) +--- Forum: General Questions (https://forum.jellyfin.org/f-general-questions) +--- Thread: Intel iGPU Platform, QSV higher GPU usage than VAAPI? (/t-intel-igpu-platform-qsv-higher-gpu-usage-than-vaapi) |
Intel iGPU Platform, QSV higher GPU usage than VAAPI? - buedi - 2025-01-11 Hi everyone, I run a 10400T with an UHD 630 on a Docker host which runs the Jellyfin Docker image. Works fine since many months, but today when checking GPU usage when transcoding a Video and checking with intel_gpu_top I have seen differences between using VAAPI and QSV. According to the documentation QSV seems to be preferred, because is it more performant than VAAPI, so I usually use QSV. But when transcoding a single 1080p video, intel_gpu_top shows me 60-100% GPU usage when using QSV and 30-35% usage when using VAAPI. Now performance is not equal usage. It could be of course that QSV is just much faster because it uses more GPU. But since the framerate of the Video is constant, I suspect that in my case both QSV and VAAPI have to transcode the same FPS and since QSV generates 3 times the GPU usage, it looks less performant to me. On first sight, I would switch to VAAPI in that case, because lower GPU usage = less power consumption. Also with QSV my iGPU seems to be maxed out and with VAAPI I could transcode up to 3 streams. But maybe I draw the wrong conclusion here. I wonder if this behavior is normal and other iGPU useres observe the same? RE: Intel iGPU Platform, QSV higher GPU usage than VAAPI? - Efficient_Good_5784 - 2025-01-11 Overall GPU utilization % isn't 1:1 as much as it seems. It can handle more than one transcoding session using QSV despite a single transcode taking at least 60%. You can test this out yourself by opening up multiple browser tabs and on each playing a different video that's transcoding. The important part of a transcode is that the transcode fps remains at or higher of the video's fps (to prevent buffering). You also have to keep in mind that energy used to produce work is measured as a unit over time. So if one method uses more energy at once but finishes the job faster, it's possible for it to use less watt-hours than the slower (and less energy-consuming) method. You have to measure how much watts your energy usage increases with QSV and see how long it takes for it to complete a transcode. Then the same for VAAPI. You finally compare how much watt-hours each used to see which is more efficient in your system. RE: Intel iGPU Platform, QSV higher GPU usage than VAAPI? - buedi - 2025-01-11 Thanks for your reply. The work over time you describe is interesting. I thought Jellyfin transcodes more or less in realtime what is needed (+ a bit more to prevent buffering). But now I observe that despite pausing the Video, the GPU utilization does not change. Does that mean that once a Video is started, Jellyfin (or more precise ffmpeg) encodes the whole file until it is finished, no matter how fast the Video is played back? Then it indeed seems to be another story of course. RE: Intel iGPU Platform, QSV higher GPU usage than VAAPI? - Efficient_Good_5784 - 2025-01-12 (2025-01-11, 08:13 PM)buedi Wrote: Thanks for your reply. The work over time you describe is interesting. I thought Jellyfin transcodes more or less in realtime what is needed (+ a bit more to prevent buffering). But now I observe that despite pausing the Video, the GPU utilization does not change. Does that mean that once a Video is started, Jellyfin (or more precise ffmpeg) encodes the whole file until it is finished, no matter how fast the Video is played back? Then it indeed seems to be another story of course.Yes, Jellyfin will transcode a video with ffmpeg as fast as it can. The limit will be on how fast the device (CPU/GPU) can encode the video. So when you start a video that will transcode, the entire video will get transcoded in one go and will be stored in your server's transcodes folder in chunks. These chunks of video are then sent to the client as requested. If you are streaming a video through Jellyfin's webUI player, you can open the playback info for the current stream. If you pay attention to the info of a transcode, you will see that the UI tells you how much fps your transcode is processing at by the system. Next to the fps, there is a multiplier. This number indicates how fast your transcode is progressing in comparison to the video's actual fps. You want the multiple to be 1.0x or higher to avoid any possible buffering. An example of this is the following. Lets say you have a video that is 24fps. If your transcode is progressing at an average of 30fps, that's 1.25x the fps of the video. This means that the transcode is happening 25% faster than what the actual video is playing at. If you do the math (1 / 1.25 = .8 ), you find out that your transcode will finish at 80% the time it takes to watch the video at its original speed of 24fps. Now, you can afford to drop below 1.0x without buffering provided you built up a good buffer by having the transcode progress be above 1.0x at other times of the process. Finally, there are some settings in Jellyfin's transcoding section of the dashboard that lets you limit how much a transcode progresses before being put on pause. I would check those out if they interest you. |