-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FFmpeg only using one thread for transcoding. #67
Comments
What do you have set for transcoding thread count? From the admin panel -> Playback -> Transcoding thread count. Try setting this manually. What does Does ffmpeg use the correct number of threads when run by hand with |
Thanks for the response. I did change the thread count a few times to no avail. The last time I changed it to 16, and looking at the long command it htop it looks like the amount of threads is getting passed correctly:
However WCPU never goes above 250%. So I guess it is using more than one thread but not nearly as much as specified. When I manually run the long command from Jellyfin in my terminal I get the same roughly 250% WCPU and framerate as indicated in Jellyfin Playback Info. -threads 32 or 48 doesn't matter. FFmpeg is all black magic to me but this leads me to believe there's some bottleneck in the way Jellyfin commands FFmpeg to transcode video? |
It appears FFmpeg will use roughly the correct amount of threads where it can. The issue seems to be when converting an x264(?) file into an HLS (MPEG_TS segments) stream file it only uses 1-2 threads resulting in the buffering. I am unsure if this is because the library does not support multi-threading for that file-type (x264?->HLS). The command issued appears correct. Does adjusting the preset it uses change anything? It should change the quality but does it increase/reduce the buffering? |
Changing the preset from auto (which seemed to result to |
I currently have Windows and FreeBSD machines so to test the x264->HLS encoding I tried using the version of FFmpeg from WinGet. Using the command given to you by Jellyfin.
Mediainfo from FFmpeg (not something like MediaInfo.exe)
Parameters:
Results:
On a 6-core CPU (12 threads), Windows 10 reported ~40% CPU usage across the whole task. Similar results reported when using FFmpeg 6.0. Under Windows it heavy loads 6 threads (~80% utilization per) and almost ignores the other 6 (~10%). Changing Neither FreeBSD nor Windows use ALL of the resources available when doing this type of transcode even when I am trying the same test on FreeBSD with both the ports version and my static version. I will edit this post with my results EDIT:
The transcode is not able to stay ahead of playback under FreeBSD One of two things is going on: it either REQUIRES the newer extensions found in my deskop (e.g., FMA3 BMI2 AVX2) OR something is wrong with FFmpeg under FreeBSD. |
Yes. It is still on 6.0.1
A quick test with my static build showed it to be slightly slower (~5%) than the ports version. This is not unexpected despite it being version 6.1. It is a static binary. I make no changes to the patches that FFmpeg or its dependencies on FreeBSD use and just apply them directly. There are two major differences: Mine has no hwaccel support. It supports chromaprint. The former because hwaccel requires dynamically loading in something from a driver and the later because people wanted chromaprint and ports version of FFmpeg lacks it. I was going to try Plex's encoder but it has an extremely limited set of decoders/encoders, is unversioned (uses a git commit hash), and uses an old version of clang (11?!)
Nothing appears to be missed. I am both amused and annoyed that virtualized windows binary works better than native FreeBSD binary. Thank you for reporting and helping with troubleshooting! As of right now it appears to be an FFmpeg issue and not a jellyfin+FreeBSD issue. |
Hello, sorry if this isn't the right place to open an issue but I really can't wrap my head around it.
I've adjusted the amount of threads for transcoding in settings, saved and restarted my jail countless times to no avail.
I'm running TrueNAS on a server with 32 threads but only one thread is used which isn't nearly enough for fluid playback of higher resolution files when transcoded. Does anyone have any suggestions? Is there any way to troubleshoot this or see which flags are actually getting passed down to FFmpeg? Thank you in advance.
The text was updated successfully, but these errors were encountered: