mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
CPU still high (around 100%) when Nvidia NVENC enabled #2016
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bingzhangdai on GitHub (Aug 6, 2020).
Describe the bug
System (please complete the following information):
To Reproduce
--gpu allparameter.topcommandExpected behavior
Low CPU usage.
Logs
Additional context
CPU is
Intel(R) Core(TM) i3-9300T CPU @ 3.20GHzand GPU isGeForce GT 1065.nvidia-smishows that GPU is not busy at all,Both encoding and decoding are enabled. CPU usage significantly drops compared to the situation where hardware acceleration disabled, but still not that optimal.
@bugfixin commented on GitHub (Aug 7, 2020):
I don't see any issues with the ffmpeg commands as logged.
It's not unusual for ffmpeg to still take a fair amount of CPU while using gpu-accelerated transcoding, as there are still tasks that are done by the CPU and ffmpeg doesn't throttle itself (e.g. in your logs, ffmpeg is also transcoding the audio track of the video to mp3, using the CPU). It does this as quickly as possible, which could certainly give the impression of high cpu usage, but with GPU acceleration, you'll see the transcoding proceeding much more quickly than if it was all on the CPU.
I guess my question is this: do you see significantly lower CPU loads while transcoding via other builds of ffmpeg, or with other but similar command line options?
@nyanmisaka commented on GitHub (Aug 8, 2020):
If your CPU has 6 cores, ffmpeg should takes 600% when it is fully loaded.
But 82.7% means ffmpeg takes 82.7% on ONE core instead of all cores like on Windows.
It involves driver, memory copy and ffmpeg stuffs.
@nyanmisaka commented on GitHub (Aug 8, 2020):
So It's not a BUG, I will close this for now.
@ThaChillera commented on GitHub (Aug 12, 2020):
@nyanmisaka I'm new to jellyfin, and have a similar experience: even when using directstream, ffmpeg is still at 100% cpu usage. Could this be due to it transcoding the audio to mp3? (even though the source has AAC, which is supported by the android app AFAIK)
@nyanmisaka commented on GitHub (Aug 13, 2020):
Directstream only changes the type of the container without re-encoding, similar to copying. It usually takes only a few seconds to complete. What you have encountered is a known issue.
@Zygisr commented on GitHub (Jan 28, 2021):
I've experienced very same problem (50% cpu usage and 100mb of gpu vram) using Jellyfin in a docker using Unraid. After fiddling around with settings I've noticed that in Jellyfins admin dashboard under playback>transcoding "Enable 10-Bit hardware decoding for HEVC" was unchecked. After ticking that check box jellyfins docker log promped that new version of ffmpeg have been discovered (4.3.1 if I recall corectly) and cpu usage droped to 10% and gpu vram grew to 900mb.
cpu XEON 2660 v2
gpu nvidia 1050ti
Hope that helps
@NokiDev commented on GitHub (Jan 29, 2021):
Hello, just to add a bit about this issue, when disabling NVENC the transcoding, will use all 4 cores of my virtual processor and transcoding will run fine, BUT when enabling NVENC, a single CPU core will be used and lead to less performant transcoding than without the card.
It is probably an ffmpeg issue (or by design??), or misconfiguration or a bug, I honnestly don't know, but it makes the use of NVENC impossible.
If someone passing by has solved this, it could be great, to add in the docs.
Meanwhile I'll try to investigate.
For the record if it helps, this is my setup :
It's virtualized ubuntu 20.04
with 4virtual cores,
a GTX 1660 GPU
Jellyfin version is 10.6.4
NVIDIA driver version is 450.80
And its running in an NVIDIA-docker container (image: linuxserver/jellyfin).
Thanks in advance
And by the way Thanks to all contributors / testers of this project, since the fork !
Edit :
My bad for not reading all the thread....
@Zygisr, I'll try what you proposed, and come by to give more insights about it :)
Edit2:
FFMPEG was already to the latest version 4.3.1.
Playing a bit with options, and unchecking hardware encoding seems to have fixed the issue here, but it's weird tough.
Checking / unchecking 10bits HEVC transcoding, did not changed anything to the transcoding performance.
@nyanmisaka commented on GitHub (Jan 29, 2021):
@NokiDev Hey! Can I get the transcoding logs?
Here are my thoughts before seeing the log.
First, The CPU usage will be higher if subtitle burn-in is being used.
Second, H264 High 10 videos is not supported by GPU.
Last, 10-bit -> 8-bit pixel format conversion is being done in CPU, which leads to some overhead during the data transfer between CPU<->GPU. Fortunately, this can be solved with #5107
@NokiDev commented on GitHub (Jan 29, 2021):
Hi @nyanmisaka, thanks for your answer.
Yes you can ! (See at the end).
For subtitle burning, maybe but it won't prevent the video from playing, I mean CPU usage won't be 100% just to burn subtitles
I'm not really sure about the two other points.
When you say H264 High 10 (bits ?) video is not supported ? you mean decoding or encoding ?
Hardware Decoding seems to work just fine.
It may be a 10bits -> to 8-bit pixel conversion then, but why when disabling, GPU transcoding / Hardware encoding, I do not observe the issue, anymore.
I took a look to your PRs, I'll try to find some time to test them soon.
In my tests I'm using a HEVC 4K video, but I also observe the same issue with 1080p HEVC videos.
The following are trancode logs of the transcoding, of the first seconds of the media :