BluRay playback and ripping on Fedora (AACS, BD+, BD-J)

There are multiple ways that one can try to make BluRay decryption and playback in Linux. Of course, after some googling and fiddling around, you can see that is quite simple even if not the different instructions are quite confused as they span across multiple iterations of software development.

First of all a brief introduction. It is all explained here in great detail on the BluRay Wikipedia page, this is just an extract.

There are two different types of encryption:

  • AACS, performed using keys)
  • BD+, performed using a small embedded Java VM that executes programs and decrypts contents

And one type of “enhanced” java embedded menu (even small apps, like internet connected browsers, etc.) that can run on the BluRay player:

  • BD-J, using a GEM standard Java VM that includes also BDlive, for internet access

If any of these is implemented in a disk you own, the thing you need to do is simply insert a disk and run the bd_info command (from the libbluray-utils package) against your BD/DVD device.

Screenshot from 2015-08-27 10-59-57

This, of course, does work if you have the proper decryption keys or software installed on your system. That is, by default, nothing. 🙂

So, to enable decryption of the discs, you can proceed in two different ways, one using only open source software (not really, as you need anyway keys and a JVM dump of a BluRay Player) or going through commercial software (free at the moment while in beta).

Unfortunately none of my BluRays worked with open source tools on my system. I was not even able to get the required keys with the aacskeys program; so the proprietary software is my current choice.

Required repositories

In both cases, first of all enable the RPMFusion and the HandBrake/MakeMKV repository. Most of the keys required can be fetched from labDV, where you can also contribute back yours.

For the following examples I’m taking VideoLan as the main player, as it has good support (and a nice interface) to fiddle around with the various settings and is already available in RPMFusion.

Open Source AACS/BD+ decryption

First of all install libaacs and libbdplus from RPMFusion:

dnf install libaacs libbdplus

Then put the required AACS keys in a place, so that your AACS client can find them. For example:

mkdir -p ~/.config/aacs
wget -c -O ~/.config/aacs/KEYDB.cfg

Now, VLC, using libbluray, should dynamically load the library if it finds it on the system and then decrypt the AACS protected content if the key for the specific disc is available.

Similar to AACS, put the required BD+ JVM dump in the appropriate folder, so that your BD+ client can find them. For example:

mkdir -p ~/.config/bdplus/
wget -c -O ~/bdplus-vm0.bz2
tar -xvjf ~/bdplus-vm0.bz2 -C ~/.config/

Again, now libbluray should dynamically load the library if it finds it on the system and then decrypt the BD+ protected content using the VM dump in your personal folder.

Do not forget to update the AACS keys and the VM dump every once in a while!

Moving keys and dumps in a system wide location

This is required if you have multiple user for the system and you want to avoid each user into maintaining its own set of keys and dumps.
After installing everything in your personal folder, you will end up with a structure like the following:

$ find .config/bdplus .config/aacs | sort

To move up everything to a common location, just performs the following commands:

sudo mv ~/.config/{aacs,bdplus} /etc/xdg
sudo chown -R root:root /etc/xdg/{aacs,bdplus}

That’s it!

Proprietary AACS/BD+ decryption

This is done through MakeMKV, available from the HandBrake/MakeMKV repository, with the registration key available publicly from their forum. The software is fast, works really well, and although not open source is the only way to properly get access to your disks.

Support for external decoders has been added in libbluray some time ago, and allows you to specify different libraries than libaacs/libbdplus for decrypting content.

To proceed, remove the libaacs/libbdplus libraries if you have them installed, and install MakeMKV:

dnf remove libaacs libbdplus
dnf install libbdplus

As explained in the repository page, the MakeMKV package sets up environment variables that override the default libraries using for decryption and just uses MakeMKV’s libmmbd to launch a hidden MakeMKV instance for decryption in the background. To load the environment, logoff and login again, so it is picked up by any program starting.

After logging in, check that the environment is loaded with the following command:


Then start VLC, select to open a BluRay disc, with or without the menus. Both will smoothly work as long as it is not a BD-J, as you can see in the pictures below. Menu is navigable, reactive to selections and clickable.


Now also the command bd_info works fine, using the same mechanism.

BD-J Java menus

