This repository contains HandBrake with supporting programs MakeMKV and libdvdcss packages for Fedora distributions. Along with HandBrake, the same repository is used to host the CUDA and FFMpeg enabled Blender, a FFMPeg binary and Gstreamer plugins compiled with most of the possible options. 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, 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 repositories as they are presented here due to patent and licensing issues or simply because they are coupled with non open source software.

This repository requires that the RPMFusion repository be enabled on your system if you’re on Fedora and that the EPEL one be enabled if you’re running CentOS/RHEL 6.

These packages try to comply as maximum to the Fedora Packaging Guidelines; which means they have debuginfo packages, default Fedora’s GCC compile time options (where possible) and standard locations for binaries, data and docs.

Supported Fedora/CentOS/RHEL distributions:

  • Fedora 22 – i686/x86_64
  • Fedora 23 – i686/x86_64
  • CentOS/RHEL 6 – i686/x86_64
  • CentOS/RHEL 7 – i686/x86_64

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.

HandBrake, MakeMKV and libdvdcss

HandBrake HandBrake is a tool for converting video from nearly any format to a selection of modern, widely supported codecs. MakeMKV is a one-click solution to convert video into free and patents-unencumbered format that can be played everywhere. It converts the video clips from proprietary (and usually encrypted) disc into a set of MKV files, preserving most information but not changing it in any way. Additionally MakeMKV can instantly stream decrypt video without intermediate conversion and can decrypt Blue Ray discs and protected DVD discs. libdvdcss is a support library designed for accessing DVDs without having to bother about the decryption.HandBrake

By the combination of these 3 packages any video title can be ripped or transcoded without problems.

Additional libraries that are normally fetched during HandBrake compilation have been pre downloaded and are shipped in the source rpm. This to avoid unnatural behaviour when compiling packages with Fedora tools such as mock or Koji.

HandBrake is made of two separate packages; HandBrake-gui and HandBrake-cli. The former being the GTK main GUI interface, and the latter the command line program. MakeMKV contains both graphical and command line interfaces into one package.

Fedora ships the latest HandBrake with the GTK 3 interface enabled, while CentOS/RHEL 6 version is at 0.9.8; as it is the last version available that still builds with GTK 2.20 as shipped in the distribution.

HandBrake Bundled libraries

Historically, HandBrake has always linked statically the libraries required by the program. Since version 0.9.9 there’s the option to have them as external libraries and link them to the main executable. This does not mean thought that they can be used straight from Fedora repositories; some have restrictive licenses, some are forked and some do not contain the required patches for HandBrake.

All the libraries that can be linked are now linked from the main repositories, while the rest is left as bundled. Still left as bundled libraries inside the build due to versioning/patches are the following modules (libav is a fork of ffmpeg):

  • CentOS/RHEL 6: faac, mp4v2, ffmpeg, libbluray, libdca
  • Fedora 22: fdk-aac, x265
  • Fedora 23+, CentOS/RHEL 7: libav

The CentOS/RHEL 6 builds still bundle libbluray and ffmpeg, as the packages currently in EPEL 6 are too old. There’s an effort for updating libbluray to the same Fedora version, but the current RPMFusion maintainers don’t want to grant a buildroot override for MPlayer rebuilds, even if the MPlayer maintainer is willing to rebuild it.

Installing HandBrake/MakeMKV/libdvdcss

To install the repository on a supported Fedora 22+ distribution, run as root the following command:

dnf config-manager --add-repo=

To install the repository on CentOS/RHEL:

yum-config-manager --add-repo=

Then, to install the HandBrake packages (as an example both the graphical interface and the command line tool), perform the following commands:

yum -y install HandBrake-gui HandBrake-cli

For MakeMKV:

yum -y install makemkv

For libdvdcss:

yum -y install libdvdcss

Please note that the 64 bit MakeMKV tarballs contain a 32 bit binary. The binary is required by the main MakeMKV program (makemkvcon) for proper operation and comes only in binary format. This means that the 64 bit MakeMKV package will pull in the 32 bit mmtdsdec and associated glibc packages; which in a normal 64 bit desktop system are not guaranteed to be installed:

 rpm -q --whatrequires mmdtsdec
$ rpm -ql mmdtsdec
$ rpm -ql mmdtsdec
$ file /usr/bin/mmdtsdec
/usr/bin/mmdtsdec: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.6.24, stripped

Registering MakeMKV to avoid expiration

Please use the provided beta registration key published by the developers:

After starting MakeMKV just press the “Register” button and paste the provided code.


Playing protected Blu-Ray discs

Starting with version 1.8.5, MakeMKV comes with the libmmbd library. This library provides a simple API that any application can use to decrypt M2TS/SSIF files from a Blu-Ray disc. The library is licensed under the open-source LGPL license; although the way the library works, it launches a MakeMKV instance in background and communicates with MakeMKV in order to get decryption keys; so a working MakeMKV installation is required for the library to function. The libmmbd library is designed to be updated very infrequently – all the logic is inside MakeMKV (in makemkvcon), and libmmbd is just a proxy. The libmmbd source code is part of MakeMKV oss linux package.

Also, libmmbd emulates two popular open-source libraries, libaacs and libbdplus. What this means, that after a one-time setup, any application that uses libbluray/libaacs for decryption will be able to open a protected Blu-Ray disc, as long as MakeMKV is installed. Most notable application that uses libbluray is Videolan VLC player.

The libbluray library, starting from version 0.5.0 supports setting two environment variables to ease libmmbd loading, so the MakeMKV package already contains what’s required for the override (of course adjusted for 32/64 bit environments):

$ cat /etc/profile.d/ 
export LIBBDPLUS_PATH=/usr/lib64/
export LIBAACS_PATH=/usr/lib64/

This is equivalent to set an explicit library override in your library directory:

ln -sf
ln -sf

For additional details see the original announcement and how to page on MakeMKV‘s forums.

To debug such a setup, you can use the variable MMBD_TRACE prepended to the command you want to run. For example, to decrypt and print information from a Blu-Ray disc:

MMBD_TRACE=1 bd_info /dev/sr0

Or to make sure MakeMKV is doing it’s part for VideoLan:


Fully fledged FFMpeg binaries

FFMPegIt started due to my personal usage with support for NVENC, the hardware encoding support for Nvidia video cards, but due to popular request the custom built FFMpeg package that drops in as a replacement for RPMFusion enables linking and support for all the codecs/encoders/decoders that would result in an unredistributable binary.

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
  • OpenH264 encoding (H.264 Cisco variant)
  • OpenGL rendering
  • SSH transport
  • Fontconfig/fribidi text support
  • CDIO Audio CD support
  • NVENC (Nvidia H.264/265 GPU hardware encoder)
  • QSV (Intel Quick Sync Video H.264/265 CPU hardware encoder)
  • HE-AAC+ (3GPP AAC+ High Efficiency Advanced Audio Codec v2 encoder)

This sobstitutes the FFMPeg binaries that were 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 and Intel Quick Sync Video is enabled here as well and the required packages are now installed through the use of RPM weak dependencies.

To install the main FFMPeg binary and enable transcoding of practically everything, proceed as you would with the normal FFMpeg package from RPMFusion:

dnf install ffmpeg

Then after installing, you can see what options have been enabled at compile time by issuing one of the following commands:

ffmpeg -formats
ffmpeg -devices
ffmpeg -codecs
ffmpeg -decoders
ffmpeg -encoders

The package has a different Epoch so it is not overwritten by normal updates. The idea is to have all the possible codecs/transports supported out of the box, so also expect HEVC kvazaar (H.265), CIFS transport, and other stuff, as soon as I have more time.

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-plugins-vaapi
  • gstreamer1-plugins-libav
  • gstreamer1-plugins-bad-fluidsynth (pulls in the whole FluidSynth distribution)
  • gstreamer1-plugins-bad-nvenc (x86_64 only, pulls in the Nvidia binary driver)

They all have an Epoch of “1”, to avoid any upgrade issue. As for FFMpeg, I’ve tried to enable all the supported plugins out of the box. They are not yet available for CentOS/RHEL 7 due to time constraints; I will try to prepare them in the next weeks.

CUDA/FFMpeg enabled Blender

BlenderThe Blender packages contained herein enable all the possible build options including support for the RedCode image formats (for the old Red line of professional cameras), CUDA and FFMPeg.

Installing Blender works exactly like with the normal package from Fedora, except that the package will pull in all required libraries to enable FFMpeg support:

