After switching from libav to FFmpeg, the HandBrake developers quickly added NVENC encoder support to HandBrake. You can now select both NVENC for H.264/H.265 encoders in the drop down menu or with the command line interface:
With most GPUs I tried, even setting the slowest and costly preset results in the video engine not being fully utilized. Encoding times are cut to ~25%.
Awesome! No more ffmpeg command line black magic. You can now comfortably create your preset in the HandBrake gui and then use HandBrakeCLI through SSH on your awesome Plex Media Server. The build is available for both CentOS/RHEL 7 and Fedora.
Just a small post to notify that Plex Media Player package is back. Now it does not require Conan or Python anymore for building, and you can just build it using standard tools, the dependency issues between the Plex binary packages have been resolved.
Also the TV interface is now improved, on par with what Plex currently offers for other platforms, and it’s much better in terms of performance. I also don’t get anymore the weird positioning of the PIN window.
You can still install plex-media-player-session and do the minimal configuration required (extracted from /usr/share/doc/plex-media-player/README.Fedora):
If you are planning to do an HTPC installation, and would like to have Plex Media Player starting instead of the login screen the moment you boot the
device, execute the following commands as root:
The first command installs the required files (services, targets and PolicyKit overrides). The second command instructs the system to load by default the Plex Media Player target; that is X and the player just after. The third command allows the system to start the X server as the Plex Media Player user, otherwise only users logged in through a console or root can start it.
If you want to go back to your normal installation (let’s say Gnome), then revert back the changes:
The package is available for all supported Fedora releases.
Also, on a side note, HandBrake has been updated again to track the master branch, as it now uses FFMpeg 4 and no longer libAV 12. This could probably lead to other improvements, like NVENC/CUDA support, more formats, etc.
The whole multimedia repository has been rebased with recent releases, and it now features FFmpeg 3.2 as the foundation. Most of the programs that suppport some Nvidia integration are now enabled and compiled with support for CUDA/NVENC/CUVID; leveraging the previous reorganization of CUDA 8 in the various subpackages.
This means that all the Nvidia packages are now included in the repository as well, so if you have an Nvidia card and you are interested in both repositories, you can just have the multimedia repository enabled. If you still just want the Nvidia stuff (as enabled in Fedora 25) then it’s still available as a separate repository; and that will not change.
Why all of this? Because I can’t keep them separated anymore. The Nvidia repository can exist on its own, but the multimedia one can’t, due to the dependencies and the constant rebases (also of main Fedora and CentOS/RHEL packages). You can use the Nvidia repository alone, if you just need that, or use the multimedia one if you need everything else.
The repository is now exposed also at this URL, and contains Delta RPM support:
All repository files and configurations have been updated, so this means that in the future this would be the place where the metadata and repository information will be placed and any new installation will get the repository from there. If you are reading this blog post, you can switch now. I will add a negativo17-release package soon, along with a few mirrors; I’m sorting out the details now with the mirror owners.
FFmpeg and other CUDA enablements
To make proper use of the Nvidia hardware encode features (NVENC/CUVID) and CUDA kernel support (i.e. Blender GPU rendering) in the various programs you need the Nvidia driver installed (nvidia-driver-cuda), and for Nvidia Performance Primitives you require the CUDA driver and the NPP library package (cuda-npp).
This means that for most people NOT requiring CUDA support or not using an Nvidia video card, the following 2 packages will be installed anyway:
$ ls-alghs nvidia-driver-cuda-libs*.rpm cuda-npp*.rpm
92M -rw-r--r-T. 1 mock 92M Nov 1612:35 cuda-npp-8.0.44-6.fc25.x86_64.rpm
22M -rw-r--r-T. 1 mock 22M Nov 1915:00 nvidia-driver-cuda-libs-375.20-1.fc25.x86_64.rpm
$ ls -alghs nvidia-driver-cuda-libs*.rpm cuda-npp*.rpm
92M -rw-r--r-T. 1 mock 92M Nov 16 12:35 cuda-npp-8.0.44-6.fc25.x86_64.rpm
22M -rw-r--r-T. 1 mock 22M Nov 19 15:00 nvidia-driver-cuda-libs-375.20-1.fc25.x86_64.rpm
Both packages contain just libraries, and they will be on your system as much as other libraries for multimedia codecs you don’t actually need. Example, with most multimedia programs you will get Xvid libraries for opening Xvid files, even though the format is pretty much abandoned. Having them installed does not enable any unwanted feature in your system. Also, NPP libraries should decrease 50% in size in one of the next CUDA updates, being the monolithic version of the library being deprecated in favor of split functionality.
There are some patches being evaluated to make those libraries loadable at runtime, but they have not been merged yet and there’s no guarantee that they ever will. Also, they are available for FFmpeg but not for all the other programs where support has been enabled for; so depending on your installation, you might get them anyway.
As of today, from the Multimedia repository the following programs have been enabled with some Nvidia hardware enablement:
MPV (video decoding through CUVID)
FFmpeg (encoding through NVENC, decoding through CUVID and filtering through CUDA NPP)
Avidemux (encoding, through NVENC)
GStreamer (NVENC plugin)
Blender (GPU rendering)
VDPAU for decoding was already enabled where possible.
Of course anything that is using FFmpeg (like the GStreamer plugins) could theoretically benefit from the same enablements as in FFMpeg:
A note on Blender: Blender with CUDA support is still at 2.78 built with CUDA 7.5, and not 2.78a built with CUDA 8; so no Nvidia Pascal GPU support. I’m working on it.
GNOME Software integration
Most of the graphical software is now enabled in GNOME software for Fedora 25, meaning that you can search stuff with a keyword and that if you have the repository enabled it will just pop-up:
There is still some packages that need AppStream metadata, but that will come.
As usual, feedback, bugs and comments are welcome.
Fedora 24 repositories have been available for quite some time now, but here is the official statement that everything should be supported out of the box.
As part of the repository availability, I would like to say that starting from Fedora 24, the repositories are self-sustained and do not require RPMFusion to be enabled. I try to preserve compatibility between the two, so if you step into any problem just open an issue to the specific package on Github, send me an email or drop a message in the comment section of the various pages. Please note that “compatible” means that actually you shouldn’t get any conflict when installing packages, and not that I will not overwrite/obsolete the packages provided in the other repositories.
CentOS/RHEL 7 repositories have been available stand alone since the beginning and do not require external repositories to be enabled. Again, if an RPMFusion (or whatever will be mainstream at the moment) CentOS/RHEL 7 repository will appear, I will try to be compatible with it.
Scope of support
My basic idea is to have what I’m using normally everyday as a package in Fedora, enabling software combinations that would be otherwise impossible to distribute in official repositories due to license/patent issues. This for example includes NVENC (Nvidia Encoder) FFMPeg enabled builds that I use almost everyday.
Being a daily CentOS/RHEL 7 user I also want to support the latest and gretest of the same software on that platform, which also means rebuilding some official CentOS/RHEL 7 packages like VP8/9, VDPAU and VA-API libraries.
Due to the various package builds being different (or simply containing newer software releases) from what the other repositories offer, I also try to be completely independent, you can basically install the operating system and just use my repositories.
Build system changes
The (internal at the moment) build system uses Github as its primary system for storing the package information. There is a Negativo17.org public organization where all the work goes, so if you want to look at the development or the SPEC files, just browse to Github. If you have an issue or proposed change as well, you’re welcome to open an issue or create a merge request in the specific package Git page.
Skype Web Pidgin plugin
The Skype repository used to contain purple-skype for Fedora and CentOS/RHEL distributions which at the time required an installed Skype to work. Now, I helped a new Fedora contributor into integrating the newly developed Skype web plugin, which is based on the Skype web client. The package in Fedora obsoletes and provides correctly the skype4pidgin plugin and as such I don’t need to provide anything else in the repository.
The installation instructions have been updated to reflect this.
Skype is available only in 32 bit format, so on a 64 bit a 32 bit client will always be installed. Since the merging with MSN, the HTML welcome screen requires a 32 bit WebKit GTK build to start. This is not included in the 64 bit only CentOS/RHEL 7 repositories; so for this reason, if you are running CentOS/RHEL 7, it requires the multimedia repository to be enabled and have the dependency solved. This used to be self-contained in the Skype repository, but this is no longer feasible for me to mantain considering there is a different rebuild of WebKit GTK in the Multimedia repository.
Spotify Client
The Spotify repository used to contain FFMpeg for CentOS/RHEL distributions and a requirement on FFMpeg’s RPMFusion as a Fedora dependency. FFMpeg is no longer included in the CentOS/RHEL 7 repositories so the multimedia repository has to be enabled to have the dependency solved. As for Skype, this no longer feasible for me to mantain considering there is a different rebuild of WebKit GTK in the Multimedia repository.
Here as well the installation instructions have been updated to reflect the change.
aKMOD kernel module packages
The kernel binary module packages generated by aKMOD are now compressed with XZ, like in the original Fedora kernel packages that contain kernel modules. I’ve become a DKMS contributor, so, as time permits, I will add the same functionality to DKMS for Fedora distributions.
At the moment, this applies to Nvidia and X-Pad kernel modules.
Gstreamer plugins and multimedia libraries
The Multimedia repository now provides GStreamer (1.0) plugins for Bad, Ugly, libAV and VA-API plugin bundles with all options enabled. This is split into the following GStreamer runtime packages:
gstreamer1-plugins-bad
gstreamer1-plugins-ugly
gstreamer1-vaapi
gstreamer1-libav
gstreamer1-plugins-bad-fluidsynth (pulls in the whole FluidSynth distribution)
gstreamer1-plugins-bad-nvenc (x86_64 only, pulls in the Nvidia binary driver; and at the moment it does not work properly)
They all have an Epoch of “1”, due to the various reasons explained at the top. They are not yet available for CentOS/RHEL 7 due to time constraints; I will try to prepare them in the next weeks.
Fedora 24 OpenH264 repository
A note on the Fedora 24 OpenH264 repository. As described in its wiki page, there is an extra repository that can be enabled directly in Fedora 24 that allows you to install OpenH264, its relevant Gstreamer 1.0 plugin and a Mozilla plugin for Firefox. Following the same logic, at the moment the same Gstreamer 1.0 plugin is provided/obsoleted (in newer form) by the gstreamer1-pluings-bad package. There is a conflict for the OpenH264 binaries which I will address soon.
HandBrake is now using a freshly built x265 library that enables full color depth support at 8, 10 and 12 bits. You can now convert videos in these format! This has been enabled in the 64 bit builds of the x265 library; for both Fedora 23 and CentOS/RHEL 7.
Also, NUMA support has been added to the libraries. Just by chance I have an SGI UV 200 (the predecessor of the current SGI UV 300) lying around.
This goes along with the 10 bit support for x264 that was enabled some time ago; so I’ve made some adjustments to the libraries and now there is more consistency between x264/x265. Both are loaded at runtime by HandBrake:
$ ls-alghs/usr/lib64/libx26*
668K -rwxr-xr-x. 1 root 667K Feb 5 09:55/usr/lib64/libx264_main10.so
764K -rwxr-xr-x. 1 root 763K Feb 5 09:55/usr/lib64/libx264.so.148
3.4M -rwxr-xr-x. 1 root 3.4M Feb 5 09:05 /usr/lib64/libx265_main10.so
3.4M -rwxr-xr-x. 1 root 3.4M Feb 5 09:05 /usr/lib64/libx265_main12.so
3.2M -rwxr-xr-x. 1 root 3.2M Feb 5 09:05 /usr/lib64/libx265.so.68
$ ls -alghs /usr/lib64/libx26*
668K -rwxr-xr-x. 1 root 667K Feb 5 09:55 /usr/lib64/libx264_main10.so
764K -rwxr-xr-x. 1 root 763K Feb 5 09:55 /usr/lib64/libx264.so.148
3.4M -rwxr-xr-x. 1 root 3.4M Feb 5 09:05 /usr/lib64/libx265_main10.so
3.4M -rwxr-xr-x. 1 root 3.4M Feb 5 09:05 /usr/lib64/libx265_main12.so
3.2M -rwxr-xr-x. 1 root 3.2M Feb 5 09:05 /usr/lib64/libx265.so.68
The multimedia and Skype repositories now contain all components and libraries to have the same “experience” as in Fedora 23. This includes HandBrake, MakeMKV, Skype and the same FFMPeg build with the same options that are enabled in the Fedora 23 build; including Intel Quick Sync Video and the Nvidia Encoder.
To enable this, new build roots with CentOS/RHEL i686 images have been used. This way all dependencies have been correctly built from the same CentOS/RHEL 7 packages and not with cross-compilation or using the Fedora 19 buildroots.
As most of you have noticed, the HandBrake repository has been integrating more and more multimedia packages that are not related to HandBrake itself or to its supporting programs. The latest additions to it are the CUDA/FFMpeg enabled Blender package and some additional encoding options for FFMPeg.
This definitely puts a nail in the coffin of the “CUDA programs” repository that was previously treated as a separate repository. I’m not able to provide separate repositories for them as either you have a full blown multimedia collection with each component strictly tied to each other (Blender requires FFMPeg and Nvidia drivers, FFMpeg requires restricted multimedia libraries and Nvidia drivers, HandBrake requires the same restricted multimedia libraries of FFMPeg, etc.) or you just have the plain Fedora repositories with no license/patent encumbered options.
None of these packages can be distributed inside the main Fedora/RPMFusion repositories as they are presented here with current build options; mainly due to patent and licensing issues or simply because they are coupled with non open source software resulting in dubious licensed binaries.
Some of the packages might have hard dependencies on Nvidia components or libraries, while some other have a weak dependency on them. Whether you can enable support for those it’s usually just a matter of adding or not the Nvidia repository and the multimedia (HandBrake) repository at the same time.
Not all distributions are on par regarding features and packages, let’s say most of the development goes on to the latest Fedora release due to it being my daily desktop.
To install the CUDA enabled Blender, HandBrake, MakeMKV or the fully fledge FFMpeg binary just go to the appropriate page and follow the instructions.
I will probably also rename the repository into something more generic compared to what is currently called now; so suggestions are welcome!
There is a new update for HandBrake, it now reverts to using bundled libAV in place of the system FFMpeg. UTF subtitles were not recognized properly when scanning files, and VP8 encoding is not working properly.
Also, there is a new update for libbluray and a FFMpeg update that enables hardware acceleration for Intel Quick Sync Video hardware. That is, you can now use hardware acceleration for encoding on both Nvidia cards (NVENC) and Intel CPUs (QSV). CDRtools has also been updated to the very latest.
Notes and information on the HandBrake repository page has been updated accordingly.
As some of you may have noticed, a lot of updates and new stuff has been pushed.
Highlights from the updates
The Nvidia driver version 358.16 has been promoted as “Short Lived” for Fedora, and it has support for X.org Video ABI 20. So it is now the default for Fedora 21, 22 and 23.
Driver version 352.63 is the new “Long Lived” driver for RedHat/CentOS.
Both drivers have a fallback mechanism for the SELinux regression introduced in 358.09, so you don’t need anymore to disable SELinux for GDM refresh problems.
The legacy driver has been updated to 340.96, and this as well has been enabled for Fedora 23 as it also supports X.org 1.18
CDRtools after years of an alpha 3.01 has finally updated to… an alpha 3.02 😀
HandBrake has been updated to the very latest snapshot and is relying only on separate source tarballs that are not statically linked. Unfortunately some are of dubious licenses as usual. Please note that there are some issues with subtitle tracks embedded in Matroska files not being correctly interpreted.
The Nvidia NVML library and CUDA packages have seen some small update.
Steam has been updated to version 1.0.0.51 and has updated UDev rules for the Steam Controller. If you are one of the owners of such controller, you will find support out of the box. The same changes have also been pushed to the RPMFusion package.
New repository
There’s a new repository for Samsung printers, multifunction printers and scanners that carries the “Samsung Unified Linux Driver” for both the scanning and printing functions. Just by installing it and enabling the ports in the firewall should be enough to get every device running in no time. Refer to the appropriate page for details.
Fully fledged FFMpeg binaries
Also, due to popular request, there is now a custom built FFMpeg package that drops in as a replacement for RPMFusion ones and that enables linking and support for all the codecs/encoders/decoders that would result in an unredistributable binary. This is now available the HandBrake repository. The following codecs/encoders/decoders/transports have been enabled:
VP8 and VP9 de/encoding
WebP encoding
AAC (Fraunhofer, LibVO and other variants) de/encoding
OpenAL 1.1 capture support
BluRay reading
AMR-WB de/encoding
AMR-NB de/encoding
RTMP[E] support
H.264 encoding (OpenH264, Cisco variant)
OpenGL rendering
SSH transport
Fontconfig/fribidi text support
This sobstitutes the ffmpeg binary that was provided as part of the CUDA enabled programs, as it is now tied to all the other multimedia libraries available in this repository. The support for Nvidia H.264/H.265 hardware encoding/decoding is enabled here as well and the required packages are now installed through the use of RPM weak dependencies.
The package has a different Epoch so it is not overwritten by normal updates. The idea is to have all the possible codecs supported out of the box, so also expect HEVC kvazaar (H.265), Intel Quick Sync Video (H.265) hardware support through libmfx/mfx_dispatch, CIFS transport, and other stuff, as soon as I have more time.
The same repository will be used to host the CUDA and FFMpeg enabled Blender, as it makes no sense to have a separate repository for it. Either you have a full blown multimedia collection with each component strictly tied to each other, or you just have the plain Fedora repositories with no license/patent encumbered options.
All the repositories have been updated for Fedora 23, so if you trigger an update, everything should update properly. CUDA enabled programs are still building.
A few notes:
HandBrake has been updated to a pre-release of 1.0 for Fedora 23. Updated x264/x265/FFmpeg libraries should give a speed bost to all encoding operations.
The Spotify 0.9.x repository has been removed. It will never receive updates anymore, and now the 1.x builds are on feature parity, including 32 bit support. If you haven’t upgraded, just do it now.
Nvidia drivers version 358.09 do not yet support X.org driver ABI 20, so you’re probably going to have some lock ups or random issues.
The SteamOS and X-Box replacement driver have been updated to the latest upstream.
Recent Comments