drm and dri exposed but no hardware acceleration #56
Comments
|
Everything looks like it SHOULD be working. |
|
Hi @Thefrank When attempting to use the default FFmpeg (6.0) on FreeBSD, an error occurs
The log displays the following command invocations: As we can see, |
|
It appears that the following configuration is not being passed to FFmpeg. I am unsure how the device node path is handled by Jellyfin.
|
|
@gmsotavio |
|
One final thing to try: |
@Thefrank, thank you for your patience and support. As you have suggested, I have been trying to use FFmpeg with the following command to utilize VA-API for hardware acceleration: However, I encountered the following error message during the process: |
For that test, I encountered the following error message: and |
|
I believe there might be an issue with FFmpeg. Jellyfin provides a package called |
|
@gmsotavio I don't have any hardware to test it on sadly. If you want to try a different (but not jellyfin's version) of FFmpeg, I make a static binary for it: https://github.com/Thefrank/ffmpeg-static-freebsd . I doubt it will work with hwaccel as that is very difficult to do via static linking |
|
@Thefrank, I conducted some additional tests tonight. I attempted to isolate Jellyfin from FFmpeg. I took one of the movie files I was trying to play and manually performed an HEVC -> H.264 conversion using only FFmpeg with options for decoding using hwaccel@vaapi. The command below worked:
As you can see in the image, the processor load is very low during the transcode, confirming the use of the iGPU:
Possibly, some of the filter parameters passed by Jellyfin are causing the issue. The thing is, it's not about problems with drivers or even issues with FFmpeg. Everything should be working. I'll be investigating further the parameters that Jellyfin passes to FFmpeg. For instance, if I attempt to remove the parameter As we can see in the Jellyfin command issued to FFmepg, the filter selection is a bit complex and harder to grasp:
For now, I appreciate the help and time dedicated to assist me. |
|
@Thefrank I managed to make it work (manually). I'm almost there. Params that Jellyfin passes to lffmpeg:
After making several modifications, the results are as follows:
What I have changed
Aditionally, It will be necessary to add Now, I need to find a way to modify the parameters passed to lffmpeg before they are fed to the ffmpeg executable. I'm unsure if this is possible. |
|
If jellyfin assumes that you are using FFmpeg v5 instead of v6 it might explain some of the args being passed oddly. The API between 4->5->6 are all slightly different |
|
Hi @gmsotavio, |
|
Hello @johndodigie, I am still investigating the cause of the problem. Here are some clarifications:
My two assumptions when analyzing the Jellyfin source code are:
Currently, I am using software transcoding, but I would very much like to enable hardware transcoding, as I have already proven that it works perfectly in FreeBSD jails and would significantly alleviate the load on my processor. |
|
I should have some free time after the holidays to deep-dive this issue. A quick glance seems to point at requiring some source changes to support VAAPI. As pointed out, it already does a good job of determine which version of FFmpeg is being used; it should be able to use This (hopefully) is just an |
|
https://github.com/Thefrank/jellyfin-server-freebsd/releases/tag/jellyfin-vaapi-test Let me know if that resolves the issue. If it does, I will work on QSV next. |
|
Thank you for sharing. I'll test your modifications and promptly share the results with you. I appreciate the efforts you've put into assisting us with this. |
|
In the tests I conducted, I did not notice any difference. The parameters that Jellyfin passes to ffmpeg are exactly the same. I really don't know if I might be doing something wrong. However, upon reviewing the code again, I came across this: var isVaapiFullSupported = isLinux && IsVaapiSupported(state) && IsVaapiFullSupported();It seems that Vaapi is only considered fully supported if the system is Linux. I don't know if this could be influencing the issue we are facing. var isLinux = OperatingSystem.IsLinux();Note that the hardware image scaling filter private bool IsVaapiFullSupported()
{
return _mediaEncoder.SupportsHwaccel("drm")
&& _mediaEncoder.SupportsHwaccel("vaapi")
&& _mediaEncoder.SupportsFilter("scale_vaapi")
&& _mediaEncoder.SupportsFilter("deinterlace_vaapi")
&& _mediaEncoder.SupportsFilter("tonemap_vaapi")
&& _mediaEncoder.SupportsFilter("procamp_vaapi")
&& _mediaEncoder.SupportsFilterWithOption(FilterOptionType.OverlayVaapiFrameSync)
&& _mediaEncoder.SupportsFilter("hwupload_vaapi");
}Note that these are just observations. I do not know if this is the root of the problem, but they might indicate a potential issue. I am not an expert in drm, ffmpeg, or related subjects. |
|
@gmsotavio The changes I tried were to add If the Jellyfin version of FFmpeg has additonal filters, it might be why the checks are also failing but looking at the configure for FFmpeg 6.1 all of the same filters and filter options appear in it that jellyfin tries to find. I should have some more time over the weekend to dig into this. |
|
Did you get any further with this, I'm pretty keen to get this working |
I rebuild the server and web parts with some more patching if you want to try it: https://github.com/Thefrank/jellyfin-server-freebsd/releases/tag/jellyfin-vaapi-test |
|
unfortunately it didn't work from the logs it seems to have decided not to enable hardware acceleration |
|
That looks like it is not even trying to make any hw decoding. I do not have any hardware that does hardware acceleration so it is rather hard to debug what it is seeing. does what does your startup look like? Here is mine where it just tests the results of pinging @gmsotavio if you are still around and want to try another build |
i wonder if my issue is the plugin repo not resolving - which is weird, the jail has raw sockets turned on and has perfectly working network otherwise. i've also been trying to get opencl working to eliminate that, although i have tone mapping turned off so it shouldn't need it. I can't figure out why opencl doesn't want to work (even outside the jail) |
|
host resolves fine inside the jail - |
|
@rbev DNS name resolution errors (and some other network errors) can be caused by jellyfin's library monitoring. Try turning that off The good news is that jellyfin DOES see a valid VAAPI device so it should be able to use it as a VAAPI device. Same with ffmpeg it does appear to see a VAAPI device. Neither jellyfin nor ffmpeg see a valid opencl device :( |
|
Yeah i posted some logs on the freebsd forums puzzled about why i couldn't get opencl working on this igpu. In case it helps - here's my transcoding settings: |
|
I did another restart and it looks like i get a clean startup now no plugin errors - but still not hwaccel |
|
Hrm. I have no idea why it does not even bother to use hwaccel despite detecting it. For your opencl try |
|
Same as above, vaapi works fine and then it prints this error for opencl: and its the same thing outside the jail running as root |
|
|
clinfo does not even see the device so things like ffmpeg and jellyfin wont see it either. Does jellyfin try to use VAAPI at all in the logs? I am confused why it does not even try to use vaapi |
|
I see absolutely nothing in the logs about it attempting to use vaapi - it seems like it's deciding it can't use it. and the transcode logs don't mention the drm device or vaapi outside of the printout of compile flags on startup (which i've pasted previously) |
|
i can probably enable debug logging and restart - let me look up how to do that edit: nothing enlightening in the debug logs |
|
Doing some more reading of the jellyfin code it looks like the lack of openCL is my problem from what i can tell here it falls back to a software decoding path unconditionally if there is no openCL available, and it's not doing the extra branch on line on 4425 to add the hardware encode to the end of it. I'll spend some more time working out why opencl isn't working for me |
|
I've started to lose hope - I've narrowed my OpenCL issue down to this: FreeBSDDesktop/kms-drm#197 which appears to be a problem I can't fix myself |
|
Try Rusticl instead as described in freebsd/freebsd-ports@d8990eff958b |
|
ok, that fixes clinfo but it doesn't change ffmpeg's behaviour |
|
I think there is a typo in the jellyfin.diff patch that is preventing hardware acceleration from being detected properly. When Jellyfin checks if the operating system is Linux, it uses Rephrasing this using De Morgan's (https://en.wikipedia.org/wiki/De_Morgan%27s_laws), This statement becomes To fix this, The patch lines containing For the patch file itself, line 17 adds I don't have time to build the code with the fixes myself but I believe this should be enough to get VAAPI working. |
|
@MACVTi good catch! that diff is a bit out of date and does contain that logic flaw. The newest experimental binaries from ~2wk ago should have corrected logic. Back in college I took a whole course on logic so it is rather embarrassing that it happened in the first place >.< edit: but yes |
|
Don't worry, I had to do some googling to remember it too! 😄 I'm only after seeing the VAAPI test release there now after you mentioned that test build in your previous comment. I've tested it on my computer and I can confirm that VAAPI is working for my AMD Raven Ridge GPU (Integrated graphics on AMD 3200G) on FreeBSD 14 with drm-515-kmod and the Mesa Gallium driver 24.0.4. The device is also correctly detected in the logs.
Is it possible to get this change merged into the binary that is distributed on the FreeBSD Ports or do you want testing from the other available VAAPI devices first? Looking at the logic of Jellyfin, they should work if the AMD GPU works, but I can understand if you'd prefer testing each device before adding it. (I posted this by accident on my work account originally in case you see a duplicate comment @Thefrank ) |
|
A couple of reason: I want to make sure that I have correctly applied all of the patches before pushing out a new binary so it will remain a test until I get some feedback. QSV should work for Intel CPUs. The test version is based off the upstream master branch which should be an actual release soon(tm). The 10.8.x branch and tags throw NuGet security errors when building. These are easy to fix by bumping the versions of the depneds but I don't want to break something else while doing so. |
|
That's understandable. Now that you say it, the version is 10.9.0, not 10.8.9 as I first read it. The release date on the Github page threw me off again! :) If you want, I probably have a few Intel computers lying around so I should be able to try VA-API and QSV support for Intel in the next day or two if that's any help? I think that covers most of the configurations of HW Acceleration thats on FreeBSD anyway? (Maybe the raspberry pi but I'm not sure if drivers are available for FreeBSD). If you have a list of configurations that you'd like to get feedback on, I could see what I could do. Also for my own curiosity, do you think there'd be much work in converting the port to be a true source port? I'm not too familiar with .NET myself to be honest. It would just be handy as we could submit pull requests with code we could test rather than having to hassle you! |
VAAPI and QSV are the ones mostly used by other mediaplayers on FreeBSD so those would be the best/first to try. If there is demand for it, I can look at CUDA and Vulkan.
It can be rather tedious to get setup initially. Maintaining is easier but requires manually updating all of the version numbers from the NuGet packages it uses. You can look at https://github.com/freebsd/freebsd-ports/tree/6dbb66a12e23526f7dc4f43f8c2cf7ae58f4be9f/devel/msbuild or https://github.com/Thefrank/freebsd-dotnet-sourcebuild/blob/main/PortWIP/dotNET8/Makefile if you want some examples. ASLR needs to be turned off and This SOUNDS very complicated but it is mostly just a massive time sink.
I need to get something setup to make contributions outside of documentation updates easier. |
|
@gmsotavio I now have freebsd 14.1, intel i7-4770k, Intel HD Graphics 4600, and after switching to another console, the VAAPI hardware acceleration breaks down and the vainfo output looks like this: More details - https://forums.freebsd.org/threads/switching-between-tty-consoles-breaks-intel-hardware-acceleration-i915kms.96348/ |
Hello guys,
I would like to share my situation. I've been trying to enable hardware acceleration for my Jellyfin server using the instructions provided in this file Installation_TrueNAS_GUI.md. While I can see the
drianddrmnodes inside my jails, videos requiring transcoding simply do not load. Below are the configurations of my system and the procedures I've followed:System Configuration
FreeBSD 13.2-RELEASE amd64pciconf -vlreturns:Procedures Performed (Host)
Jail Creation and Jellyfin Installation
Created the Jail with
vnet=onandallow_mlock=1:Installed Jellyfin inside the Jail:
drm-kmod Installation and Module Loading
Installed the
drm-kmodpackage:Added
i915kmsto thekld_listin/etc/rc.conf:Rebooted the system to load the new modules.
Verification of Loaded Modules and Device Nodes
i915kmsanddrmwere loaded usingkldstat:Verified the creation of the nodes
/dev/drmand/dev/dri:Devfs Rules Configuration
Created the file
/etc/devfs.ruleswith the following content:Restarted the
devfsservice:Applied the ruleset 10 to the Jellyfin Jail:
Inside the Jellyfin Jail
Properties of the Jellyfin jail:
Starting the Jellyfin jail:
Installing the packages:
Versions of the installed packages:
FFmpeg config:
Confirming that the jail can see the
drmanddrinodes:Result of the command
vainfo:Added the user
jellyfinto the groupvideo:Created the file
/usr/local/bin/lffmpegwith the following content:root@jellyfin:~ # cat /usr/local/bin/lffmpegAdded execute permission to the file
/usr/local/bin/lffmpeg:root@jellyfin:~ # ls -la /usr/local/bin/lffmpeg:Playback settings on Jellyfin web:
When trying to load a movie, I notice that it never leaves the loading screen (it keeps spinning indefinitely with the loading circle):
The transcode log:
More logs:
I appreciate any tips you may have to offer. Thank you in advance.
The text was updated successfully, but these errors were encountered: