This repository contains multimedia programs that I use on my systems. The full list is as follows:
- HandBrake with supporting programs MakeMKV and libdvdcss
- CUDA enabled FFMpeg with most of the possible options
- CUDA enabled Blender
- CDRtools in place of cdrkit for burning Blu-Rays and any other kind of disc
- VLC and MPV media player, again compiled with most options enabled
- GStreamer plugins with additional forbidden codecs and compilation options
- Nvidia driver, CUDA with additional libraries and Video SDK components
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 is NOT compatible with RPMFusion, nor it does attempt to replace it as I have no interest in adding any software out there.
For details on the Nvidia components, please read the relevant page for the Nvidia-only repository. The packages hosted in this repository are exactly the same.
This repository requires the EPEL repository to be enabled if you’re running CentOS/RHEL.
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 – x86_64/aarch64
- Red Hat Enterprise Linux (and derivatives) – x86_64/aarch64
Not all distributions are on par regarding features and packages, and this is mostly true to RHEL where not all the required libraries are available at the correct version. Let’s say most of the development goes on to the latest Fedora release due to it being my daily desktop, and there everything is supported.
Most of the desktop packages that ship with a menu icon and launcher are also available in Gnome Software, just type something in the search bar:
Table of Contents
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.
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.
Installing HandBrake/MakeMKV/libdvdcss
To install the repository on a supported Fedora distribution, run as root the following command:
dnf config-manager --add-repo=https://negativo17.org/repos/fedora-multimedia.repo
To install the repository on CentOS/RHEL:
yum-config-manager --add-repo=https://negativo17.org/repos/epel-multimedia.repo
Then, to install the HandBrake packages (as an example both the graphical interface and the command line tool), perform the following commands:
yum/dnf -y install HandBrake-gui HandBrake-cli
For MakeMKV:
yum/dnf -y install makemkv
For libdvdcss:
yum/dnf -y install libdvdcss
Registering MakeMKV to avoid expiration
Please use the provided beta registration key published by the developers:
http://www.makemkv.com/forum2/viewtopic.php?f=5&t=1053
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/makemkv.sh export LIBBDPLUS_PATH=/usr/lib64/libmmbd.so.0 export LIBAACS_PATH=/usr/lib64/libmmbd.so.0
This is equivalent to set an explicit library override in your library directory:
ln -sf libmmbd.so.0 libaacs.so.0 ln -sf libmmbd.so.0 libbdplus.so.0
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 VLC playing a Blu-Ray disc:
MMBD_TRACE=1 vlc
Fully fledged FFMpeg binaries
It 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 is available here and 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, along with much more stuff:
- 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
- NVENC/CUDA (Nvidia H.264/265 GPU hardware encoder/decoder)
- QSV (Intel Quick Sync Video H.264/265 CPU hardware encoder)
- HE-AAC+ (3GPP AAC+ High Efficiency Advanced Audio Codec v2 encoder)
- H.264/H.265 (through various meaning, x264, x264, OpenH264, Kvazaar)
This FFMPeg libraries are 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 hard dependencies if feasible.
To install the main FFMPeg binary and enable transcoding of practically everything, proceed as you would with a normal package:
yum/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 idea is to have all the possible codecs/transports supported out of the box.
CUDA/FFMpeg enabled Blender
The 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.
Plex Media Player
The Plex Media Player works as a standalone player and also as the main interface for an HTPC setup, where the “TV interface” starts as the main thing when you power up your system.
Plex Media Player uses MPV in the background, so any compilation option that was added to MPV, is now also part of Plex Media Player by using the same libraries that were already available in the multimedia repository.
To install it on Fedora, just perform the following commands:
dnf -y install PlexDesktop
You will then find it along with the other applications in your menu. You will be greeted with the familiar Plex web interface, with the main difference being that the player is local through the MPV library.
If you are instead planning to do an HTPC installation, and would like to have Plex Media Player starting instead of the login screen the moment you boot the device, execute the following commands as root:
dnf install plex-media-player-session systemctl set-default plex-media-player echo "allowed_users = anybody" >> /etc/X11/Xwrapper.config
The first command installs the required files (services, targets and PolicyKit overrides). The second command instructs the system to load by default the Plex Media Player target; that is X immediately followed by the player itself. The third command allows the system to start the X server as the Plex Media Player user, otherwise only users logged in through a console or root can start it.
You will be greeted with the TV interface just after boot:
If you want to go back to your normal installation (let’s say Gnome), then revert back the changes (again type the following commands as root):
systemctl set-default graphical sed -i -e '/allowed_users = anybody/d' /etc/X11/Xwrapper.config rpm -e plex-media-player-session
CUDA enabled MPV
This has been already available for a long time, but with FFmpeg 3.3, CUDA dynamic support loading is enabled also in MPV, so the hard dependency on the CUDA library is gone, and the binaries load the library dynamically:
$ strings /usr/bin/mpv | grep libcuda libcuda.so.1 $ strings /usr/lib64/libmpv.so.1.25.0 | grep libcuda libcuda.so.1
So assuming you have the Nvidia driver already installed with the appropriate CUDA part, you can then play a video with the following command line:
mpv --hwdec=cuda /path/to/video.file
And then check with nvidia-smi
or with the Nvidia control panel if the video engine is being utilized:
If you want to enable that by default, just make sure your configuration file has something like this inside:
$ cat ~/.config/mpv/mpv.conf
hwdec=nvdec
Apart from CUDA support, MPV as well has been built with all possible options enabled out of the box.
Sonarr, Radarr, Lidarr, Prowlarr, Jackett and Tautulli
You can easily install Sonarr, Radarr, Lidarr, Prowlarr, Jackett and Tautulli. This allows you to populate and maintain automatically your TV Shows, Movies and Music libraries without effort for Plex consumption.
Tautulli is not particularly useful if you are not hosting Plex for third parties, but gives you anyway statistics and information in a nice GUI for consumption and also notifies you any time one of the other tools adds something to a library.
All of them come with proper System units and Firewalld rule definitions. So should be a breeze to enable them on the system.
# dnf -y install sonarr radarr lidarr prowlarr jackett tautulli
# for service in sonarr radarr lidarr prowlarr jackett tautulli; do
systemctl start $service
systemctl enable $service
firewall-cmd --add-service=$service
firewall-cmd --add-service=$service --permanent
done
Combine them with something like Transmission web UI and you’re done.
Spotifyd
There is a Spotifyd package, which allows you to turn any system into a Spotify client and/or Spotify Connect speaker. Without any configuration file it just works like a WiFi speaker support Spotify Connect, with a configuration file that contains a Spotify Premium username and password you have a fully connected client that you can control with the Spotify phone app like any other client.
If your computer or Plex server is always on, why not use it also as a WiFi speaker?
For example:
This list comes from my phone, and I’m in the same network of the laptop. Everything else is signed in with my account or has been playing something when I was close by, so it’s still logged in.
The version currently in the repositories is built to also support PulseAudio as a backend, as the plan is to run this on a fully fledged Fedora/CentOS/RHEL system. The binary release offered on the Github project is built with only Alsa as a backend as it requires a considerable less amount of libraries as dependencies; making it suitable for running on a barebone Raspberry Pi.
Bugs
Please open bugs to the relevant Github repository. The address for contacting me is in the packages’ changelog, otherwise leave a comment in the post, I’ll do my best to reply to everyone.
after some tweaking I’m still unable to play videos with totem. Now I get:
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
(totem:8073): Cogl-WARNING **: driver/gl/cogl-framebuffer-gl.c:983: GL error (1280): Invalid enumeration value
(totem:8073): Gtk-WARNING **: Calling Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
Any ideas how can I fix it?
This seems to be a bug somwhere, there are a lot of reports open:
https://bugzilla.redhat.com/show_bug.cgi?id=1123536
https://bugzilla.redhat.com/show_bug.cgi?id=1373217
Can you try the following?
And retry? This should effectively disable video acceleration. If it does not, then try the following:
Please paste your results.
On Fedora 24, 64bit
Hello, where are you getting the
libav-libs
package from? It’s not in Fedora nor RPMFusion. And I Guess it will create anyway problems if you want to load in memory the ffmpeg libraries with the same names that are in theffmpeg-libs
package.Wierdly, no source is listed. Not a repository, not a @@commandline…
When I try do “dnf erase” it, it lists it from @@commandline
Nothing depending on it, so I’ve removed it, and now packages update fine
Out of curiosity, I then tried to reinstall libav-libs, and it comes from postinstallerf. Since I don’t need it, I aborted the installation.
Sorry for the noise!
Just FYI, that
libav-libs
is from DavidVA/kuboosoft’s PostInstallerF set of packages, which I believe has also now been incorporated into UnitedRPMs.vlc-3.0.0-7.20161008gitc910cc6.fc24.x86_64 no longer seems to be playing mp3’s for me, since I updated. I get:
[000055dfc93748b8] core audio output error: module not functional
[00007f71f0c05af8] core decoder error: failed to create audio output
Just me or do I need to do something new to get mp3 support back?
There was a bug in VLC upstream. The Mpeg Audio plugin has been reworked and it works now.
I’m uploading a new build now.
Thanks it’s all good now
Hi and thanks for all the work you’ve done! I have a small dependency problem with this repository though. First of all, here are my versions/specs:
– CentOS 7, 64bit
– GraphicsMagick, version 1.3.25, release 1.el7, from the epel repository
When I do a yum upgrade, I get the following dependency conflict:
Error: Package: GraphicsMagick-1.3.25-1.el7.x86_64 (epel)
Requires: libwebp.so.4()(64bit)
Available: libwebp-0.3.0-3.el7.x86_64 (base)
libwebp.so.4()(64bit)
Installed: libwebp-0.4.4-1.el7.x86_64 (@epel-HandBrake)
~libwebp.so.5()(64bit)
Can you suggest what to do?
Hello, I’ve just become dad, so I was disconnected for a few days. The rebuilt GraphicsMagick is now in the repositories.
I have installed the lastest (370.28-1.fc24.x86_64) Nvidia drivers, the latest CUDA drivers (cuda-devel-1:7.5.18-4.fc24.x86_64), and the latest CUDA dev packages (cuda-devel-1:7.5.18-4.fc24.x86_64). When I install FFMPEG from your repository, and check for hardware acceleration support, this happens:
# ffmpeg -decoders -hide_banner | egrep -i “Intel Quick Sync|NVIDIA”
V….D h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264)
V….D hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)
V….D mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video)
V….. vc1_qsv VC-1 video (Intel Quick Sync Video acceleration) (codec vc1)
No trace of NVENC anywhere… I checked your repo for nvenc and found this:
nvenc-7.0.1-1.fc24.noarch
nvenc-samples-7.0.1-1.fc24.noarch
So I installed them. Same result.
Then I tried to install nvenc-devel from rpmfusion, but it conflicts with your packages, and asks to remove them. So I did, and still no NVENC in FFMPEG.
I have a GTX-650. I was trying to experiment with this before buying a Pascal video card, and don’t know what I’m doing wrong…
Please take time to read the instructions. It’s described here (look for nvenc): http://negativo17.org/handbrake/
You’re doing too much stuff which is absolutely not required.
1- You don’t need to install
cuda
2- You don’t need to install
nvenc
(it contains just header for compiling nvenc support in other programs, like ffmpeg)3- You don’t need to install
nvenc-samples
You need:
nvidia-driver
,nvidia-driver-cuda
andffmpeg
.ffmpeg
loads dynamicallylibcuda.so.1
if you invoke the NVENC encoder. Also, NVENC, as the name suggests, it’s an encoder option, not a decoder. With the command you provided you’re just checking for decoders.Thanks! I got confused because your post says:
‘$ ffmpeg -decoders -hide_banner | egrep -i “Intel Quick Sync|NVIDIA”
V….D h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264)
V….D hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)
V….D mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video)
V….. vc1_qsv VC-1 video (Intel Quick Sync Video acceleration) (codec vc1)
$ ffmpeg -encoders -hide_banner | egrep -i “Intel Quick Sync|NVIDIA”
V….. h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264)
V….. nvenc NVIDIA NVENC h264 encoder (codec h264)
V….. nvenc_h264 NVIDIA NVENC h264 encoder (codec h264)
V….. nvenc_hevc NVIDIA NVENC hevc encoder (codec hevc)
V….. hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)
V….. mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video)’
And it says ‘nvenc’ in your config and not in mine… In my setup, though, when replacing ´-decoders’ with ‘encoders’, nvenc appears.
If you carefully read it, you’ll see he’s issuing a second command:
$ ffmpeg -encoders -hide_banner | egrep -i “Intel Quick Sync|NVIDIA”
Oh! You’re right! Thanks!
I installed vlc x86_64 Version 3.0.0 Release 4.749293f.fc24 out of repo fedora-HandBrake.
Icons and other things are too big and fonts are distorted.
I resetted vlc and deleted config-directory.
No change.
How to have back usual vlc?
I already reported this issue: https://github.com/negativo17/vlc/issues/1
The problem is VLC enabled a QT HiDPI setting and changed DPI calculations. A workaround is to start VLC like this:
env QT_AUTO_SCREEN_SCALE_FACTOR=0 vlc
Nice catch. Adding env QT_AUTO_SCREEN_SCALE_FACTOR=0 allowed VLC to work again for me.
Fedora 24
VLC media player 3.0.0-git Vetinari (revision 2.2.0-git-8681-g749293f)
VLC version 3.0.0-git Vetinari (2.2.0-git-8681-g749293f)
Compiled by mockbuild on (Aug 21 2016 22:09:45)
Compiler: gcc version 6.1.1 20160621 (Red Hat 6.1.1-3) (GCC)
I was seeing the following before:
$ vlc -v 2
VLC media player 3.0.0-git Vetinari (revision 2.2.0-git-8681-g749293f)
[00005557a8ea71c8] core libvlc: Running vlc with the default interface. Use ‘cvlc’ to use vlc without interface.
QWidget::setMinimumSize: (/QStatusBar) The largest allowed size is (16777215,16777215)
QWidget::setMaximumSize: (/QStatusBar) The largest allowed size is (16777215,16777215)
QXcbConnection: XCB error: 3 (BadWindow), sequence: 423, resource id: 39845892, major code: 2 (ChangeWindowAttributes), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 424, resource id: 39845892, major code: 18 (ChangeProperty), minor code: 0
When I playback an MKV file on VLC and use the Speedup Playback option – using the ] key – in the past it used to work perfectly. Now, since I am on Fedora 24, the audio just becomes a series of loud clicks.
This is what I have installed:
# rpm -qa | grep -E “vlc|ffmpeg” | sort
ffmpeg-3.1.2-2.fc24.x86_64
ffmpeg-compat-0.6.7-9.fc24.x86_64
ffmpeg-libs-3.1.2-2.fc24.x86_64
gstreamer-ffmpeg-0.10.13-15.fc24.x86_64
vlc-3.0.0-4.749293f.fc24.x86_64
vlc-core-3.0.0-4.749293f.fc24.x86_64
Is this a VLC bug? FFMPEG bug? Any advice?
Thanks for your awesome contributions.
I guess it’s a VLC bug. Will look into it.
How can i install MakeMKV? here is my problem:
$ sudo dnf install makemkv
[…]
Error: Transaction check error:
file /usr/share/doc/glibc/NEWS from install of glibc-2.23.1-10.fc24.i686 conflicts with file from package glibc-2.23.1-7.fc24.x86_64
[…]
That’s a mismatch with 32/64 bit libs in the repositories, it has nothing to do with the MakeMKV packages. Clean up your dnf cache and try again, otherwise wait/pull down updates from updates-testing.
Error: nothing provides gstreamer1-libav = 1.8.2-2.fc24 needed by gstreamer1-libav-devel-docs-1:1.8.2-2.fc24.noarch.
package gstreamer1-plugins-ugly-devel-docs-1.8.2-1.fc24.noarch requires gstreamer1-plugins-ugly = 1.8.2-1.fc24, but none of the providers can be installed.
package gstreamer1-vaapi-devel-docs-1:1.8.2-1.fc24.x86_64 requires gstreamer1-vaapi = 1.8.2-1.fc24, but none of the providers can be installed
any idea how to fix this?
I simply can not update these packages:
Skipping packages with broken dependencies:
gstreamer1-libav
gstreamer1-libav-devel-docs
gstreamer1-plugins-ugly
gstreamer1-vaapi
It should be fixed now. Thanks for reporting.
Yes indeed, it is fixed now. Thanks for the fast reply 🙂
Hi, I’m on Fedora 23 and latest build handbrake (1.0-25.56c7ee7.fc23) w/ xfce4. I’m unable to choose presets. It is very weird.
Can you try to back up your presets, erase your preference folder (
~/.config/ghb/
) and try to reimport them? The format has changed substantially in the various releases.If you are not able to do that through the gui you can just back up the
.json
files in your profiles folder.THX for ur reply.
I tried that, now I can only choose from “Legacy”. Other categories won’t take any effect.
Not to be a *total* noob.. would you folks mind telling me where/how to find the HandBrake logs so I can figure out what I broke / didn’t ‘fedup’ right?
I took a Fedora 22 install, upgraded to 23 and *cannot* get HandBrake to run. The GUI is fine, When I start the job, it simply exits to the command line with status return 127 (meaningless)
Hi, can you try the latest build (1.0-25.56c7ee7.fc23) I’m just uploading? It contains a lot of fixes.
Very weird. If I run those commands I get
So the binary’s coming from the correct RPM but somehow is linked – or believes it’s linked – to an older library.
I’ve done a dnf clean, update and reinstall, to make sure I’ve only got the fedora-HandBrake packages but it’s still messing me around.
Oh, and I checked that there isn’t some other random source installation of makemkv on my system – only the one from the repo.
Uhm, you should also have a dependency problem then with the packages and not only the program failing to run if the libraries are missing. My only guess is that the package was installed while I was still rebuilding Fedora 24 quite some time ago and you force installed something else as
dnf
would have prevented installation.Can you do a
dnf reinstall makemkv
? I think that should fix it.Ah, can you also please paste here the output of
rpm -qi makemkv
before reinstalling? Thanks.Sorry for the delayed response – not had much of a chance to look at this recently.
rpm -qi makemkv
givesThe reinstall hasn’t improved anything – it’s still complaining it can’t find
libavcodec.so.56
The package is correct, same as the one I’ve published, but the executable are linked to the correct libraries, so that error does not come from my package:
Are you sure you don’t have any depdendency problems? Are you using my
ffmpeg
packages?I guess there is something else loaded that then complains about the missing library.
Bizarrely, it looks like it’s
makemkcom
– I’ve just done a reinstall, ensuring only fedora-Handbrake repo was enabled and checked the executables withldd
:$ ll /usr/bin/makemkv*
-rwxr-xr-x 1 root root 25326144 Apr 22 16:16 /usr/bin/makemkv
-rwxr-xr-x 1 root root 5406944 Apr 22 16:16 /usr/bin/makemkvcon
$ ldd /usr/bin/makemkvcon | grep libav
libavcodec.so.56 => not found
libavutil.so.54 => not found
which is mystifying as the two commands you suggested
rpm -q --requires makemkv | grep libav
andrpm -qvl ffmpeg-libs.x86_64 | grep lib64
show dependencies onlibavcodec.so.57
andlibavutil.so.55
.Which is not my package again, as my binary is ok:
By chance, do you have both i686 and x86_64 packages installed? This is all you should have:
I guess there is something wrong on your system which in turns load the previous FFMpeg library. Even if the program is linked, your system might pull in something else. Can you do the following?
Found it! I had a rogue
libmakemkv.so.1
from 2014 in/usr/lib
. That’s what you get for doing an upgrade rather than a reinstall, I guess.Thanks very much for your help 🙂
There is a new version of Blender out, please consider updating the repo. Thank you.
I’ve updated it to 2.77a for Fedora 24 already mid June.
Which distribution are you using? This can’t be updated on other releases due to Python differences; unless I bundle Python in it.
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!
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.
Which distribution, which package version? Can you provide the MKV file somewhere?
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.
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.
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).
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!
Can’t seem to get it to work on fedora 24 – I just get
/usr/bin/makemkvcon: error while loading shared libraries: libavcodec.so.56: cannot open shared object file: No such file or directory
which is right as ffmpeg-libs installed libavcodec.so.57 and it’s the one from here:
I’ve tried numerous updates, reinstalls, symlinks, etc – all the usual tricks – and nothing seems to work.
Any clues?
It seems you are running a very old MakeMKV package, the command
makemkvcon
is actually linked tolibavcodec.so.57
: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.
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.
Have you tried checking your applications menu in your Desktop environment? There’s a shiny icon and title 😀
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.
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:
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.
> 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.
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
andmakemkv
packages as I ship them and see while accessing the disc through yourlibbluray
based program (VLC, HandBrake, whatever) if you have amakemkvcon
process running on your system in the background. If it is, you are usinglibmmbd
support for decryption.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.
Oh well, it seems there are patches coming in for Blu-Rays:
https://github.com/HandBrake/HandBrake/commits/master
I seem to be having trouble around libmmbd/libaacs. I get the following errors from bd_info with MMBD_TRACE set to 1:
And it gives me this info for AACS:
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/aacs.so.0
,/usr/lib/libbdplus.so.0
,/usr/lib64/aacs.so.0
, and/usr/lib64/libbdplus.so.0
to/usr/lib64/libmmbd.so.0
, 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.
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. Alsomakemkvcon
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?
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.
Yeah, sure, no problem, I understood. I’m dubious what to do, if people want to help with packages they’re welcome to. I’m moving my build stuff here with all the branches:
https://github.com/negativo17/
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.
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.
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.
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.
Not happening at all here, don’t know what causes it. But there is some fix available apparently:
https://github.com/HandBrake/HandBrake/commit/6c56b2bed72bbb5f4d4d5b14307385ef42225b83
Will release a new build soon.
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?
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?
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.
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.
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.
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.
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
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.
won’t that cause constant flipflop between packages when packages from rpmfusion update before you do, and then you update them ?
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.
so you plan on maintaining the gst plugin stuff in perpetuity?
Until the things I want/plan to include/change are included for sure.
On Fedora 23, installing HandBrake-cli returns:
Error: package HandBrake-gui-1.0-17.12f7be2.fc23.x86_64 requires libx265.so.79()(64bit), but none of the providers can be installed
Any ideas where to go from here? dnf install libx265 comes up empty.
Thanks
Oops, to be clear I was attempting to install HandBrake-cli and HandBrake-gui
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.
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?
Thank you for all your hard work on HandBrake and maintaining repositories for MakeMKV, Steam, etc.
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?
https://sourceforge.net/projects/projectm/
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!!).
Pretty frustrating that the latest version isn’t backward-compatible and has rendered my script unusable. Thanks for being conscientious about backward-compatibility.
Which version of which component are you referring to?
Please upgrade ffmpeg to latest version to enable nvenc_hevc encoder and h265_qsv encoder.
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.
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:
https://gist.github.com/robertc/dfeb432a2f3ce5489625
Here’s the drivers I have installed:
$ rpm -qa | grep nvidia-driver
nvidia-driver-361.28-2.fc23.x86_64
nvidia-driver-cuda-361.28-2.fc23.x86_64
nvidia-driver-NVML-361.28-2.fc23.x86_64
nvidia-driver-cuda-libs-361.28-2.fc23.x86_64
nvidia-driver-libs-361.28-2.fc23.x86_64
nvidia-driver-libs-361.28-2.fc23.i686
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
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.
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?
Have you installed the correct driver Cuda packages? FFMPeg loads
libcuda.so.1
at runtime:If not, do an install of
nvidia-driver-cuda
and either reboot or load thenvidia-uvm
module.Do you have any logs/output for the
ffmpeg
command?Grrr,
I had the ‘free repository’ enabled but not the ‘nonfree’
After enabling the nonfree repository the faac packages
showed up.
Thanks,
Jerry
Hi,
I am getting dependency errors ie
ffmpeg-libs (x86_64 ) fedora 23 complains
about a missing libfaac.so.0.
I cannot find it anywhere ;(
It’s in the faac package. Did you enable RPMFusion?
Thank you! 🙂
There is a new update of MakeMKV available 🙂
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.
Version 2.8.5 was tagged an hour ago, will update to that as soon as the tarballs are available.
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?
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.
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:
https://fedoraproject.org/wiki/DNF_system_upgrade
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?
I’m running the same version here, and no issues. Try cleaning your preferences directory. (~/.MakeMKV)
Mmmm thanks. Last night I compiled it from “source” off MakeMKV’s website and all is good.
Thanks
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!
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.
Always what it’s bundled in Fedora; but as shown by your build, this does not make any difference.
According to the source code, VP9 has never been enabled: https://github.com/HandBrake/HandBrake/commits/master/contrib/libvpx
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.
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).
Should work now (see previous reply).
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
When “backing out” to 0.10.2-3 are you on Fedora 22 or 23?
HandBrake ships with a bundled libvpx 1.3.0. Fedora 22 has it in the repositories; Fedora 23 has version 1.4.0.
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.
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?
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.
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 :/
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
ah just figured it out. blender in your repos is only for f23, or at least not available for f22. i’ll update 🙂
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.
Has the Fedora 21 repository been deprecated? If so, why?
Will the Centos binary run on an F21 installation?
(thanks in advance)
No they will not. Fedora has been in EOL since 1st of december. You should upgrade.
https://fedoraproject.org/wiki/End_of_life
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.
Oh yeah, thanks for letting me know. I need to get rid of all the Fedora 21 entries in the pages. Thanks for notifying!
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.
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.
Just a FYI… the update didn’t help. Problem still exists.
HandBrake-cli-1.0-6.46e641c.fc23.x86_64
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.
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.
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 libavcodec.so 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/libpthread.so.0"
}
, { "address": 140711413853085
, "build_id": "5e86d81f6b21b75b08b19cd1574e14ec0ec098f3"
, "build_id_offset": 1059741
, "function_name": "__clone"
, "file_name": "/lib64/libc.so.6"
} ]
}
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.
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/libpthread.so.0
#5 0x00007fffeec49b9d in clone () at /lib64/libc.so.6
As a test, I built from the SPEC file you have here and it appears to work properly now.
http://negativo17.org/repos/HandBrake/SPECS/HandBrake.spec
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.
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 ‘http://negativo17.org/repos/HandBrake/fedora-23/x86_64/’: 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.
Complete!
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 ‘http://negativo17.org/repos/HandBrake/fedora-23/x86_64/’: 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.
There is no HandBrake for Fedora 23 at the moment, as it depends on Fedora 23 RPMFusion packages which are not yet released.
I notice in your instructions on this page you say to:
ln -sf /usr/lib64/libmmbd.so.o libaacs.so.0
…but there is no libmmbd.so.o on my system, only libmmbd.so.0 (replace the last letter “o” with the number “zero”).
Thanks.
Typo on my side, will fix it. Thanks.
Fixed, thanks.
Hi,
makemkv 1.9.5 is available.
http://www.makemkv.com/forum2/viewtopic.php?f=3&t=224
could you please build a new rpm package.
thanks
This has been done.