dnf install blender

If you have an Nvidia video card supported by the latest drivers and have the Nvidia repository enabled, you can install blender with the following command and get the benefit of using your GPU(s) for rendering.

dnf install blender-cuda nvidia-driver

This will pull in CUDA support for the installed Nvidia driver as well as the CUDA kernels for the various cards. Remember to manually load the nvidia-uvm module (or simply reboot) prior to starting Blender.

CUDA devices will then be selectable in the System pane of the User Preferences in the main Blender interface as depicted in the Screenshot below.

Screenshot from 2015-12-11 19-20-27


The address for contacting me is in the package’s changelog, otherwise leave a comment in the post, I’ll do my best to reply to everyone.

220 thoughts on “Multimedia

  1. Something is weird with the 64-bit makemkv package for Fedora 19. It pulls in the 32-bit version of glibc:

    $ sudo yum install makemkv
    Loaded plugins: langpacks, show-leaves
    Resolving Dependencies
    --> Running transaction check
    ---> Package makemkv.x86_64 0:1.8.5-1.fc19 will be installed
    --> Processing Dependency: for package: makemkv-1.8.5-1.fc19.x86_64
    --> Processing Dependency: for package: makemkv-1.8.5-1.fc19.x86_64
    --> Processing Dependency: for package: makemkv-1.8.5-1.fc19.x86_64
    --> Processing Dependency: for package: makemkv-1.8.5-1.fc19.x86_64
    --> Processing Dependency: for package: makemkv-1.8.5-1.fc19.x86_64
    --> Processing Dependency: for package: makemkv-1.8.5-1.fc19.x86_64
    --> Processing Dependency: for package: makemkv-1.8.5-1.fc19.x86_64
    --> Running transaction check
    ---> Package glibc.i686 0:2.17-19.fc19 will be installed
    --> Processing Dependency: for package: glibc-2.17-19.fc19.i686
    --> Processing Dependency: for package: glibc-2.17-19.fc19.i686
    --> Running transaction check
    ---> Package nss-softokn-freebl.i686 0:3.15.2-2.fc19 will be installed
    --> Finished Dependency Resolution
    Dependencies Resolved
     Package                     Arch            Version                Repository                 Size
     makemkv                     x86_64          1.8.5-1.fc19           fedora-HandBrake          4.8 M
    Installing for dependencies:
     glibc                       i686            2.17-19.fc19           updates                   4.2 M
     nss-softokn-freebl          i686            3.15.2-2.fc19          updates                   176 k
    Transaction Summary
    Install  1 Package (+2 Dependent packages)
  2. Unfortunately that’s by design. Even the 64 bit package contains a 32 bit binary from the non-OSS part of MakeMKV:

    $ rpm -qvl makemkv | grep bin
    -rwxr-xr-x    1 root    root                 25229512 Sep 19 12:42 /usr/bin/makemkv
    -rwxr-xr-x    1 root    root                  6545248 Sep 19 12:42 /usr/bin/makemkvcon
    -rwxr-xr-x    1 root    root                    63428 Sep 19 12:42 /usr/bin/mmdtsdec
    $ file /usr/bin/{makemkv,makemkvcon,mmdtsdec}
    /usr/bin/makemkv:    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x7392512f3a8c8f426fba2882e55f0f41f714f82b, stripped
    /usr/bin/makemkvcon: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped
    /usr/bin/mmdtsdec:   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped
    $ tar -tzf makemkv-bin-1.8.5.tar.gz | grep bin

    I will make a note in the page.

    1. As you can see from their forum the update to 1.8.6 is severely limited, it requires ffmpeg 2.x which is only available in Fedora 20. There’s currently no way to make MakeMKV 1.8.6 work with FFMpeg 1.x.

      I’ve update the repository for Fedora 20 yesterday, until the issue is solved upstream you should just register MakeMKV with the current beta key that is provided directly by the software house:

    1. I think you should read the repository page. I would say more carefully, but apparently you did not read it at all.

      – You have installed the Fedora repository on CentOS and this will never work; you have to install the EPEL repository. Have you looked at the path? “Fedora 6″…
      – Even if you install the repository on CentOS there’s a clear statement that the HandBrake GUI is not available on CentOS/RHEL 6.x due to graphical libraries being too old; only the command line interface is available.
      – As described in the page, the GUI is available for all supported Fedora releases:

  3. I need some help, I have installed MakeMKV & Handbrake using repositories above following the instructions.
    When running MakeMKV on any Bluray disc I get the following error:

    MakeMKV v1.8.6 linux(x64-release) started
    Using direct disc access mode
    Evaluation version, 26 day(s) out of 30 remaining
    Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - AUTHENTICATION FAILURE' occurred while issuing SCSI command A30..00200740100720..0D5C9837BD226116B946D9EA18B5B750187 to device 'SG:dev_11:0'
    Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - AUTHENTICATION FAILURE' occurred while issuing SCSI command A30..00200740100720..0709C88BDAA671518E61B72D5D1634543AF to device 'SG:dev_11:0'
    Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - AUTHENTICATION FAILURE' occurred while issuing SCSI command A30..00200740100720..0577967BE76973EF9641D4D0BF9B9B0698E to device 'SG:dev_11:0'
    Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - AUTHENTICATION FAILURE' occurred while issuing SCSI command A30..00200740100720..0A93DCBDE2815D02756466F4B801507B131 to device 'SG:dev_11:0'
    Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - AUTHENTICATION FAILURE' occurred while issuing SCSI command A30..00200740100720..091F2FD58EAFBF602DFC09C03E8DCD9E864 to device 'SG:dev_11:0'
    Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED' occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0'
    Error 'Scsi error - ABORTED COMMAND:NO ADDITIONAL SENSE INFORMATION' occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0'

    I also have errors on VLC & Handbrake when trying to read any Bluray disc as well.
    I am running Fedora 20/Mate.
    MakeMKV/Handbrake & VLC all work 100% when using a normal DVD.
    Do you perhaps have any idea where to start looking for the problem?

    1. I’ve just discovered that I made a mistake in version 1.8.6 during packaging. The library links of MakeMKV when obsoleting libaacs should be like the following:

      lrwxrwxrwx. 1 root root     23 Nov 27 14:15 /usr/lib64/ -> /usr/lib64/
      lrwxrwxrwx. 1 root root     23 Nov 27 14:15 /usr/lib64/ -> /usr/lib64/
      -rwxr-xr-x. 1 root root  26896 Nov 27 14:15 /usr/lib64/
      -rwxr-xr-x. 1 root root 503136 Nov 27 14:15 /usr/lib64/
      -rwxr-xr-x. 1 root root  35056 Nov 27 14:15 /usr/lib64/

      I’m pushing an update in a few moments. In the meanwhile upstream has created an updated 1.8.6 to fix FFMpeg issues; so I’ll be pushing 1.8.6 also on Fedora 18, 19 and 20. Can you please make a test with the following rpm in Fedora 20?

      1. I am getting the following error:

        [root@danie-laptop danie]# rpm -q makemkv
        [root@danie-laptop danie]# makemkv
        Qt: Session management error: None of the authentication protocols specified are supported
      2. Now both 1.8.5 and the current beta key no longer work (sounds like it may take a day or two for a new beta key to be posted). Any update on the 1.8.6 build for Fedora 19?

          1. Ah, thanks for the info. Well, they posted a new beta key that’s good through the end of January, so I’m back working on 1.8.5. Thanks for building and packaging this! Very handy.

  4. I have the libdvdcss2.x86_64 package from AtRPMs installed, per mjwired’s Personal Fedora Install Guide(s) at (I am on Fedora 20 release (beta?), he doesn’t have F20 guide up yet, but F19 with the right mods to commands works fine). The version in the AtRPMs repo is slightly later than you have, they have 1.2.13-7.fc20 vs your 1.2.13-2.fc20. However since their package is labelled ‘libdvdcss2’ and yours is ‘libdvdcss’ there is not a warning of conflict from yum until it tries to do the transaction test:

    Running transaction test
    Transaction check error:
    file /usr/lib64/ from install of libdvdcss-1.2.13-2.fc20.x86_64 conflicts with file from package libdvdcss2-1.2.13-7.fc20.x86_64

    Can you add in a satisfies requirement like an ‘or’ statement in a SPEC file? Maybe like this in Handbrake:

    Requires: libdvdcss >= 1.2.13 || libdvdcss2 >= 1.2.13

    I am not sure that would work, I have not had to do that before in my RPM builds. Or maybe you could do a provides in the libdvdcss package, since you appear to have the same codebase:

    Provides: libdvdcss libdvdcss2

    I am not sure this would work well either, it might just conflict with the other package in AtRPMs.

    1. I can add it, but to avoid disrupting other dependencies relationship I need to know if there are any dependencies on the libdvdcss2 package in ATrpms. Is it pulled in by any other package? For the moment, my suggestion is to remove the ATrpms’ package, I have put a dependency on libdvdcss inside HandBrake so it is able to read protected DVDs.

      1. Sorry for the late reply, life got in the way.

        I have uninstalled the libdvdcss2 from ATRPMs. I found that VLC was the main cause for it being installed, needed to play protected DVD content as you said. I installed the one from your repo, and VLC can use it to play the protected content. There is no specific dependency on the lib, if it is there VLC uses it. I suppose other system players use it too but I have not tested them.

        I now am installing Handbrake from the repo and notice the following (I uninstalled libdvdcss earlier in testing VLC):

         Package               Arch      Version           Repository           Size
         HandBrake-cli         x86_64    0.9.9-9.fc20      fedora-HandBrake    3.4 M
         HandBrake-gui         x86_64    0.9.9-9.fc20      fedora-HandBrake    3.9 M
         makemkv               x86_64    1.8.8-1.fc20      fedora-HandBrake    6.9 M
        Installing for dependencies:
         glibc                 i686      2.18-12.fc20      updates             4.2 M
         libdvdcss             x86_64    1.2.13-2.fc20     fedora-HandBrake     53 k
         libmkv                x86_64    fedora               26 k
         nss-softokn-freebl    i686      3.15.4-1.fc20     updates             183 k
        Transaction Summary
        Install  3 Packages (+4 Dependent packages)

        Why is a 32-bit GNU C Library needed? It appears in the dependencies that makemvk is calling for a lot of libs that state (GLIBC_2.0), …_2.1), and …_2.2). Not that I won’t install the 32-bit C libs, but it just seemed odd to me that a 64-bit labelled package would be calling a 32-bit LibC.

        1. Unfortunately the MakeMKV package contains a 32 bit binary (/usr/bin/mmdtsdec) that is required when extracting DTS audio, it is noted at the end of the installation section above. The current RPM packages do not allow to create subpackages with an i686 architecture, only a noarch package can be generated; so for now it’s bundled in the main package.

          I would need to disassemble the binary tarball, create two separate packages and create a dependency on the mmtdsdec.i686 package from the main MakeMKV package.

        1. Thanks for pointing this out, I’ve added a note to the MakeMKV page. I don’t have a Blue Ray drive to test (next in the list for Christmas) so I was not aware of this bug. I use it mainly to rip DVDs. The bug though, is not in MakeMKV but instead in the kernel, so this has nothing to do with MakeMKV; if the kernel package is fixed, the binaries here will work as expected.

          1. I have just tested it on my laptop and it is now working for me without any SCSI errors. Thanks a lot of fixing it. πŸ™‚

  5. I have HandBrake-gui-0.9.9-7.fc19.i686, and the rpm is missing the post-install scripts to set up the icon cache, etc.:

    $ rpm -q --scripts HandBrake-gui
    (no output)
    1. Thanks for noticing, by mistake I’ve added the %post, %postun and %posttrans sections to the base package instead of the gui subpackage. Update coming!

  6. I updated to all the latest packages. I’m getting the SCSI error again. Anyone else notice this with the latest FC20 packages? Tried un-installing/re-installing makemkv but no luck.

    Happening on previously ok Blu-ray too.

  7. Hello

    and first of all a big, big thank you for your efforts to make the popular HandBrake available for Fedora-users in a very easy way. I’m using both, the cli- and the gui-version and HandBrake 0.9.9-9 was running fine on Fedora 20 (64bit). Updated yesterday to 0.9.9-10 and now I get a “segmentation fault” as soon as the encoding-process starts. The gui-version opens and load the video I want to encode, but when I hit the “start encoding”-button HandBrake crashes immediately.

    poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=12, events=POLLIN}, {fd=17, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 2 ([{fd=4, revents=POLLIN}, {fd=14, revents=POLLIN}])
    read(4, “\2”, 16) = 8
    write(4, “\1”, 8) = 8
    write(16, “[10:52:08] * video track\n”, 26) = 26
    write(18, “[10:52:08] * video track\n”, 26) = 26
    +++ killed by SIGSEGV +++
    Speicherzugriffsfehler (= Segmentation fault in english)

    If you need any further informations, please let me know and thanks again!

    1. This seems related to the latest libdvdnav/libdvdread change, but the crash happens also on some non-dvd source files. I will push an update ASAP (currently away from computer/internet). Thanks for reporting.

      1. The crash happens from the CLI as well if I select the Normal preset.

        HandBrakeCLI –preset “Normal” -i /share/DVDs/SHREK_2_US_16X9/title02.mkv -o ./title02.mkv


        [11:51:45] + loose anamorphic
        [11:51:45] + storage dimensions: 720 * 460, mod 2
        [11:51:45] + pixel aspect ratio: 32 / 27
        [11:51:45] + display dimensions: 853 * 460
        [11:51:45] + encoder: H.264 (x264)
        [11:51:45] + x264 preset: veryfast
        [11:51:45] + h264 profile: main
        [11:51:45] + h264 level: 4.0
        [11:51:45] + quality: 20.00 (RF)
        [11:51:45] * audio track 1
        [11:51:45] + decoder: English (AC3) (5.1 ch) (track 1, id 0x1)
        [11:51:45] + bitrate: 448 kbps, samplerate: 48000 Hz
        [11:51:45] + mixdown: Dolby Pro Logic II
        [11:51:45] + encoder: AAC (faac)
        [11:51:45] + bitrate: 160 kbps, samplerate: 48000 Hz
        [11:51:45] reader: first SCR 7470 id 0x0 DTS -2970
        [11:51:45] encx264: min-keyint: 24, keyint: 240
        [11:51:45] encx264: encoding with stored aspect 32/27
        [11:51:45] encx264: Encoding at constant RF 20.000000
        x264 [warning]: –psnr used with psy on: results will be invalid!
        x264 [warning]: –tune psnr should be used if attempting to benchmark psnr!
        x264 [info]: using SAR=32/27
        Segmentation fault (core dumped)

        1. Fixed in version 0.9.9-11, now in the repository. It was not related to the libdvdnav/libdvdread changes. Please let me know of any other issues.

  8. The latest version of Handbrake from 3-14 is crashing here:

    0x0000003aeeb5cc15 in __memcmp_sse4_1 () from /lib64/
    (gdb) where
    #0 0x0000003aeeb5cc15 in __memcmp_sse4_1 () from /lib64/
    #1 0x00000000009d364e in x264_cqm_init ()
    #2 0x00000000009a0eb4 in x264_encoder_open_130 ()
    #3 0x000000000049f360 in encx264Init ()
    #4 0x00000000004989ef in work_func ()
    #5 0x00000000004a11ab in hb_thread_func ()
    #6 0x0000003aef207f33 in start_thread () from /lib64/
    #7 0x0000003aeeaf4ded in clone () from /lib64/

    1. Fixed in version 0.9.9-11, now in the repository. It was not related to the libdvdnav/libdvdread changes. Please let me know of any other issues.

  9. I had the same problem as jfc. After updating and rebooting, I got “Aborted (core dumped)” when scanning a DVD. I fixed the issue by going to Preferences and unchecking “Use dvdnav” in the Advanced tab. Video is encoding without a crash. I’m on an AMD FX6300 machine (just in case this has something to do with SSE4.

    1. Hello, I’ve updated the builds (currently uploading). They contain a libdvdnav that has been updated with an HandBrake patch that has been accepted upstream and will be contained in libdvdnav 5.0.0.

      It fixed the crash for me on my only DVD where I could reproduce it. There is a fairly recent Debian bug (still unresolved) that seems to indicate the bug itself is in libdvdnav and not in HandBrake support for the library:

  10. Thanks a bunch for maintaining the HandBrake package for Fedora users!

    I have Handbrake 0.9.9-12 on a Fedora 20 x86_64 system that I used with compiled MakeMKV (the latest version, forgot the number and typing this from my work computer). I have this particular blueray movie ripped in a folder that I am trying to encode with HandBrake with my default settings. The encode starts and continues up until 1.14%, stalls there and then crashes with segmentation fault. I tried running ghb -x from console, with essentially no useful additional information. I tried disabling libdvdnav from preferences, again with no change in behavior. On the other hand I can watch the movie without any problems up until 20% or so from the unencoded mkv file in the rip folder; therefore I don’t think the source mkv file is the problem. Do you have any suggestions or pointers for me?

    1. I am sorry to reply to my own post, but I downloaded the source code of HandBrake (6160 svn) today and compiled it. It does not crash anymore and does the job. Therefore, I think the current rpm package for Fedora 20 may be defective, probably not due to a packaging defect, but due to a problem in the code. This is a pure speculation on my part, since I am happy to admit that I don’t have a clue :). I just wanted to inform you all.


      1. I have had the same issue; my encode goes to 1% or so and crashes with a seg fault. It occurs on 5 different Blu-ray and DVD rips, so it looks like it is something in the 0.9.9-12 version and not a particular Blu-ray source. I am also on Fedora 20 x86_64 so it may be some interaction with Fedora 20 64 bit and the new build. I was also able to download the source code (6161 svn), compile it, and it works fine.

  11. Same issue on Fedora 20 with the latest version from your repo.

    Apr 27 09:25:25 pepwul81385 kernel: [ 1411.593461] ghb[2822]: segfault at 18 ip 00007f85bee83c5c sp 00007f858d7fd940 error 4 in[7f85beabe000+6a1000]
    Apr 27 09:25:25 pepwul81385 kernel: ghb[2822]: segfault at 18 ip 00007f85bee83c5c sp 00007f858d7fd940 error 4 in[7f85beabe000+6a1000]

    Does this when starting to process a blu-ray rip .mkv file.

    Please email me with additional info you need.


    1. Also experiencing the same 55.39.101 segfault due to

      [1522295.520438] ghb[16604]: segfault at 18 ip 00007f077f1c6c5c sp 00007f0742d59900 error 4 in[7f077ee01000+6a1000]

      Thanks very much for maintaining this package!

  12. The latest version from 8-6 is dumping the following on startup:

    ghb: Symbol `vpx_codec_vp9_dx_algo’ has different size in shared object, consider re-linking
    ghb: Symbol `vpx_codec_vp8_cx_algo’ has different size in shared object, consider re-linking

    When selecting a file to convert it crashes

  13. I am on Fedora 20 x64 and HandBrake GUI (svn6304) not longer works properly using dvdnav. It worked in the recent past. I cannot pinpoint exactly when it began failing. If ‘Use dvdnav (instead of libdvdread’ is selected under Preferences -> Advanced tab, HandBrake reads the DVD, reaches the last title in the disk and then spontaneously closes. No error message is displayed before closure. If ‘Use dvdnav (instead of libdvdread’ is *not* selected then the faiure behavior does not present and HandBrake performs normally.

    1. I can’t reproduce it here, all the DVDs I have tried are scanned succesfully with libdvdnav version 5. One thing you could try (I doubt it will solve any issue) is to downgrade libdvdnav to the bundled Fedora 20 version; but I doubt it will solve any issue.

      HandBrake developers left the flag to use libdvdread for a reason. πŸ™‚

  14. I am having the same issue as Hal. This is the issue I described in the repository thread.

    I wonder if recompiling libdvdnav from srpm would help?

  15. Anyone else having problems with sub-titles always being burn-in.

    * subtitle track 1, English (track 2, id 0x2) Picture [VOBSUB] -> Render/Burn-in

    Some update back around Aug, seems they’re no longer:

    * subtitle track 1, English (track 3, id 0x3) Picture [VOBSUB] -> Passthrough

    1. I see it in all repositories:

      $ find . -name "*makemkv*" | sort

      Which repository are you referring to?

  16. On Fedora 20, trying to install Handbrake, I get this:

    --> Finished Dependency Resolution
    Error: Package: HandBrake-cli-0.10-10.svn6507.fc20.x86_64 (fedora-HandBrake)
    Error: Package: HandBrake-gui-0.10-10.svn6507.fc20.x86_64 (fedora-HandBrake)
    Error: Package: HandBrake-cli-0.10-10.svn6507.fc20.x86_64 (fedora-HandBrake)
    Error: Package: HandBrake-gui-0.10-10.svn6507.fc20.x86_64 (fedora-HandBrake)

    I’m new to Fedora and haven’t been able to find mp3lame or x264, (a page on dates back to 2004/2005…), where can I download them? Thanks!

  17. I have installed Fedora 21. When I load makemkv into fedora 21 I get this message. /usr/bin/makemkvcon: error while loading shared libraries: cannot open shared object file: No such file or directory

    Could it be an idea to get an ffmeg-compat2 as workaround fro makekvm?

    1. Hello, makemkvcon is linked to ffmpeg 2.4:

      $ ldd /usr/bin/makemkvcon | grep av => /lib64/ (0x00000033ece00000) => /lib64/ (0x00000037b8600000)

      You should not have that error. this means you have the package for another distribution installed. Correct version at the time of writing is:


      Can you do the following?

      yum distro-sync makemkv
      1. Same thing here, distro-sync didn’t do anything.

        $ ldd /usr/bin/makemkvcon | grep av => not found => not found
        $ rpm -qf /lib64/ /lib64/
        $ rpm -qf /usr/bin/makemkvcon

        There seems to be a disconnect between the current version of makemkv and ffmpeg-libs.

        1. Hello,

          there is something wrong with your system; your yum should complain every time you perform some operation about the missing dependencies. Can you reinstall the makemkv package (yum -y reinstall makemkv)? I have the same binary and it is linked to the correct libraries:

          $ ldd /usr/bin/makemkvcon | grep av
 => /lib64/ (0x0000003c43000000)
 => /lib64/ (0x0000003c44200000)
          $ rpm -qf /usr/bin/makemkvcon
          $ rpm -q ffmpeg-libs

          1. Okay, this is very strange, can you tell me the checksum of your version of makemkvcon?

            # yum -y reinstall makemkv
            Loaded plugins: fastestmirror, langpacks
            Loading mirror speeds from cached hostfile
            * fedora:
            * rpmfusion-free:
            * rpmfusion-free-updates:
            * rpmfusion-nonfree:
            * rpmfusion-nonfree-updates:
            * updates:
            Resolving Dependencies
            --> Running transaction check
            ---> Package makemkv.x86_64 0:1.9.1-1.fc21 will be reinstalled
            --> Finished Dependency Resolution

            Dependencies Resolved

            Package Arch Version Repository Size
            makemkv x86_64 1.9.1-1.fc21 fedora-HandBrake 3.5 M

            Transaction Summary
            Reinstall 1 Package

            Total size: 3.5 M
            Installed size: 30 M
            Downloading packages:
            Running transaction check
            Running transaction test
            Transaction test succeeded
            Running transaction (shutdown inhibited)
            Installing : makemkv-1.9.1-1.fc21.x86_64 1/1
            Verifying : makemkv-1.9.1-1.fc21.x86_64 1/1

            makemkv.x86_64 0:1.9.1-1.fc21

            # ldd /usr/bin/makemkvcon
   => (0x00007fff46b20000)
   => /lib/ (0x000000338fa00000)
   => /lib/ (0x0000003079400000)
   => /lib64/ (0x0000003317600000)
   => /lib64/ (0x0000003317200000)
   => /lib64/ (0x0000003317a00000)
   => /lib64/ (0x000000331ca00000)
   => /lib64/ (0x0000003319600000)
   => /lib64/ (0x0000003328c00000)
   => /lib64/ (0x0000003317e00000)
   => /lib64/ (0x000000331ce00000)
   => not found
   => not found
   => /lib64/ (0x0000003318200000)
   => /lib64/ (0x0000003318a00000)
            /lib64/ (0x0000003316e00000)
            # md5sum /usr/bin/makemkvcon
            b2d6140250ed34d626e34f77399031f4 /usr/bin/makemkvcon

          2. Doh! Found the problem, I had an old makemkv library in /usr/lib, removing that fixed the problem,

            # rm /usr/lib/

  18. I could not get the gui to start on Fedora 20. Then I tried the CLI and found that a shared library that was missing is my problem. Installed libass and all is well. Thanks!

    Here is the message that the CLI spit out:

    HandBrakeCLI: error while loading shared libraries: cannot open shared object file: No such file or directory

    1. The library is linked by the main executable, so unless you forced the installation of HandBrake through rpm ignoring dependencies the library is already pulled in by HandBrake:

      $ rpm -q --requires HandBrake-cli | grep ass
      1. Precisely, its looking for but it installed and so isn’t finding it. I have the same issue on FC21.

        I had to create a symlink “ln -s /usr/lib64/ /usr/lib64/” so it would find the library but surely this should not necessary if packaged correctly for this distro?

          1. I am having the same issue, and so far have not been able to get by it. rpm -q –requires HandBrake-cli shows which is what is installed (libass-0.12.0-1.fc21.x86_64) but ghb and HandBrakeCLI both say they want

            I have the latest HandBrake release 0.10.1 also.

            yum whatprovides “*/” produces nothing.

          2. Don’t know where you are getting those packages, but the one I produce have the correct dependencies. is not in Fedora 21. All packages have correct requirements:

            $ rpm -qp --requires HandBrake-{gui,cli}-0.10.1-1.fc21.x86_64.rpm | grep
            $ ldd /usr/bin/{ghb,HandBrakeCLI} | grep libass
   => /lib64/ (0x0000003c50600000)
   => /lib64/ (0x0000003c50600000)

          1. SOLVED!
            strace HandBrakeCLI does indeed show it looking for

            ldd /usr/local/bin/HandBrakeCLI also lists libass.so4 which is where strace found the command. BINGO!

            The current bin files are in /usr/bin !

            SOMEONE left old executable files in /usr/local/bin. I removed ghb and HandBrakeCLI from /usr/local/bin and it all WORKS now.

  19. Hi,
    I’ve been using handbrake for a couple of years now on fedora. I recently upgraded to fc21 and upgrade handbrake after that. I normally generate mkv using Theora and Vorbis. this stopped working after i upgrade HB. It generates a file that is only 10M and no video but some sound. If i choose some other type like mp4 it works fine. any ideals how i can debug this? I’ve tried different videos and it does the same for all of them.


    1. I just applied the lastest rpm update and i still can’t generate video using theora. The sound is fine, but the picture is black, makes for a very small mkv file. fc20 version still works and thankfully i didn’t upgrade all my servers at the same time. however until i can resolve this i can’t upgrade the last of my servers to fc21

      1. just upgrade my server to fc22 and still the same ole problem. i can’t generate mkv containers but others work fine. i still would like some ideals how to debug this since handbrake isnt’ reporting any issues in the logs. i have reinstalled the libraries before the upgrade and they were installed again as part of the upgrade to fc22. It is only working on fc20 for me.

  20. Is anyone else noticing large icons on the toolbar and a few other places for HandBrake on Fedora 21 x86_64? From what I can tell the source icons are in SVG and in inkscape the dimensions are set to 64×64. Maybe it’s not downsizing the icons for the toolbar? See

    1. Yes, me too. Will test a new build in the weekend with the latest commits and post it next week if it solves the issue. I’m currently off for the weekend. Thanks for notifying.

  21. Mine shows exactly what yours does too. I am wondering if this has to do with upgrading from Fedora 20 to 21 or something because HB used to work. Since I don’t use it all that often, I am not positive when it stopped working.

    Is there a way to trace when I run HandBrakeCLI what is producing the requirement for the .4 version?

  22. Hello, I just followed the install instructions and it works great.
    However I cannot get MP4 in the ripping format, as I used to running an Ubuntu distro.
    Are there some smart workaround this ?


    1. You’re using an EOL distribution. As you can see from the repository page and from the repository itself there is no Fedora 19 support.

        1. Well, thanks for letting me know, I’ve removed it πŸ™‚
          Basically I track the current distributions (where possible) that are not EOL, that is, at the moment of writing:

          Fedora 20+
          CentOS/RHEL 5+

          Depending on the software, someone may be missing (there is no RPMFusion RHEL 7 for multimedia libraries, etc)

  23. I am running Fedora 22… trying to get this going. i have installed the RPMFusion repository. Any idea why i’m getting the below message?

    # dnf install –add-repo=
    Last metadata expiration check performed 1:54:10 ago on Tue May 26 11:46:45 2015.
    No package –add-repo= available.
    Error: no package matched: –add-repo=

  24. I’m using Fedora 22 and Handbrake 0.10.1 (x86_64). I’m trying to encode a DVD and as soon as the encoding process starts I get a “Segmentation fault (core dumped)” and the program closes inmediatly.

  25. You wrote that the command works for Fedora 22+.
    I have a fedora 20.
    Does this command works also for Fedora 20:
    dnf config-manager –add-repo=


    1. Fedora 20 will be available until the end of June, at which time it will go EOL and I will delete the relevant repositories. Command is the same but with yum:

      yum config-manager --add-repo=

  26. Hi, looking for handbrake for RHEL 7. Does this exist, or can some one give me pointers on building it from source?

    1. Hello, I will build 0.9.9 for it; I’m a bit swamped by daily stuff. 0.10.x requires newer GTK libraries than what RHEL 7 provides.

    1. Hello, I’m literally swamped with apartment move and daily work. Have updated it today to 1.9.4, new build being pushed in a few hours.

  27. i’ve been using handbrake since fredora 18. I have it running on one server running FC20. On another server that i have upgraded to FC21 and then FC22 i can not get handbrake to generate a working Theora video file, i get no video and the file size is less than 20mb big. I can create a mp video files. I’ve tried reinstalling handbrake, i’ve also tried reinstalling the various lib packages it depends on. no luck. I’ve traced and don’t see any issues. Looking for some additional insights as to how to troubleshoot this.

  28. I notice in your instructions on this page you say to:

    ln -sf /usr/lib64/

    …but there is no on my system, only (replace the last letter “o” with the number “zero”).


  29. Unable to indtall handbrake, or makemkv from repository.

    um command has been deprecated, redirecting to ‘/usr/bin/dnf update’.
    See ‘man dnf’ and ‘man yum2dnf’ for more information.
    To transfer transaction metadata from yum to DNF, run:
    ‘dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate’

    Failed to synchronize cache for repo ‘fedora-HandBrake’ from ‘’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried, disabling.
    Last metadata expiration check performed 0:27:23 ago on Tue Oct 27 12:56:01 2015.
    Dependencies resolved.
    Nothing to do.

    sudo yum install HandBrake-cli
    Yum command has been deprecated, redirecting to ‘/usr/bin/dnf install HandBrake-cli’.
    See ‘man dnf’ and ‘man yum2dnf’ for more information.
    To transfer transaction metadata from yum to DNF, run:
    ‘dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate’

    Failed to synchronize cache for repo ‘fedora-HandBrake’ from ‘’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried, disabling.
    Last metadata expiration check performed 0:27:39 ago on Tue Oct 27 12:56:01 2015.
    No package HandBrake-cli available.
    Error: Unable to find a match.

    1. There is no HandBrake for Fedora 23 at the moment, as it depends on Fedora 23 RPMFusion packages which are not yet released.

  30. Starting with HandBrake-gui-10.2-3 I am getting segfaults when opening most multi-title blurays (the more titles, the higher the chance of the crash). I can remux those titles with makemkv then open them in HandBrake one by one (annoying, but it works).

    I’ve also recreated this with a fresh install of Fedora 22 (Install base, RPMFusion repos, and yours. Update and install HandBrake-gui) on a separate hardware platform and a VM.

    Looking at the stack trace, it looks like it might be crashing in “decavcodecvInfo”. Though admittedly, this is not my area. Possible a regression of the previous segfaults discussed earlier due to the change to local libraries?

    Kern message:
    kernel: ghb[2077]: segfault at 0 ip 00000000004610ef sp 00007ff842cb9a08 error 4 in ghb[400000+896000]

    Crashed thread stack trace:
    { "crash_thread": true
    , "frames":
    [ { "address": 4591855
    , "build_id": "0c7e4a13524e14706761c7e4b0f2153bede79db6"
    , "build_id_offset": 397551
    , "function_name": "decavcodecvInfo"
    , "file_name": "/usr/bin/ghb"
    , { "address": 4642970
    , "build_id": "0c7e4a13524e14706761c7e4b0f2153bede79db6"
    , "build_id_offset": 448666
    , "function_name": "DecodePreviews"
    , "file_name": "/usr/bin/ghb"
    , { "address": 4647983
    , "build_id": "0c7e4a13524e14706761c7e4b0f2153bede79db6"
    , "build_id_offset": 453679
    , "function_name": "ScanFunc"
    , "file_name": "/usr/bin/ghb"
    , { "address": 4571083
    , "build_id": "0c7e4a13524e14706761c7e4b0f2153bede79db6"
    , "build_id_offset": 376779
    , "function_name": "hb_thread_func"
    , "file_name": "/usr/bin/ghb"
    , { "address": 140711485863253
    , "build_id": "6e1fb69fc4248ca0819107eed38c9e8db0b645b3"
    , "build_id_offset": 30037
    , "function_name": "start_thread"
    , "file_name": "/lib64/"
    , { "address": 140711413853085
    , "build_id": "5e86d81f6b21b75b08b19cd1574e14ec0ec098f3"
    , "build_id_offset": 1059741
    , "function_name": "__clone"
    , "file_name": "/lib64/"
    } ]

    1. Ouch. Could be, actually. Will look into it, thanks for reporting.
      Actually I am in the process of updating to newer ffmpeg/x264/x265 and HandBrake, will see if it happens.

      1. As of today, it loos like this is still occurring. GDB backtrace still shows a segfault in decavcodecvInfo. Let me know if there’s anything that I can do to assist.

        Program received signal SIGSEGV, Segmentation fault.
        [Switching to Thread 0x7fffcc9df700 (LWP 4514)]
        0x00000000004610ef in decavcodecvInfo ()
        (gdb) backtrace
        #0 0x00000000004610ef in decavcodecvInfo ()
        #1 0x000000000046d89a in DecodePreviews ()
        #2 0x000000000046ec2f in ScanFunc ()
        #3 0x000000000045bfcb in hb_thread_func ()
        #4 0x00007ffff30f6555 in start_thread () at /lib64/
        #5 0x00007fffeec49b9d in clone () at /lib64/

          1. This should generate no different build compared to the one I provide. Can you try with the latest 1.0-10? It contains a few fixes.

  31. There is an issue with HandBrake-1.0-3.6d66bd5 in the F23 repository. When trying to encode with VP8, the CQ settings aren’t working – the output is of extremely low quality. The workaround is to use the previous version in the F22 repository. I compiled for F23 and appears to be working fine.

    1. Sorry for not replying to your email, I’m a bit swamped at the moment. I have a big multimedia reorganization in mind and also to update HandBrake. Will look into it, thanks.

        1. Just pushed an update (1.0-8), the build reverts to bundled libAV, compiling HandBrake with FFMPeg creates issues with UTF subtitles. libAV is also used for the VP8 encoding.

          Please let me know how it goes.

          1. Yes, VP8 encoding appears to be working correctly now. I did notice that there is a problem with subtitles, they don’t display. When using smplayer you get the pulldown menu with the selections… but when you choose one, it doesn’t display. This was working a few releases back, but stopped noticed it stopped with
            0.10-2-3. The other thing I noticed that VP9 used to be a selection, now it has disappeared. It basically was unusable because it was so slow… but I read that there have been recent improvements, so would like to give it another try. Thanks for your help.

  32. Has the Fedora 21 repository been deprecated? If so, why?

    Will the Centos binary run on an F21 installation?

    (thanks in advance)

      1. Hi slaanesh, thanks for the clarification. I was just going by the verbiage at the top of the post (maybe remove the Fedora 21 support statement?).

        I’ll upgrade to F22 in the next month or so so it should be a mut point for me.

        Thanks for your work on Handbrake, BTW.

  33. I’m on F22, I’ve install handbrake,makemkv etc from your handbrake repo no problems. but can’t install blender or blender-cuda (GTX580). the only option I get is from updates/fedora. I guess i’m doing something wrong, but i’ve skimmed this page and others many times… help

      1. Yeah, I’m a bit busy but it’s coming. Yesterday I updated all the Fefora 22 libraries required for FFMpeg, this week I will update also FFMpeg and Blender. Thanks.

  34. HandBrake 1.0-9.3443f6a isn’t working with H265 now. Previous version worked. Both previous version and current still have the VP8 issue I reported earlier. Is it possible for you to backout to the versions that worked?

    1. A bit more information on the VP8 issue, previously, it appeared to rip through at a high frame rate with bad quality, now the frame rate seems to be back to normal, but the quality isn’t up to previous levels – if that makes sense. The H265 now gets an “encode failed” almost immediately upon starting. Would be interesting to know if anyone else is seeing this. So far H264 appears to be working.

      1. This was a bug in the latest HandBrake sources. Uploading a new build now (tested it on H.265, VP8 and H.264).
        It’s very hard to accomodate all requirements and have a stable build :/

  35. Just tried the x264 10bit… it consistently fails also with “encode failed” at about the 3-4% mark. Regular x264 as mentioned earlier appears to be the only thing working. (Didn’t test Theora).

      1. Just did some partial encoding and here are the results:
        VP8 – same. Used setting of 14, quality is bad. As a test, backed out to version 0.10.2-3 and again used VP8 and setting of 14… looked great.

        X265 – appears to be working again. Will run longer test to be sure.

        X264 – Working still.

        X264.10 – Locks up machine, then:
        kernel: Out of memory: Kill process 29135 (ghb) score 676 or sacrifice child

        1. When “backing out” to 0.10.2-3 are you on Fedora 22 or 23?

          VP8 – same. Used setting of 14, quality is bad. As a test, backed out to version 0.10.2-3 and again used VP8 and setting of 14… looked great.

          HandBrake ships with a bundled libvpx 1.3.0. Fedora 22 has it in the repositories; Fedora 23 has version 1.4.0.

          X265 – appears to be working again. Will run longer test to be sure.

          HandBrake bundles an old x265 1.5 version on 0.10.2 and a x265 1.8 version in 1.0…

          Let’s say that if I want to push the same build on Fedora 22, 23+ and CentOS 7 I need to bundle libav, libvpx and x265; which is something I would like to avoid.

  36. For 0.10.2-3: I’m on Fedora 23. I had the source rpm and rebuilt it for F23.

    So for: HandBrake-1.0-10.57a9f48.fc23 what are we using for VP8? The bundled version or what is supplied with Fedora?

    Regarding x265 on 1.0-10.57a… ran the longer tests and all appears good.

    BTW, whatever happened to VP9… it used to be included when the encoding was so slow it was unusable. I’ve read that’s all been resolved, but now it has been removed just when it should work?

    In any event, I really appreciate you providing this repository. Thanks!

    1. For 0.10.2-3: I’m on Fedora 23. I had the source rpm and rebuilt it for F23.

      So it must be a bug in the newer HandBrake then, as the libvpx package is the system one, so used for both the 0.10.2 and the 1.0 build. I guess we just have to wait then.

      So for: HandBrake-1.0-10.57a9f48.fc23 what are we using for VP8? The bundled version or what is supplied with Fedora?

      Always what it’s bundled in Fedora; but as shown by your build, this does not make any difference.

      BTW, whatever happened to VP9… it used to be included when the encoding was so slow it was unusable. I’ve read that’s all been resolved, but now it has been removed just when it should work?

      According to the source code, VP9 has never been enabled:

      1. I’ll follow up with upstream regarding the libvpx issue. Hopefully they already are aware.

        Regarding VP9, I’m sure I didn’t imagine this – it was about a year or so ago – when it disappeared I didn’t much care because it was unusable… but as I mentioned the situation apparently has now changed. I’ll ask upstream about that also.

        Thanks again for the clarification and quick response.

  37. Just upgraded to F23 with MakeMKV 1.9.8-1.fc23.x86_64. App no longer opens, only get a “Application failed to initialize” popup window, running via console provides no further info.

    Was working fine just prior to the upgrade on F22.

    Any help?

  38. I’ve been running F23 for almost 2 months and haven’t had any issues with MakeMKV – including the recent version 1.9.8-1.fc23.x86_64; since you have just upgraded you might want to check for any other residual weirdness. Sometimes the upgrade doesn’t catch or cleanup everything – and you have to do it manually. Take a look at “optional” post-upgrade tasks here:

  39. I love HandBrake but unfortunately the latest unstable versions you ship seem to have a bug regarding the normalize feature (it simply does not work).

    Could you please also provide the stable 0.10.2 release, at least the CLI version?

    1. Sorry but I never used the normalize feature. It is the same passed as:

      --normalize-mix Normalize audio mix levels to prevent clipping.
      Separated by commas for more than one audio track.
      0 = Disable Normalization (default)
      1 = Enable Normalization

      in the command line?

      I can’t provide the 0.10.2 release in place of the 1.0 snapshot as it would make me go back in bundling a lot of libraries in the client. But I can provide an “HandBrake-010” package, although I would avoid it; so I would like to check if there is any issues with the libraries.

  40. Are you aware of the 0-day exploit that has been discovered in ffmpeg? It seems the current (2.8.4-1) version that you are offering is affected.

  41. Hi,
    I am getting dependency errors ie
    ffmpeg-libs (x86_64 ) fedora 23 complains
    about a missing

    I cannot find it anywhere ;(

  42. Grrr,
    I had the ‘free repository’ enabled but not the ‘nonfree’

    After enabling the nonfree repository the faac packages
    showed up.



  43. I did a clean install of Fedora 23 yesterday and I’ve not been able to get NVENC working with ffmpeg since then. I keep getting an error: “No NVENC capable devices found”

    I have the same GTX 760 card I was using successfully with Fedora 22 earlier in the week, so either I missed something simple when installing, something is packaged incorrectly or the newer Nvidia drivers dropped support for my card. Any ideas?

    1. Have you installed the correct driver Cuda packages? FFMPeg loads at runtime:

      $ strings /usr/lib64/ | grep -i libcuda

      If not, do an install of nvidia-driver-cuda and either reboot or load the nvidia-uvm module.

      Do you have any logs/output for the ffmpeg command?

  44. I already have nvidia-driver-cuda installed. The exact error message from ffmpeg is:

    [nvenc @ 0x85b300] No NVENC capable devices found

    Here is the full output from the command:

    Here’s the drivers I have installed:

    $ rpm -qa | grep nvidia-driver

    From this you can see nvidia_uvm appears to be loaded:

    $ cat /proc/modules | grep nvidia
    nvidia_modeset 741376 3 - Live 0xffffffffa0e94000 (POE)
    nvidia_uvm 561152 0 - Live 0xffffffffa0bee000 (POE)
    nvidia 10022912 60 nvidia_modeset,nvidia_uvm, Live 0xffffffffa01b0000 (POE)
    drm 335872 3 nvidia, Live 0xffffffffa0076000

    1. Hello, sorry for the late reply. Can you just try with the latest 2.8.6 ffmpeg version? If it doesn’t work, I will try to backport the 3.0.x changes to the NVENC encoder.

    1. Hello, sorry for the late reply. I tried to use FFMpeg 3.0.x for the latest builds, the source contains a lot of changes for NVENC 6.0; but unfortunately FFMpeg 3.0 is not yet compatible with VLC (not even a git snapshot).

      I’m keeping an eye on VLC commits, and if it works with it I will update the FFMpeg packages.

  45. Pretty frustrating that the latest version isn’t backward-compatible and has rendered my script unusable. Thanks for being conscientious about backward-compatibility.

  46. Is it possible to update this package with a recent git snapshot? The update situation in Fedora is pathetic at best, since this package has been orphaned. Also, and this is where this repository kicks in, the last time I checked projectM it linked against a NVIDIA proprietary SDK to produce OpenGL 2.1+ compliant shaders. That’s why every Linux distro on Earth disables that part of projectM.

    Can you come to the rescue?

    1. Hello, for now I just rebuilt the version that is shipped in Fedora also for RHEL/CentOS 7, will look if I can build a more recent snapshot from GIT (the last tarball is from 2014!!).

  47. On Fedora 23, installing HandBrake-cli returns:

    Error: package HandBrake-gui-1.0-17.12f7be2.fc23.x86_64 requires, but none of the providers can be installed

    Any ideas where to go from here? dnf install libx265 comes up empty.


    1. I am having the same issue. Did you find a solution?

      I have a previous version installed and they have upgraded with dnf without issue.

      1. I don’t have any issue, how come? I’ve tried a lot of encoders and settings, but everything works fine.

        Can you try saving (exporting) your presets and then wiping HandBrake’s configuration directory? The issue is somewhere in the Json files used for configuration and the new version.

        1- Export presets in files
        2- Remove ~/.config/ghb
        3- Start, re-import preset

        Can you try this?

  48. the Fedora handbrake repositories now seem to include gstreamer plugins that override the ones in rpmfusion. Is this on purpose? It also combined them and gave them a different name

    gstreamer1-plugins-bad x86_64 1:1.6.3-2.fc23 fedora-HandBrake 2.2 M
    replacing gstreamer1-plugins-bad-free.x86_64 1.6.3-3.fc23
    replacing gstreamer1-plugins-bad-free-extras.x86_64 1.6.3-3.fc23
    replacing gstreamer1-plugins-bad-freeworld.x86_64 1.6.3-1.fc23

    1. Hello, sorry for the late reply. Yes it is, I tried to submit patches upstream for the free and free-extras subpackage to no avail, and I was trying to add all missing plugins to freeworld. So a simple package seemed to be a better choice.

      1. won’t that cause constant flipflop between packages when packages from rpmfusion update before you do, and then you update them ?

        1. Not really, I’ve bumped the Epoch in most packages (Nvidia, multimedia libraries, etc.) just to avoid that. So nothing should jump in from another repository.

  49. Will you ever put up a gitlab (or similar) tracker for your repositories? It’d be nice to submit real bug reports or spec fixes outside of these comment fields. Maybe you don’t get enough bug reports for it to be worthwhile though.

    1. I receive a lot of comments, and putting everything on a public git has been sitting on my todo list for quite a while, including renaming the HandBrake repository into something more appropriate. Unfortunately time is scarce.

  50. I have run into an odd problem while trying to convert *.mkv to *.mkv. I am receiving an ‘Encode failed’ immediately after starting the encode. The first apparent error in the Activity log is ’22:10:49] hb_parse_filter_settings: Error parsing (0)’ and the last error in the error chain is ‘** (ghb:5919): WARNING **: CanSuspend failed: The name org.freedesktop.PowerManagement was not provided by any .service files’. Any ideas?

    1. i’ve not been able to generate any mkv files after the last big os update i did. mp4s work fine but not mkv, i get a
      22:45:02] json unpack failure, failed to find title: Object item not found: Path
      [22:45:02] hb_dict_to_job: failed to find title: Object item not found: Title
      [22:45:02] thread 7f0a6097a700 exited (“work”)
      [22:45:02] thread 7f0a6097a700 joined (“work”)
      [22:45:02] libhb: work result = 3

      i’ve been trying to downgrade package to see what caused this but no luck finding the correct one so far.

      1. where can i find the prior version of handbrake rpm, it is not up on the repository so i’m unable to use the ‘dnf downgrade’ to see if that fixes my mkv issue.

  51. i couldn’t find an older rpm version so i download the 0.10.1 source, build the software and it works just fine. I tried the latest version of the source and it doesn’t work. so it wasn’t the fedora build that is bad, there is something in the main code that is bad. I won’t be upgrading anytime soon to newer versions.

      1. I don’t have any issue, how come? I’ve tried a lot of encoders and settings, but everything works fine.

        Can you try saving (exporting) your presets and then wiping HandBrake’s configuration directory? The issue is somewhere in the Json files used for configuration and the new version.

        1- Export presets in files
        2- Remove ~/.config/ghb
        3- Start, re-import preset

        Can you try this?

  52. uppdate: i tried all the releases of 0.10.x from the main handbrake website and the only versions that will generate a working mkv file are: 0.10.2 and 0.10.5. the current branch does not work. i download the source and build on my system and tested all the 0.10.x version. i hope this is helpful to someone else having issues generating mkv files.

  53. If avidemux from rpmfusion is installed this repo can’t be used since it depends on rpmfusion x264/x265 lib versions. After uninstalling avidemux it works, but avidemux can’t be installed due to the same reason. Would it be possible that you provide it as well in your repo rebuilt for your lib versions? I see you do that already for other packages like vlc.

    1. I’m not willing to support any software available around, but since I’m doing lots of encoding I might do. Will look into it.

  54. Just for clarity, my response was related to the issue of upgrading to the latest version but getting unmet dependencies. After removing avidemux, I was able to upgrade without issues.

  55. I seem to be having trouble around libmmbd/libaacs. I get the following errors from bd_info with MMBD_TRACE set to 1:

    MMBD: MakeMKV v1.9.9 linux(x64-release) started
    MMBD: Debug logging enabled, log will be saved as /tmp/MakeMKV-0x129c-1.tmp
    MMBD: DEBUG: Code 0 at juQ.:SSdCo1&\v_qAG(E:29398760
    MMBD: DEBUG: Code 0 at juQ.:SSdCo1&\v_qAG(E:29398760
    MMBD: Opening files on harddrive at /dev/sr0
    MMBD: DEBUG: Code 0 at a+L@]K0q>HdTM;ug:121266396
    MMBD: DEBUG: Code 0 at a+L@]K0q>HdTM;ug:213131916
    MMBD: DEBUG: Code 0 at a+L@]K0q>HdTM;ug:121265660
    MMBD: Failed to open disc
    aacs.c:295: get_aacs_data(DISC_ID): libaacs not initialized!
    dec.c:208: aacs_open() failed!
    bdj.c:457: BD-J check: Failed to load JVM library

    And it gives me this info for AACS:

    AACS detected       : yes
    libaacs detected    : yes
    Disc ID             : 0000000000000000000000000000000000000000
    AACS MKB version    : 0
    AACS handled        : no
                          (corrupted BluRay disc)

    Using makemkvcon directly works just fine, with no problems whatsoever.

    My assumption is this means that LIBBDPLUS_PATH and LIBAACS_PATH aren’t being respected. I symlinked /usr/lib/, /usr/lib/, /usr/lib64/, and /usr/lib64/ to /usr/lib64/, but that hasn’t changed the output at all.

    Am I barking up the wrong tree? Is there something else I should try to do to debug? Any suggestions would be appreciated. Thanks for making this whole thing so much simpler.

    1. Hi Peter, I think everything is correct on your side.

      The library are detected fine by the environment, otherwise you wouldn’t get any output from the TRACE, as the library would not be loaded. The symlink thing you did is then useless and also wrong, as you are linking 64/32 bit libraries together, so they are not loaded by ldconfig; please restore it to what is installed by the packages. Also makemkvcon is launched in the background while loading the library (makemkvcon is basically a blu-ray player with a valid commercial key) and by launching the GUI program, so it is the same as launching it manually.

      I have one Blu-Ray that exhibits the same problem, I think this due to the fact that the keys in it are not yet availabel for MakeMKV. As you can see from the changelog I’ve put in the package (/usr/share/doc/makemkv/changelog.txt), they are adding updated AACS keys at almost every release. So I’m guessing that it might be still not supported.

      Do other Blu-Rays you own work properly?

  56. > The library are detected fine by the environment, otherwise you wouldn’t get any output from the TRACE, as the library would not be loaded.

    Hm, now that you mention it, that makes a lot of sense.

    > The symlink thing you did is then useless and also wrong, as you are linking 64/32 bit libraries together, so they are not loaded by ldconfig; please restore it to what is installed by the packages.

    I had a feeling, but felt it was worth a shot. Definitely going back to the vanilla install.

    > Do other Blu-Rays you own work properly?

    So that’s the funny part. I think I found one or two Blu-rays that actually work, after trying like ten. (Honestly, this was like 12 hours ago amidst a bunch of throwing things at the wall to see what stuck, so don’t quote me on that. I know that the failure rate when pointing Handbrake at the /dev/sd0 device was so overwhelming I stopped trying different disks and went back to trying to figure out what was wrong with my setup.) But what’s super weird is that I can use makemkvcon itself to export an mkv file from the Blu-ray, then process that mkv file with Handbrake. No problems there, and it’s the workaround I’m using at the moment. But trying to process directly off the Blu-ray throws the errors I quoted above at me. My understanding was that because libmmbd was being used, the same Blu-rays that makemkvcon supports would also be supported by Handbrake and bd_info, but it seems like the vast majority of my Blu-rays work with makemkvcon but have aacs errors when using HandbrakeCLI or bd_info. Which is why I suspected libmmbd wasn’t being used. Now I suspect I’ve fundamentally misunderstood the benefits of libmmbd.

    Is this making sense, or am I just spewing nonsense at you? I’ll confess I have the vaguest idea about what I’m doing, and spent the last day or two reading all the guides and info I can find this, but the odds that I’ve misunderstood something are really rather high.

    1. It all make sense. Actually, if I need to rip a disc, I always go through MakeMKV first and then convert the MKV file after. It can take hours, so it’s also a good thing to avoid the mechanical drive to spin up & down all the time for a very long time. The benefits of MakeMKV are what is depicted in the guide, so AACS/BD+/DCSS (and other protection mechanisms) decryption, with “transparent” support for Blu-Rays in libbluray.

      After having said that, I never ripped Blu-Rays through HandBrake directly, so I don’t know if it works. What you can do to see if your setup is working properly, it’s just use plain libbluray and makemkv packages as I ship them and see while accessing the disc through your libbluray based program (VLC, HandBrake, whatever) if you have a makemkvcon process running on your system in the background. If it is, you are using libmmbd support for decryption.

      1. Good advice, thanks! And thanks for making these packages available. At the very least, I’m glad my “workaround” isn’t so much a workaround as it is the right way to do things. It felt redundant and unnecessary to me, but what you’re saying about spinning the drives makes sense.

        I think I’ll stick with the MakeMKV-creates-an-mkv-file -> Handbrake-converts-the-mkv-file workflow for now, as it’s not a silly hack but a Good Way To Do Things.

  57. I have HandBrake-gui and HandBrake-cli installed but I only have a HandBrakeCLI binary. HandBrake-gui was successfully installed and I have the package but I just have no actual gui for HandBrake. Anyone know what this could be? Fedora 23.

    1. Have you tried checking your applications menu in your Desktop environment? There’s a shiny icon and title πŸ˜€

      1. I use a window manager so I don’t normally get to things by an application menu so I logged into Gnome and yep, HandBrake is there. Apparently I have to launch the program through gnome-software if I’m just using a WM. I’ve never had this happen with any other program so I’m a bit confused as to the logic of it. Oh well, at least I can access it now.

        1. You are taking for granted that a package for a program contains a binary with the same name, which is absolutely not true. If you look at the hundreds of binaries in your system they 99% don’t come from a package with the same name.

          You don’t need any Gnome software, just check the binary you need to run:

          $ rpm -ql HandBrake-gui | grep bin
          1. I don’t expect the package name and binary name to be the same but I do expect the binary to have a similar name to what program it represents eg. handbrake, handbrake-gui, HandBrake-gui etc.

            Thanks a lot. Knew the binary had to be there somewhere.

  58. So did something break in the latest F22 updates? Makemkv was working fine for me for the last few weeks then I left it alone for a while and now makemkvcon just sucks up 100% cpu and accomplishes nothing, can’t get the GUI to open up or the debug flag to change anything.

  59. Been using your repos for awhile and I know that Fedora 24 hasn’t been officially released or supported, but I’m already using it and have been trying to get Handbrake to work on it. I’m currently running into a segfault whenever I try to rip a DVD or convert anything from MakeMKV. Is there anywhere in particular that I can look to try and pinpoint the issues that I’m having or files that might point me in the right direction? I’ve already tried running ghb using -x for debug and it gives me the segfault after the find_queue_job runs, but so far that’s not been much help for me to figure out what the root cause is. Anyway, it may be something that I just need to wait until 24 is officially supported, but wanted to check in anyway. Thank you for your work on this!

    1. Tried running just a simple conversion (just input and output flags) on my MKV file I created and end up with the following output:

      [15:31:09] sync: expecting 155911 video frames
      HandBrakeCLI: libFDK/src/fixpoint_math.cpp:546: FIXP_DBL fDivNorm(FIXP_DBL, FIXP_DBL, INT*): Assertion `L_num >= (FIXP_DBL)0′ failed.

        1. Doesn’t seem to matter which MKV file I use from MakeMKV, they all error out. It’s the CLI version HandBrake 20160525073544-879a512-unknown.

    2. Hello, do you have the problem on MakeMKV or HandBrake? Both are running fine here on Fedora 24, I use them daily. From my side, Fedora 24 is fully supported, so if you have any issue I would consider this a bug/packaging problem.

      1. MakeMKV seems to be working just fine, I can pop in a DVD, select the tracks I want and then create the MKV. I can then convert it to MP4 just fine using ffmpeg. I’m currently using Handbrake version 20160525073544-879a512-unknown (x86_64).

      2. Just ran an upgrade on the packages, and everything appears to be running fine now. Not sure what caused either of the two issues, but I’m back on track again!

Leave a Reply