In the latest beta version, the release notes state that Intel Hardware Transcoding has been removed on FreeBSD, but at the same time has been improved on Linux!
Why is this? I have used Intel Hardware Transcoding on FreeBSD for a significant amount of time with no issues. The Linux KPI DRM infrastructure on FreeBSD exposes the same acceleration API anyway so this seems to be a very arbitrary removal.
An explanation would be appreciated, as this just looks like a further case of the FreeBSD version becoming worse than the linux one.
Unfortunately, the actual Intel userspace drivers required to provide hardware transcoding do not natively support FreeBSD. In order to provide this support, we had to apply patches maintained by the FreeBSD community. When these patches fell behind, it meant we couldnāt update to the latest versions of the drivers, which in turn meant that Linux users with newer Intel GPUs were unable to use hardware transcoding.
The number of Linux users with those newer Intel GPUs exceed the number of FreeBSD users with any Intel GPU (with kernel drivers set up for it, at least) by a sizable margin, so when given a choice between supporting one or the other, it was clear which we needed to prioritize.
If, in the future, the Intel drivers add first-class support for FreeBSD in the relevant codebases, we would be happy to re-evaluate this change. This primarily means that these two pull requests would need to be merged:
Note that the latter is currently blocked on the former.
Removing functionality on a platform is always a hard decision, and Iām very sorry that it was ultimately necessary here; we thank you for your understanding.
This is incredibly frustrating, and please donāt thank me for my understanding. I pay for Plex pass and youāve just dropped something I use pretty much daily without any warning or discussion whatsoever.
My view is thereās no point in providing a FreeBSD version of PMS at all if itās not going to be properly supported. Itās been on life support for a while. I think you need to make a decision.
I was pretty worried when I saw the ports go unmaintained. Bummer.
As somebody who doesnāt depend on hardware transcoding, Plex still works great on FreeBSD. So Iām glad the decision was ācontinue to support FreeBSD as a platformā.
Thanks for the detailed explanation regarding the removal of hardware-accelerated transcoding support on FreeBSD. While unfortunate, it is understandable. Iāve not used FreeBSD as a Plex server in a while, but I appreciate the option to do so in the future.
Whenever one of these FreeBSD vs. Linux conversations come up I wonder what things would look like today had the legal situation of 386BSD in the early 90s been different been different.
If weāre at the mercy of community volunteers to do the work Plex needs to keep FreeBSD up to dateā¦ and if those volunteers lose interestā¦ I canāt blame Plex for dropping features.
Instead of relying on volunteers we ought to put the screws to Intel to have BSD support put in from the beginning.
It works ok, but it is diverging with the linux version in terms of feature parity.
Thereās no sonic analysis support (which was always annoying but not a showstopper) and now no hardware transcoding (which is).
I donāt know what to do, I really really donāt want to go back to a linux distribution.
Also, why is plex packaging the Intel media drivers and not using the ones installed on the system? Surely that decision is causing/exacerbating this problem?
Honestly itās just one more reason for me to start moving the last few apps I had to my Linux docker VM.
While not ideal - I actually agree that if bsd makes up (letās say) 5% of the install base - itās completely reasonable choice vs them just axing support.
There are options around it (bhyve) or type1 virtualisation - or just move to bare metal linux/windows.
Given the lack of feature parity - previous issues/discussions with ongoing support - honestly surprised bsd is still supported.
For the record I do run truenas core (both virtualised and bare). But these days Iām warming more to letting it do it job and having something else for apps. Scale is a good alternative but if you have the know how, thereās better routes.
Plex provides static (or nearly-static) builds so that all of the required client libraries are included within the Plex download, instead of relying on system-provided libraries. This is common with commercially-packaged software.
But it wouldnāt work any better if Plex looked for a system library. Because Plex has been updated to use the newer Intel libraries, an older system library wouldnāt work anyway.
I believe Nvidia cards should still work? But I havenāt tried that in ages.
But they could certainly make it work with the system libraries on FreeBSD if they are installed rather than just not supporting it at all.
Look at the Linux world, thereās various versions of ffmpeg / VLC and other software that manage to do hardware encoding / decoding using a multitude of different versions of the Intel media driver via qsv/vaapi with no issues.
Bhyve isnāt a satisfactory solution and neither is moving back to Linux, which either requires Ubuntu (yuk) or dkms (which isnāt entirely reliable) for ZFS support. I moved to FreeBSD for better ZFS support and to escape the bloat in mainstream Linux distributions. Being forced to move back to Linux is highly unsatisfactory.
If we depended on the system driver, it would likely depend on other system libraries that would have symbol conflicts with our own copies, which may be a different version. We used to do this for OpenCL drivers on Linux, but it was extremely complex and resulted in severe stability problems.
There would also be ABI versioning issues; libva will only load a driver if it was built against an equal or older VAAPI version, which means that any time your local copy was ahead of ours, hardware acceleration would stop working.
If we instead linked against the system copies of libva and the related libraries, weād be tied to whichever versions of those happened to be present when we built; any updates that changed the SONAME fields would cause PMS to crash on startup.
Unfortunately, none of these options are tenable as a complete solution. We may try to provide a way for users to configure PMS to use their system-installed Intel drivers on FreeBSD in the future, but if so, it would be on an at-your-own-risk basis, as we would be unable to provide any guarantee of stability in that kind of environment. The best-case scenario would be for Intel to properly support FreeBSD as a target platform.
The tools youāre referring to are generally built by the distro maintenance team, rebuilt whenever ABI breaks occur, and have separate builds for different major versions of distros. This would not be practical for PMS.
Thanks for the detailed reply. That would be ok by me. āProbably/possibly working with an ability to get it workingā is far better than ānot at all working with no chance of getting it workingā.
Yeah, but I think we both know thatās not likely to happen.
Itās not a solution for me. That would mean doubling up on hardware - itās one or the other.
Sounds like the options are run Plex in a VM and pass the iGPU through to that, or install a Nvidia graphics card, if you donāt want to have a separate system for Plex.
Personally Iāve never used the hardware decoding (Xeon-D doesnāt have a GPU) but Iām still bummed to hear this news in regards to my next build. Scale still has a lot of bugs and the container system is a real step up in overhead.
Swapping over to SCALE is easy at least, but the jails do not translate over into anything directly usable. I made the jump a year ago, just left all the files there and you get asked to set up storage for apps and then cna start setting up kubernetes backed charts. Biggest rub is that there is no good direct replacement for custom jails. Everything is charts running docker containers.
Yeah, I considered using bhyve and gpu passthrough but I donāt like that solution at all. Thereās no guarantee that the issue will be resolved, thatās the problem.
Iām pretty much resigned to having to ādowngradeā to Ubuntu (as itās the only distro with built in ZFS support). This is a massive shame as FreeBSD is more simplistic and elegant than mainstream linux distributions in every way, but it is what it is.
The OS is just a tool at the end of the day, and linux is unfortunately a more suitable tool as a PMS host.
Iām just putting off going through the pain of doing it for as long as possibleā¦
My previous setup 18 months back was Ubuntu with PMS via docker which worked alright.
Iāve never had issues with firewalling on linux using iptables, if anything itās way more complex and fully featured than the majority of people will ever need to use.
Bummer.
