AWEL Multimedia Packages for RHEL/CentOS 7

VideoLAN Client

Web design optimized for Thinkpad T410 because they still rock

AWEL VLC Packages for RHEL/CentOS 7

Table of Contents

About VLC

VideoLAN Client is a network capable multimedia player and framework. It can play just about anything with the right plugins installed.

From a philosophical point of view, I prefer media applications that use a GStreamer back-end. Install a plugin, and all GStreamer based applications can potentially handle what the plugin provides.

Unfortunately the general purpose media applications for CentOS that do use GStreamer in my opinion currently suck. No disrespect intended, but I just do not enjoy using them.

Rhythmbox is trying too hard to be iTunes and it crashes a lot. It also adds any file you ask it to play to its library, and I really do not want that. I work with a lot of audio files that are only temporarily on my system, I don't want them added to my library.

VLC makes it easy with a nice minimalist interface.

[VLC minimal interface]

Totem (now just called Video Player in the menus) plays just about any video or audio file if you have the right GStreamer plugin installed but the user interface has really been deteriorating the last few years. I use to really love Totem, but now I find that I just no longer even like it. I suspect the lead developers changed.

GNOME applications in general are deteriorating in the user interface department. It feels like they are trying to be a tablet operating system, not a desktop operating system.

It may not use a GStreamer back-end, but in my opinion, VLC is an excellent option for GNU/Linux that still has a very usable user interface.

The packaging here is currently beta packaging, I may make radical changes to how things are packaged.

The version of VLC currently packaged: VLC 2.2.8

Installing VLC

Make sure that you have installed the AWEL Media repo package as described on the Home Page. Make sure your system is up to date:

[root@host ~]# yum clean all && yum update      
      

For most users, you can get everything you need by then installing the VLC meta package:

[root@host ~]# yum install vlc-meta
      

That will automatically install the following VLC packages:

That is pretty much everything most people need. There are some additional packages you may desire, to see the full list of available packages: http://awel.domblogger.net/7/media/x86_64/repoview/letter_v.group.html

Known Issues

VLC crashes when playing an audio if the 3D Spectrum visualizer is chosen, at least on my hardware.

VLC does not successfully play all DVDs. When a DVD has DRM content protection, the libdvdcss library has to break the encryption to play it. Quite often it is successful, but sometimes it is not.

As currently installed and configured, VLC was not able to play Bluray disks with DRM. That might now be resolved if MakeMKV is installed but I have not had opportunity to test.

Plugins Not Currently Built

There are some media plugins that potentially could be packaged but currently are not in my RPM.

Intel QuickSync MPEG4-Part10/MPEG2

This will be packaged in the near future.

Vovoid VSXu visualization plugin

This will probably be packaged in the near future.

Sidplay

The plugin provides support for decoding Commodore 64 sound files. If the sidplay2 library is ever maintained in EPEL, and that might happen, I will package the VLC plugin. Otherwise, I will look back at the 80s with fond memories and move on.

Shine Fixed-pt MP3 Encoder Library(Shine) and Multi-Media Abstraction Layer (MMAL)

Those two libraries are not available in CentOS or EPEL repositories and I have no desire to package them myself for CentOS 7. I am not even sure they can be built on x86_64. It appears that they really are only beneficial to systems like the Raspberry Pi and would not add any benefit to an x86_64 system.

Goom Visualization Plugin

Goom is an audio visualizer that appears to have been abandoned by its creator, it has not been updated since 2013. As it is basically eye candy, I have no intent on maintaining an RPM for the library myself. VLC has other visualizers.

If an RPM for Goom were to make it into EPEL then I might build the VLC plugin, it was a nice visualizer back when I used it with Totem. However I doubt any EPEL maintainers have any interest in maintaining a stale abandoned audio visualizer package.

Personally if I was VLC, eye candy libraries that have not been maintained by their upstream authors in years would have their plugins removed from the VLC source.

FDK-AAC

FDK-AAC is the best open source AAC encoder I know of, but unfortunately it has a very very funny license that is not compatible with the GPL license used by VLC.

It would violate the GPL for me to distribute anything GPL that links against libraries that are not compatible with the GPL. It does not however violate the GPL for an end user to build the plugin themselves, nor does it violate the GPL for me to make it easy for the end user to do so.