BD-J support is still in its infancy, at the moment of writing, with the latest libbluray 0.8.1 I am able to get part of the menus working. Most of the time I just got a video loop where the menu should be but not the actual menu. This is much better than having just VideoLan crashing, though. 🙂

Support for this is enabled by installing the libbluray-bdj package. The package puts an OpenJDK compiled Java Archive inside the classpath of the Java VM, so no further configuration is required. To install the package, just do:

dnf install libbluray-bdj

After this, in VideoLan you can just select “Open Disc”, “Blu-Ray” as the source and deselect “No disc menus”. As I said, support is not perfect, in the screnshot below I was able to see the menus but not click on them and in the background I was having a lot of errors.


I’m tracking the upstream project, so if the library can be rebuilt without breaking compatibility with the additional Fedora packages, I will add it to the repository along with MakeMKV. Before version 0.8.1 I was not even able to open a BD-J enabled BluRay disc with VideoLan.

One final curiosity

All my BD-J enabled discs have a Playstation 3 firmware update on the disc. Don’t know why, but probably because Sony owns the BluRay format so they can do as they please. Meh!

As always, feedback is welcome.

Repositories update

Another batch of changes has reached the repositories in the last weeks. The updates have touched everything:

  • MakeMKV has been updated to version 1.9.2.
  • HandBrake has been updated to the current 0.10.1 for Fedora 20, 21 and 22.
  • libdvdnav and libdvdread are based on 5.0.x releases. Also, all required libraries for MakeMKV and HandBrake have been rebuilt for Fedora 22 until RPMFusion catches up, at which point I will remove them from the repository.
  • The Nvidia driver is now at version 346.59 for all CentOS/RHEL and Fedora variants and at 349.12 (beta) for Fedora 22. According to the release notes, the 319.42 drivers will try to copy the framebuffer console’s contents out of /dev/fb0 making the Plymouth transition even better on UEFI systems.
  • The Nvidia driver is now using libvdpau 1.1 which contains support for decoding H.265/HEVC video streams (VDPAU Feature Set F) on supported GPUs.
  • The GPU Deployment kit (NVML headers and docs) is now at version 346.46. Also, nvidia-healthmon is now 64 bit only.
  • The CDRtools suite has been updated to version 3.01a28.
  • The Flash plugin package has been updated to version and it has also been pushed to RPMFusion in the form of lpf package.
  • Spotify it’s at version for CentOS/RHEL 7 and Fedora 20, 21 and 22. Instead of bundling Ubuntu’s libgcrypt library; now it uses the compat-libgcrypt package from ssaavedra/compat-libcrypt COPR repository. The package is already included where appropriate.
  • Wimms’ ISO tools have been updated to 2.30a.
  • RAR has been updated to version 5.2.1.

As always, any issue just let me know. I’m in the process of moving and starting a new job; so please bear some patience if I don’t reply to you immediately.

End of summer updates

Just came back from holiday and work travel; just in time for another batch of changes for the repositories:

  • MakeMKV has been updated to version 1.8.12.
  • HandBrake has been updated to the current development version for Fedora 20, 21 and 22. It enables now x265 by default and uses even less bundled libraries. It also uses the system libappindicator for notifications.
  • Flash plugin package has been updated to version
  • Spotify it’s now at version As announced previously in another post, the original i386 build was reverted by upstream to 0.9.4 without even notifying and it stayed locked at this version for months. As such, I completely removed i386 support for it. I’ve changed the repository page to reflect it.
  • The Nvidia Management library header and man pages (alias GPU Deployment Kit) it’s now at version 340.21, the bundled version in CUDA 6.5. It works with drivers version 340.x and up.

Most of the repositories now support both Fedora 21 and 22, including HandBrake & friends.

Also, I’m building CUDA 6.5 packages now that it has been released. Testers welcome as usual.

Another batch of big updates for the repositories (Nvidia, HandBrake, Steam, etc…)

Another batch of changes for the repositories. The HandBrake repository has seen some updates:

  • MakeMKV has been updated to version 1.8.11.
  • HandBrake has been updated to the current development version for Fedora 21. It contains additional/different bundled libraries, but the situation is not that bad.
  • libdvdnav is now based on a 5.0.0 snapshot that contains all the fixes required to avoid the HandBrake crash while opening a DVD for scanning with the default settings. Removal of the flag “Use dvdnav (instead of libdvdread)” in the preferences panel is no longer required.

