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.

8 thoughts on “Updated builds of HandBrake/MakeMKV with system libraries

  1. I’m seeing segmentation faults when transcoding MPEG-TS content, problem occurs in libavcodec.so.55.39.101 using ffmpeg-libs-2.1.4-1.fc20.x86_64 from RPM Fusion.

    It doesn’t happen on a Windows build of HB 0.9.9 nor with these Linux builds: http://sourceforge.net/projects/handbrakerpm/files/x86_64/GUI/

    So I would guess that this is another of the GCC 4.8 bugs HB was experiencing with F19 a little while ago, or something in ffmpeg 2.1 broke ABI.

    1. If HandBrake is compiled with statically linked libraries from its own bundled & patched copies there are no issues. What I’m trying to do with this builds is to have a fully dynamically linked binary that can be later imported in RPMFusion or similar.

      I’ll be packaging a new snapshot version soon, some of the compatibility issues have been sorted out in the new development version.

Leave a Reply