If you need the FDK-AAC plugin for VLC, download the source RPM here: http://awel.domblogger.net/7/media/src/repoview/vlc.html.

To build the FDK-AAC plugin:

[user@host ~]$ rpmbuild -D '_with_fdkaac 1' --rebuild vlc-2.2.8-1.el7_5.awel.9.src.rpm
      

Never build an RPM as root. For tips on proper RPM building, see https://zabbix.org/wiki/Docs/howto/rebuild_rpms. I will write a CentOS 7 specific guide to RPM rebuilding soon.

There may be some build dependencies you need to install. Once those build dependencies are installed, you should be able to run the rebuild command and it will produce a vlc pluggin RPM for FDK-AAC that you can install.

A few other packages will be built as a byproduct. Ignore them, the FDK-AAC RPM is all you want.

Advanced Topic: Custom Rebuild Parameters

VLC has a lot of build dependencies, and I mean a lot of them. The case very well may come up where you just want to custom build one or two plugins. Perhaps you want to build it against a different version of a shared library than I use, or perhaps you have a patch that fixes an issue you have been having with a specific plugin.

It can be real pain in the ass to have to install a bunch of build dependencies for plugins you do not want to install or do not need altered just to update the one or two plugins you do want to build differently.

For that reason I have written the RPM spec file for VLC to make it easy to build specific plugins without needing to install all the build dependencies you do not care about.

RPM Version Comparison

When building RPM packages on your system, it is important to understand how your RPM update utility determines when a newer version of a package is available in an update repository.

When two packages have the same name, RPM determines which of the two packages is newer by looking at the Epoch, Version, and Release tags.

Epoch

As far as I know (and I could be wrong) the Epoch MUST be set to a non-negative integer. When it is not declared in the RPM spec file, it is assigned a value of 0. I certainly have never seen an Epoch tag set to anything other than a positive integer (or 0 by not being explicitly declared).

When two packages of the same name have a different Epoch, the Version and Release tags do not matter, the package with the higher Epoch is seen as the newer version.

While there are legitimate reasons to increment the Epoch, legitimate reasons are rare and almost always involve a non-standard version scheme from the upstream source code maintainer.

Version

When two packages have the same Epoch, RPM looks at the version to see which is newer.

In open source software, the standard way to declare the version of software is with the Major.Minor.Point Release scheme where Major, Minor, and Point Release are non-negative Base 10 integers.

VLC is an example of software that uses this scheme. VLC 2.2.6 means Major Version 2, Minor Version 2, Point Release 6.

Sometimes software vendors throw letters or underscores or dashes into the mix and that is when RPM can get confused about which version is newer, resulting in the need to increment the Epoch. If the RPM maintainer understands the non-standard versioning scheme, sometimes they can avoid the need for an Epoch by adapting the version to something RPM works well with.

With the standard version scheme, RPM first compares the Major Version, and if they are the same it then compares the Minor Version, and if they are the same it then compares the Point Release.

Life is good for package maintainers when that scheme is followed. If you ever start a software project, please use that scheme, every package manager in the world will understand it.

Release

An RPM Release tag is defined by the packager and indicates the package release.

When the Epoch and Version are the same, the Release is examined to determine which represents a newer version. This will be the case when you rebuild the VLC source RPM provided here and your custom packages are compared to what it is the yum package repository.

Most RPM spec files define the Release in the following way:

Release:     N%{?dist}
          

or

Release:     N%{?dist}.M
          

N and M are usually non-negative Base 10 integers, but there are legitimate reasons to use letters too.

When RPM compares the release tag, if the N is the same, the %{?dist} macro can cause problems. The M for Package B can be a higher integer than the M for package A but Package A may still look newer than B if the dist tags are different.

The %{dist} macro, when present, makes it clear what distribution a package was built for and what repository it came from. It is unfortunate that the standard way it is used is between other parts of the release tag.

When it is defined, it is defined at the time the RPM is built. To RPM itself, it does not care that it is specific to distribution, it just sees it as part of the release.

This means if you modify how a package is built and update the M part of the release tag, the same RPM from the vendor may appear newer depending upon what your %{dist} macro expands to.