Please test it, I found it much more stable than the previous version. If it works, I might build it also for current Fedora releases.


Regarding the other updates:

  • The Nvidia driver is now at version 340.24 for all CentOS/RHEL and Fedora variants.
  • Nvidia Fedora 21 packages have now aKMOD support
  • Nvidia CentOS/RHEL 7 packages have now binary kABI modules, so you can install the binaries directly without relying on DKMS.
  • The CDRtools suite has been updated to version 3.01a24.
  • The Steam package has been updated to version, the same build has been pushed to RPMFusion. The repository hosted here still contains other SteamOS packages.
  • The Flash plugin package has been updated to version and Skype has been updated to version Both versions have also been pushed to RPMFusion in the form of lpf packages.
  • Spotify it’s still at version 0.9.10; as the x86_64 and i386 builds share the same data package. Upstream has updated the x86_64 build to 0.9.11 but at the same time has reverted the i386 build to 0.9.4, so all Ubuntu users will not get the update anymore. Until this is sorted out, I’m going to leave the current package versions as 0.9.10 for systems that are both 32 and 64 bit. RHEL/CentOS 7 (which is 64 bit only) has the new 0.9.11 version.

As always, any issue just let me know.

Updated builds of HandBrake/MakeMKV with system libraries

I’ve udpated the HandBrake, MakeMKV and libdvdcss repository with my latest builds.

The Fedora builds still contain version 0.9.9 of HandBrake but I’ve extended the use of system libraries in place of the external ones with some notable differences:

  • Use of system libraries for everything except faac, fdk-aac, mp4v2 and libav, the latter on Fedora 19 only. Fedora 20 and 21 use the new ffmpeg 2.x.
  • The GTK 3 gui has been enabled in Fedora builds.
  • There is an updated build of libdvdnav that contains a patch that is now part of upstream’s libdvdnav.

Regarding CentOS/RHEL 6 builds, I’ve switched back to HandBrake version 0.9.8, which still contains a viable GTK interface for RHEL’s bundled GTK 2.20 libraries.

The build also uses system libraries for everything except faac, libbluray, libdca, mp4v2-trunk and ffmpeg. This means the previously contained libbluray package in the repository is no longer needed. Since I don’t want to bump the Epoch on HandBrake (I’m one of those that does yum upgrades between CentOS/RHEL releases) you need to sync your installed packages. Assuming you have the repository and version 0.9.9 already installed, perform this command:

yum distro-sync

And HandBrake-cli, libbluray and libdvdnav should sync with the versions currenlty pushed into the repositories.

I’ve updated the repository page with the new information, the builds are currently being uploaded.

Experimental builds of HandBrake with system libraries

In addition to the normal HandBrake, MakeMKV and libdvdcss repository, I’m preparing the next set of HandBrake packages, whether they be the SVN version or different builds of the released version 0.9.9.

Considering that from version 0.9.9 HandBrake supports using system libraries in place of the external ones, I’ve built the Fedora 20 packages for x86_64 with a few additions:

  • Fedora’s GCC default compiler options.
  • Use of system libraries for libbluray, lame, mpeg2dec, a52dec (with patch), libmkv (with patch) and x264.
  • Use GStreamer 1.x in place of GStreamer 0.x on Fedora.
  • Addition of the optional fdk-aac encoders.

Since I’m not sure about the stability of the program with its bundled libraries removed in favour of system ones and the forcing of Fedora’s GCC compiler options, I’m not pushing this updated packages in the repositories for a while; but instead I’m asking users to test it and provide some feedback.

$ rpm -q --requires HandBrake-gui | egrep -i "gst|x264|mkv|mpeg|mkv|a52|lame|blu"

The package gets also 400kb smaller than the one with the bundled libraries. All the other libraries still bundled (faac, fdk-aac, libav, libdvdnav, libdvdread, mp4v2) cannot be removed due to patching and/or using different versions.

If you happen to have a Fedora 20 x86_64 system and would like to help, please install the HandBrake repository and then install the updated HandBrake packages:

yum install

If you also want the command line version:

yum install

And then let me know, by post comments or by mail.