Category: Repositories

Fedora / EPEL repositories

RHEL 7.4 multimedia packages and Skype repository removal

slaanesh 4 Comments

The upgrade path from Red Hat Enterprise Linux 7.3 to 7.4 is a bit of a pain if you have the multimedia repository configured. This is because I’m rebuilding a few components for an upgraded libwebp package and because a lot of stuff has been rebased to versions that are in Fedora. Judging by the logs, I see that most of the downloads come from CentOS systems, so I just decided to hold on some updates that are required for the various package rebases for Red Hat Enterprise Linux 7.4. So until also CentOS releases version 7.4, I can’t make everyone happy and something (like Gstreamer plugin updates) will be stuck with 7.3 versions. Hopefully the new CentOS release will come quickly enough.

Also, I decided to stop rebuilding the base packages to use a newer libwebp version. This really had very few benefits and just a lot of pain due to the huge amount of packages involved in both x86_64 and i686 variants. The amount of packages affected by this weigh at around 3 gb.

In RHEL 7.4 there are additional WebKit variants that also would require a rebuild. So, as of today, to update the packages from the EPEL 7 multimedia repository you should run this command:

rpm -e --nodeps GraphicsMagick && yum distro-sync && yum -y install GraphicsMagick

Hopefully you would get an output similar to this:

Dependencies Resolved

==============================================================================================
 Package                         Arch        Version                  Repository         Size
==============================================================================================
Updating:
 compat-ffmpeg-libs              x86_64      1:2.8.12-2.el7           epel-multimedia   5.6 M
 ffmpeg                          x86_64      1:3.3.3-2.el7            epel-multimedia   1.5 M
 ffmpeg-libs                     i686        1:3.3.3-2.el7            epel-multimedia   6.1 M
 ffmpeg-libs                     x86_64      1:3.3.3-2.el7            epel-multimedia   6.3 M
 gstreamer1-plugins-bad          x86_64      1:1.4.5-5.el7            epel-multimedia   1.8 M
 libavdevice                     x86_64      1:3.3.3-2.el7            epel-multimedia    63 k
Downgrading:
 leptonica                       i686        1.72-2.el7               epel-multimedia   881 k
 leptonica                       x86_64      1.72-2.el7               epel              928 k
 libwebp                         i686        0.3.0-3.el7              base              169 k
 libwebp                         x86_64      0.3.0-3.el7              base              170 k
 lz4                             x86_64      1.7.3-1.el7              epel               82 k
 python-pillow                   x86_64      2.0.0-19.gitd1c6db8.el7  base              438 k
 webkitgtk                       x86_64      2.4.9-1.el7              epel               12 M
 webkitgtk3                      x86_64      2.4.9-6.el7              base               11 M
Installing for dependencies:
 libwebp0.6                      i686        0.6.0-1.el7              epel-multimedia   255 k
 libwebp0.6                      x86_64      0.6.0-1.el7              epel-multimedia   250 k

Transaction Summary
==============================================================================================
Install               ( 2 Dependent packages)
Upgrade    6 Packages
Downgrade  8 Packages

Total download size: 47 M
Is this ok [y/d/N]:

Basically libwebp should come again from the main CentOS/RHEL channels and the libwebp0.6 package should come from the multimedia repository. All the packages which were rebuilt for the previous libwebp 0.5 update should become synced again to their proper versions.

If you don’t get this output, but still get some dependency errors you have to do some debugging. For example, ffmpeg-libs.i686 requires libssh.i686, but the version of libssh in CentOS extras is different from the one in EPEL (it really depends on what kind of packages you have installed and with which repositories enabled) so I’m providing here the same version that is in CentOS extras but in both variants.

Update 16th August 2017

If you get many qt5 errors during the transactions, keep in mind that RHEL 7.4 has been rebased massively, and everyone else (including EPEL) is catching up. As of today, if you have the following errors (trimmed down) in a Yum transaction:

Error: Package: gvfs-1.30.4-3.el7.x86_64 (rhel-x86_64-server-7)
Error: Package: qt5-qtwebkit-5.6.1-3.b889f46git.el7.x86_64 (epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: GraphicsMagick-1.3.26-3.el7.x86_64 (@epel-multimedia)
Error: Package: kf5-kdeclarative-5.36.0-1.el7.x86_64 (epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: qt5-qtwebkit-5.6.1-3.b889f46git.el7.x86_64 (epel)
Transaction check error:
  file /usr/lib64/gstreamer-1.0/libgstopus.so from install of gstreamer1-plugins-bad-1:1.4.5-5.el7.x86_64 conflicts with file from package gstreamer1-plugins-base-1.10.4-1.el7.x86_64

You can do the following. For this:

Error: Package: GraphicsMagick-1.3.26-3.el7.x86_64 (@epel-multimedia)

Do:

rpm -e --nodeps GraphicsMagick && yum -y install GraphicsMagick

All of the QT7KDE 5 stuff:

Error: Package: qt5-qtwebkit-5.6.1-3.b889f46git.el7.x86_64 (epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: qt5-qtquickcontrols2-5.6.1-2.el7.x86_64 (@epel)
Error: Package: kf5-kdeclarative-5.36.0-1.el7.x86_64 (epel)

Are in EPEL testing updates, so:

yum --enablerepo=epel-testing update

These:

Error: Package: gvfs-1.30.4-3.el7.x86_64 (rhel-x86_64-server-7)Transaction check error:
  file /usr/lib64/gstreamer-1.0/libgstopus.so from install of gstreamer1-plugins-bad-1:1.4.5-5.el7.x86_64 conflicts with file from package gstreamer1-plugins-base-1.10.4-1.el7.x86_64

are some of the packages that are rebased in RHEL 7.4. I’ve created a temporary repository for those, it will disappear once CentOS 7.4 is released as the packages will be integrated in the main multimedia repository. You can install it through:

yum-config-manager \
  --add-repo=https://negativo17.org/repos/rhel74-temp/rhel74-temp.repo

With the above repository it is possible to install all the other multimedia packages.

Skype repository removal

Skype 4.3 is 32 bit only, is now obsolete and has been superseded by a package that actually lists proper dependencies. It is also one of the packages that required one of the above WebKit rebuilds in i686 form for RHEL/CentOS 7 x86_64.

If you have it installed, just remove it with:

yum remove webkitgtk.i686

The repository has been deleted; to install the new Skype provided version, just head to the following official link.

Nvidia driver improvements for Fedora 25+

slaanesh 27 Comments

The Nvidia repository now contains all the remaining bits for the work done by Hans De Goede.

Making an Optimus laptop work as expected with the Nvidia drivers should be much less painful than it was a few years ago and most of the things should work out of the box on Fedora 25+.

Just enable the repository on a pristine Fedora installation, and after a while you should be able to search for Nvidia, CUDA, GeForce to Quadro to make the driver, control panel and other programs appear in your Gnome Software search:

Optimus laptops

The driver should install and operate cleanly whether you are installing it on a system which has one or more discrete Nvidia cards or an Optimus laptop with an Intel and a Nvidia card. Nothing to do to enable or configure Optimus.

This is up to the point that when the drivers are installed, you can even turn off Optimus on or off in your system Bios (if your laptop allows that) and the only difference you should see is that there’s an additional VGA card enabled in your system (check with lspci) and that the Nvidia control panel switches between a PRIME Display, like in this picture:

And a normal RandR managed one, like in this one:

Everything else should not be different from your normal experience.

Limitations

Nvidia driver

The limitations are the same as provided by the Nvidia driver, this means that if you are running it on an Optimus laptop, the Intel card can never power off. Which means higher power consumption, unfortunately. If you have an Optimus laptop and absolutely need the proprietary drivers, my suggestion is still to disable Optimus in the Bios.

OSS stack

On the contrary, if you use the OSS stack (nouveau/intel) the second card can be powered off if there’s no application running on it or display directly connected to one of the card’s outputs. That’s the best reason to use the OSS drivers at all if you you’re not doing serious gaming or 3D work:

$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

You also got the nifty selection menu about running your game on the discrete card on Gnome, which is really cool:

It will power up the video card just before launching the process. Launching a program through that menu entry is like starting it from the command line with the DRI_PRIME variable declared. For example, the same as above would be:

$ DRI_PRIME=1 quake3 &
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynPwr:0000:01:00.0

As you can see, the discrete video card is turned on. For Steam, you still need to edit each of your game to run on the Nvidia card:

SLI systems

SLI is now enabled by default with the Auto profile, there’s nothing to do if you have a SLI system. If you need any different SLI option (AA, SFR, etc.), just override it in X.org configuration files.

Nouveau fallback

With the new expanded OutputClass support for X, as carried out by Hans, it’s now super easy to switch to the OSS stack if the proprietary Nvidia driver somehow does not work. No user space component is touched, as soon as the Nvidia kernel module is not loaded (check on /sys/module/nvidia), the desktop starts with the normal OSS components you get with a normal installation. Thanks to all the work done on libglvnd, the libraries loaded are the correct one for the driver you are running.

This means that the performance of the Nvidia card would be abysmal, but still you would get a nice desktop and browser to Google around for answers on how to fix it :).

Upgrade path from Nvidia CUDA, ELRepo and RPMFusion repositories

The current packages should allow you to upgrade if you have any Nvidia component installed on your system from one of the mentioned repositories. All upgrade paths, obsolency and packaging rename should be taken into account.

This has been cool for a few years, and actually helped me a lot in migrating some installed CUDA clusters to the packages hosted here. As part of ongoing discussions with a few parties (mostly Red Hat), this is going to disappear to allow later an opposite upgrade path to one of the other repositories (RPMFusion/Nvidia).

As of the 15th of May, all Nvidia packages will be marked with Conflicts instead of Obsoletes/Provides for all the other repositories out there. I will update the installation and repository page accordingly. If you have anything installed from the RPMFusion, ELRepo or CUDA repository from Nvidia and want to switch to the packages here after the 15th of May, you must “wildcard remove” all Nvidia and CUDA packages on your system prior to proceeding with the installation.

I’m not planning to remove any other feature in terms of capability or packaging option.

Compatibility GCC 5.3.1 package for Fedora

As some might have noticed, since a few days there’s a new compat-gcc-53 package in the Fedora repositories. This is only intended for compiling CUDA programs on Fedora where the latest update to Clang 3.9 actually broke the last compiler compatible with CUDA 8.

$ rpm -ql compat-gcc-53 compat-gcc-53-c++ | grep /bin/
/usr/bin/gcc53
/usr/bin/gcov53
/usr/bin/g++53

If you need to build a package using it, you can check for examples in the Blender and CCMiner packages as in the multimedia repository:

https://github.com/negativo17/blender/blob/master/blender.spec#L57-L61
https://github.com/negativo17/blender/blob/master/blender-2.78a-cuda.patch#L19-L23
https://github.com/negativo17/ccminer/blob/master/ccminer.spec#L75-L82

This way, I was able to provide the Blender package with CUDA support also on Fedora 26 even after the Clang update from 3.8 to 3.9.

The package is also available as a COPR repository if you prefer to use official Nvidia CUDA packages instead of the ones provided here.

To do list

Figure out what to do with the PRIME Synchronization configuration:

https://github.com/negativo17/nvidia-driver/issues/13
https://github.com/negativo17/nvidia-driver/blob/master/nvidia.conf#L2-L5

All reports have been mixed so far. On my systems (including a SLI one) works fine.

Big multimedia repository update (CUDA enablements, rebases, new software)

slaanesh 72 Comments

Merging of the Nvidia repository into Multimedia

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:

https://negativo17.org/repos/multimedia

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 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:

$ for i in encoders decoders filters; do
    echo $i:; ffmpeg -hide_banner -${i} | egrep -i "npp|cuvid|nvenc|cuda"
done
encoders:
 V..... h264_nvenc           NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc                NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc_h264           NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc_hevc           NVIDIA NVENC hevc encoder (codec hevc)
 V..... hevc_nvenc           NVIDIA NVENC hevc encoder (codec hevc)
decoders:
 V..... h263_cuvid           Nvidia CUVID H263 decoder (codec h263)
 V..... h264_cuvid           Nvidia CUVID H264 decoder (codec h264)
 V..... hevc_cuvid           Nvidia CUVID HEVC decoder (codec hevc)
 V..... mjpeg_cuvid          Nvidia CUVID MJPEG decoder (codec mjpeg)
 V..... mpeg1_cuvid          Nvidia CUVID MPEG1VIDEO decoder (codec mpeg1video)
 V..... mpeg2_cuvid          Nvidia CUVID MPEG2VIDEO decoder (codec mpeg2video)
 V..... mpeg4_cuvid          Nvidia CUVID MPEG4 decoder (codec mpeg4)
 V..... vc1_cuvid            Nvidia CUVID VC1 decoder (codec vc1)
 V..... vp8_cuvid            Nvidia CUVID VP8 decoder (codec vp8)
 V..... vp9_cuvid            Nvidia CUVID VP9 decoder (codec vp9)
filters:
 ... hwupload_cuda     V->V       Upload a system memory frame to a CUDA device.
 ... scale_npp         V->V       NVIDIA Performance Primitives video scaling and format conversion

I think this will be much appreciated for you users out there that are already using CUDA for deep learning and FFMpeg to process data 🙂

Rebases: FFmpeg, HandBrake, VLC, OpenH264, WebP (CentOS/RHEL), MPV.

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:

gnome-software-handbrake

gnome-software-makemkv

gnome-software-vlc

There is still some packages that need AppStream metadata, but that will come.

As usual, feedback, bugs and comments are welcome.

GStreamer plugins for CentOS/RHEL 7, MPV and Fedora 25 repositories

slaanesh 7 Comments

The Multimedia repository now provides GStreamer (1.0) plugins for Bad, Ugly, libAV and VA-API plugin bundles with all options enabled for CentOS/RHEL 7. As per the Fedora ones, these are split into the following GStreamer runtime packages:

  • gstreamer1-plugins-bad
  • gstreamer1-plugins-ugly
  • gstreamer1-plugins-vaapi
  • gstreamer1-plugins-libav
  • gstreamer1-plugins-bad-fluidsynth (pulls in the whole FluidSynth distribution)

They all have an Epoch of “1”, to avoid any upgrade issue. Like for FFMpeg, I’ve tried to enable all the supported plugins out of the box. The “bad” package actually obsoletes the “bad-free”, “bad-nonfree” and “openh264” Gstreamer plugin packages. As such, they play nicely when enabling OpenH264 support on Firefox.

Apart from this, 99% of the Fedora 25 packages are now available, Fedora 24 and Fedora 25 repositories now have MPV in them.

Next steps

Next steps:

OpenH264 Firefox support

slaanesh 8 Comments

Fedora 24 has a new repository to enable OpenH264 decoding in Mozilla Firefox by enabling a specific repository. As described in the Wiki page, this is already available on newly installed systems.

As part of the packages contained in the Multimedia repository, there is also OpenH264 and support for it in both FFMpeg and Gstreamer Plugins. These packages conflict with the packages provided in the OpenH264 repository, so I’m now providing a custom build of the Mozilla integration along with FFMpeg and Gstreamer packages. This is due to the fact that:

  • I’m providing a more recent OpenH264 Gstreamer plugin as part of the “bad” package
  • I use slightly different names for the OpenH264 packages themselves
  • I’m providing Firefox H264 support also for CentOS and Red Hat Enterprise Linux

These new packages are already available now along with other small updates in other packages; so to install OpenH264 support for Firefox:

dnf/yum install mozilla-openh264

This work is also part of the Fedora 25 (rawhide) packages that I plan to publish next week (as time permits…) which will include OpenH264 1.6 and an FFMpeg with support for it along with other Nvidia enablements. FFMpeg support is finally for both encoding and decoding.

Fedora 24 and CentOS/RHEL 7 repositories

slaanesh 23 Comments

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

skype

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

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.

Updated multimedia and Nvidia driver packages

slaanesh 27 Comments

As many of you have noticed, there are big updates pushed in the repositories. Merging all of them into one big repository is still ongoing; but as part of it all builds now come from these git repositories:

https://github.com/negativo17

Feel free to create merge requests or ask access to them.

VLC

Both Fedora 23 and RHEL / CentOS 7 packages now host VLC with all plugins enabled, so this means you can listen/watch any kind of multimedia file on both distributions. Obligatory screenshot (CentOS 7):

centos-vlc

Of course you can also play Blu-Ray discs with it.

Gstreamer “bad” plugins

Fedora contains also Gstreamer “bad” plugins with all possible options enabled. Some statistics:

$ gst-inspect-1.0 | grep Total
Total count: 227 plugins, 1483 features

Packages for both “ugly” and “bad” plugins are coming for CentOS/RHEL 7 as well.

Updated multimedia packages

Also the update brings in quite a few updates on multimedia libraries (live555, FFMpeg, x265, dcadec, etc.).

Fedora 24 support

Fedora 24 support is coming, most of the packages have been rebuilt and all repositories will be available before the release. Starting from Fedora 24, you can enable all repositories with or without RPMFusion being enabled. This means I will try to maintain compatibility but you will not require to enable it.

Nvidia driver

The Nvidia driver has been updated to 364.19 on all supported Fedora releases. This brings in mode setting for the nvidia-drm module and Vulkan support. In the current state, mode setting works only in conjunction with a custom Wayland and the module does not provide an fb driver for the console. The Wayland patches have not been merged (and is not going very well on this side) and a KMS console is not there; so basically even enabling it just brings absolutely no difference to your experience. As such, modesetting is disabled.

It also brings instability to both my systems, so I guess it needs to mature some more before being usable. To enable mode setting, perform the following changes:

# echo "options nvidia-drm modeset=1" > /etc/depmod.d/nvidia.conf
# depmod -a
# reboot

To be more precise, some kernel command should be removed when the kernel module gets also a fb driver:

# grubby --update-kernel=ALL --remove-args='nomodeset gfxpayload=vga=normal'
# sed -i -e 's/nomodeset gfxpayload=vga=normal //g' /etc/default/grub

At the moment, those parameters are still added by the package as there is absolutely no benefit in enabling mode setting. As I said, you will reboot and get absolutely no difference.

As usual, let me know of any problems. I will be away for holiday for 3 weeks, so do not expect a prompt reply!

Support for 8/10/12 bit color depths in HandBrake!

slaanesh 14 Comments

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.

ghb-x265

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

Input devices in Steam Big Picture mode

slaanesh Leave a comment

I’ve just updated the the Steam package to fix input detection of some device in Big Picture mode. The package comes now with some additional configuration files for input devices, to have them properly recognized and functioning in Big Picture mode. Check below for the complete list of input device configurations that have been added:

Configuration for the following devices is part of the original Steam tarball:

  • Steam Controller with USB adapter
  • HTC Vive HID Sensor with USB adapter

Detection for the following device has been modified to make it appear as a Game Pad and not as a mouse (due to its touchpad). This prevents the “ghost” keypresses in Steam Big Picture mode:

  • Nvidia Shield Controller with USB cable

Detection for the following device has been modified to have them properly detected as mice/keyboards and not joysticks due to a bug in the Linux kernel. This prevents the “ghost” keypresses in Steam Big Picture mode:

  • Microsoft Microsoft Wireless Optical Desktop® 2.10
  • Microsoft Wireless Desktop – Comfort Edition
  • Microsoft Microsoft® Digital Media Pro Keyboard
  • Microsoft Corp. Digital Media Pro Keyboard
  • Microsoft Microsoft® Digital Media Keyboard
  • Microsoft Corp. Digital Media Keyboard 1.0A
  • Microsoft Microsoft® Digital Media Keyboard 3000
  • Microsoft Microsoft® 2.4GHz Transceiver v6.0
  • Microsoft Microsoft® 2.4GHz Transceiver v8.0
  • Microsoft Corp. Nano Transceiver v1.0 for Bluetooth
  • Microsoft Wireless Mobile Mouse 1000
  • Microsoft Wireless Desktop 3000
  • Microsoft® SideWinder(TM) 2.4GHz Transceiver
  • Microsoft Corp. Wired Keyboard 600
  • Microsoft Corp. Sidewinder X4 keyboard
  • Microsoft® 2.4GHz Transceiver v9.0
  • Microsoft® Nano Transceiver v2.1
  • Microsoft Sculpt Ergonomic Keyboard (5KV-00001)
  • Microsoft® Nano Transceiver v1.0
  • Microsoft Wireless Keyboard 800
  • Microsoft® Nano Transceiver v2.0
  • WACOM CTE-640-U V4.0-3
  • Wacom Co., Ltd Graphire 4 6×8
  • Wacom Bamboo Pen and Touch CTH-460
  • A4 Tech Co., G7 750 mouse
  • A4 Tech Co., Ltd Bloody TL80 Terminator Laser Gaming Mouse
  • A4 Tech Co., Ltd Bloody RT7 Terminator Wireless
  • Modecom MC-5006 Keyboard
  • A4 Tech Co., Ltd Terminator TL9 Laser Gaming Mouse
  • A4 Tech Co., Ltd Bloody V5
  • A4 Tech Co., Ltd Bloody R3 mouse
  • A4 Tech Co., Ltd X-718BK Oscar Optical Gaming Mouse
  • A4 Tech Co., Ltd XL-750BK Laser Mouse
  • A4 Tech Co., Sharkoon Fireglider Optical
  • Cooler Master Storm Mizar Mouse

The relevant repository page has been updated accordingly. If you have any additional misbehaving device that does not currently work properly in Steam Big Picture mode, just contact me and I will try to add the device defnitions to the upstream repositories.

HandBrake, MakeMKV, FFMpeg and Skype available for CentOS/RHEL 7

slaanesh 19 Comments

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.

handbrake-1.0-centos7

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.