%{?dist} Expansion in RHEL/CentOS 7

In RHEL/CentOS 7, that macro in packages as built by Red Hat, CentOS, and EPEL can be any one of the following:

  • .el7
  • .el7.centos
  • .el7_0
  • .el7_0.centos
  • .el7_1
  • .el7_1.centos
  • .el7_2
  • .el7_2.centos

When you build an RPM on your CentOS 7 workstation, unless you specifically define the %{dist} macro to something else, it will either not be defined or expand to .el7.centos

The scheme often changes too. Sometimes a package will be initially release as 1%{?dist} which will expand to, say 1.el7 and when the maintainer makes a minor change, he updates the release tag to 1%{?dist}.1 but the build system used to build the update will expand it to 1.el7_2.1 instead of 1.el7.1 and that can cause issues.

I really do not like the fact that the %{?dist} macro expands in the middle of meaningful numbers, but that is the way it is done.

AWEL Media VLC Macros

Knowing there is a good chance that some users will want to rebuild specific VLC plugins without rebuilding every plugin and without worrying about their customization being replaced upon a yum update, the VLC RPM here will always use the following specification:

Release:     %{_rel_major}%{?dist}.%{_rel_minor}
        

The %{_rel_major} macro will always be defined as either 0 or a non-negative odd number (e.g. 1, 3, etc.)

When it is 0, it means a new version is being packaged and the packaging is in beta, subject to radical change until I have figured out the best to way split the build up into sub-packages. This will only happen if there are radical changes since the last version.

The minor changes that happen during the course of a packages lifetime (e.g. minor patches and tweaks) will increment the %{_rel_minor} macro and never the %{_rel_major} macro.

The %{_rel_major} macro will only be updated under one of two conditions:

  1. Security vulnerability is patched
  2. Major crash to the core program is fixed

This should make it easier for you to customize the specific plugins you want to customize without worrying about your customized package being replaced on a system update unless the update is a major one.

Defining %{_rel_major} macro at rebuild

If all you need to do is rebuild a plugin against a different version of a shared library, you do not need to modify the RPM spec file. For example, if you wanted to build the shoutcast plugin against a different version of the libshout shared library, just make sure you have the libshout version you want installed on your build system (including the header files) and redefine the %{_rel_major} macro at build time.

For example, if the source RPM is vlc-2.2.8-1.el7_5.awel.9.src.rpm you can see it has %{_rel_major} defined as 1 because that is the beginning of the release in the source RPM file, so you would redefine it as 2 at build time:

[user@host ~]$ rpmbuild -D '_rel_major 2' \
                        -D '_light_build 1' \
                        -D '_with_shout 1' --rebuild vlc-2.2.8-1.el7_5.awel.9.src.rpm
        

Since the %{_rel_major} macro was defined as 2 at build time, the resulting shoutcast plugin will always be seen as a newer RPM than the RPMs in my repository unless the version itself is updated or there is a major patch made that deems a change by me to the default %{_rel_major}

What the %{_rel_minor} macro expands to, or what the %{dist} macro expands to (if anything) is taken out of the equation.

The other two macros in that example are explained in the next section.

Build Option Macros

VLC as packaged here is very complete, it has a lot of build dependencies.

For this reason, some special build macros were created to reduce what is built when you are only after building a specific sub-package.

When build the source RPM without defining any of the build macros, it will build everything except for the FDK-AAC plugin. That is the equivalent to what the build system I use does.

To build everything including the FDK-AAC plugin, define the %{_build_all} macro:

[user@host ~]$ rpmbuild -D '_build_all 1' --rebuild vlc-2.2.8-1.el7_5.awel.9.src.rpm
        

You probably do not want to do that, but the option is there if you do.

For an absolute minimal build where everything that is optional is disabled:

[user@host ~]$ rpmbuild -D '_light_build 1' --rebuild vlc-2.2.8-1.el7_5.awel.9.src.rpm
        

That will build the vlc, vlc-devel, vlc-libs, and vlc-plugins package but the vlc-plugins packages will be greatly reduced in the number of plugins it contains.

That macro option is intended to be used in combination with other options that then turn specific options back on:

_full_core
Build all the plugins in the vlc-plugins package.
_with_qt
Build the vlc-qt package
_with_skins
Build the vlc-plugins-skins2 package
_with_jack
Build the vlc-plugins-jack package
_with_lua
Build the vlc-plugins-lua package
_with_avcodec
Build the vlc-plugins-avcodec package
_with_patented
Build the vlc-plugins-codecs-nonfree package
_with_gst
Build the vlc-plugins-gstreamer package
_with_chromaprint
Build the vlc-plugins-chromaprint package
_with_midi
Build the vlc-plugins-midi (fluidsynth) package
_with_modplug
Build the vlc-plugins-modplug package
_with_gemu
Build the vlc-plugins-game-music-emu package
_with_shout
Build the vlc-plugins-shoutcast package
_with_rtsp
Build the vlc-plugins-rtsp (Live555) package
_with_projM
Build the vlc-plugins-projectM package
_with_crystalhd
Build the vlc-plugins-crystalhd package
_with_fdkaac
Build the vlc-plugins-fdkaac package

The spec file does not care what any of those macros are defined as, just whether or not they are defined. It is customary to define them to a value of 1 but you can define them to 0 or 37 or NutCaseCheese if you like.

If they are defined, the spec file will be triggered to build those packages. They do have to be defined to something. The switch -D '_with_midi' will be rejected by the rpmbuild command, but -D '_with_midi 1' will work, and rpmbuild will pick up that the macro is defined when building the packages from the spec file.

The %{_with_fdkaac} is a special case. Since it is the most likely plugin for a user to want to build on their system, defining that macro will automatically define the %{_light_build} macro. For all the other package macros in the list above, be sure to define %{_light_build} to rpmbuild or everything will be built, requiring a lot of build dependencies.

If you are just rebuilding the package for the vlc-plugins-fdkaac plugin, you do not really need to worry about the release tag. However if you are rebuilding for one of the other plugins, be sure to define the %{_rel_major} macro to one number higher than what the source RPM uses (the first number in the release part of the RPM, right before the .el7_2).

Modifying the RPM Spec File

One of the great things about the GPL and other FLOSS software licenses is that you are free to modify the source code as you wish, and you are free to distribute those modification to others who may benefit.

The other great thing about the GPL and other FLOSS software licenses is it removes the financial barrier some have to obtaining software. As someone that is ethically opposed to piracy and someone that many (in America anyway) would consider to be part of the poor social class, that is of great personal benefit to me. But anyway...

To rebuild VLC or a plugin you need with one or more patches files applied requires modifying the RPM spec file itself. You have to add the patch to the RPM spec file (usually they are placed under the source declarations) and then tell rpmbuild to apply them and in what order within the %prep section of the RPM spec file.

How to modify an RPM spec file is beyond the scope of this document, if you are not familiar with working with RPM spec files, the Fedora project has some excellent documentation on it.

There are two non-standard macros I use in this spec file that you probably should modify if you make changes to the spec file.

_rel_minor

At the top of the vlc.spec file you will see the following:

# this is what gets bumped for minor changes to spec file
%define _rel_minor 4
        

I recommend appending a period to that definition followed by your own number you use to keep track of your modifications. For example, the first time you change the spec file you might change that to:

# this is what gets bumped for minor changes to spec file
%define _rel_minor 4.1
        

The second time, you might change it to 4.2, etc.

That helps make it clear what version of my spec file you started with while at the same time allowing you to increment the release tag.

As long as you do not the change how your %{dist} macro is defined (if defined at all) it is enough that each time you make a change and increment the number after the dot, RPM will see the new build as newer than the old build.

_rel_major

Just a little bit further down in the spec file, you will see something like this:

%if 0%{!?_rel_major:1}
%define _rel_major 1
%endif
          

That part of the spec file defines the %{_rel_major} macro if it was not already defined to the rpmbuild command.

By adding one to the definition, you will not have to remember to remember to define that macro when you use the rpmbuild command to create your modified packages. With the above example, it would look like this:

%if 0%{!?_rel_major:1}
%define _rel_major 2
%endif
          

changelog

When you modify the spec file, you should log your changes in the %changelog section. When specifying the version and release, do not include the %{dist} part of the release tag in the change. Many people do but it is meaningless.