Big multimedia repository update (CUDA enablements, rebases, new software)

Merging of the Nvidia repository into Multimedia

The whole multimedia repository has been rebased with recent releases, and it now features FFmpeg 3.2 as the foundation. Most of the programs that suppport some Nvidia integration are now enabled and compiled with support for CUDA/NVENC/CUVID; leveraging the previous reorganization of CUDA 8 in the various subpackages.

This means that all the Nvidia packages are now included in the repository as well, so if you have an Nvidia card and you are interested in both repositories, you can just have the multimedia repository enabled. If you still just want the Nvidia stuff (as enabled in Fedora 25) then it’s still available as a separate repository; and that will not change.

Why all of this? Because I can’t keep them separated anymore. The Nvidia repository can exist on its own, but the multimedia one can’t, due to the dependencies and the constant rebases (also of main Fedora and CentOS/RHEL packages). You can use the Nvidia repository alone, if you just need that, or use the multimedia one if you need everything else.

The repository is now exposed also at this URL, and contains Delta RPM support:

http://negativo17.org/repos/multimedia

All repository files and configurations have been updated, so this means that in the future this would be the place where the metadata and repository information will be placed and any new installation will get the repository from there. If you are reading this blog post, you can switch now. I will add a negativo17-release package soon, along with a few mirrors; I’m sorting out the details now with the mirror owners.

FFmpeg and other CUDA enablements

To make proper use of the Nvidia hardware encode features (NVENC/CUVID) and CUDA kernel support (i.e. Blender GPU rendering) in the various programs you need the Nvidia driver installed (nvidia-driver-cuda), and for Nvidia Performance Primitives you require the CUDA driver and the NPP library package (cuda-npp).

This means that for most people NOT requiring CUDA support or not using an Nvidia video card, the following 2 packages will be installed anyway:

$ ls -alghs nvidia-driver-cuda-libs*.rpm cuda-npp*.rpm 
92M -rw-r--r-T. 1 mock 92M Nov 16 12:35 cuda-npp-8.0.44-6.fc25.x86_64.rpm
22M -rw-r--r-T. 1 mock 22M Nov 19 15:00 nvidia-driver-cuda-libs-375.20-1.fc25.x86_64.rpm

Both packages contain just libraries, and they will be on your system as much as other libraries for multimedia codecs you don’t actually need. Example, with most multimedia programs you will get Xvid libraries for opening Xvid files, even though the format is pretty much abandoned. Having them installed does not enable any unwanted feature in your system. Also, NPP libraries should decrease 50% in size in one of the next CUDA updates, being the monolithic version of the library being deprecated in favor of split functionality.

There are some patches being evaluated to make those libraries loadable at runtime, but they have not been merged yet and there’s no guarantee that they ever will. Also, they are available for FFmpeg but not for all the other programs where support has been enabled for; so depending on your installation, you might get them anyway.

As of today, from the Multimedia repository the following programs have been enabled with some Nvidia hardware enablement:

  • MPV (video decoding through CUVID)
  • FFmpeg (encoding through NVENC, decoding through CUVID and filtering through CUDA NPP)
  • Avidemux (encoding, through NVENC)
  • GStreamer (NVENC plugin)
  • Blender (GPU rendering)

VDPAU for decoding was already enabled where possible.
Of course anything that is using FFmpeg (like the GStreamer plugins) could theoretically benefit from the same enablements as in FFMpeg:

$ for i in encoders decoders filters; do
    echo $i:; ffmpeg -hide_banner -${i} | egrep -i "npp|cuvid|nvenc|cuda"
done
encoders:
 V..... h264_nvenc           NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc                NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc_h264           NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc_hevc           NVIDIA NVENC hevc encoder (codec hevc)
 V..... hevc_nvenc           NVIDIA NVENC hevc encoder (codec hevc)
decoders:
 V..... h263_cuvid           Nvidia CUVID H263 decoder (codec h263)
 V..... h264_cuvid           Nvidia CUVID H264 decoder (codec h264)
 V..... hevc_cuvid           Nvidia CUVID HEVC decoder (codec hevc)
 V..... mjpeg_cuvid          Nvidia CUVID MJPEG decoder (codec mjpeg)
 V..... mpeg1_cuvid          Nvidia CUVID MPEG1VIDEO decoder (codec mpeg1video)
 V..... mpeg2_cuvid          Nvidia CUVID MPEG2VIDEO decoder (codec mpeg2video)
 V..... mpeg4_cuvid          Nvidia CUVID MPEG4 decoder (codec mpeg4)
 V..... vc1_cuvid            Nvidia CUVID VC1 decoder (codec vc1)
 V..... vp8_cuvid            Nvidia CUVID VP8 decoder (codec vp8)
 V..... vp9_cuvid            Nvidia CUVID VP9 decoder (codec vp9)
filters:
 ... hwupload_cuda     V->V       Upload a system memory frame to a CUDA device.
 ... scale_npp         V->V       NVIDIA Performance Primitives video scaling and format conversion

I think this will be much appreciated for you users out there that are already using CUDA for deep learning and FFMpeg to process data πŸ™‚

Rebases: FFmpeg, HandBrake, VLC, OpenH264, WebP (CentOS/RHEL), MPV.

A note on Blender: Blender with CUDA support is still at 2.78 built with CUDA 7.5, and not 2.78a built with CUDA 8; so no Nvidia Pascal GPU support. I’m working on it.

GNOME Software integration

Most of the graphical software is now enabled in GNOME software for Fedora 25, meaning that you can search stuff with a keyword and that if you have the repository enabled it will just pop-up:

gnome-software-handbrake

gnome-software-makemkv

gnome-software-vlc

There is still some packages that need AppStream metadata, but that will come.

As usual, feedback, bugs and comments are welcome.

63 thoughts on “Big multimedia repository update (CUDA enablements, rebases, new software)

  1. Any chance of leaving the older package versions in the repositories to allow the chance of “downgrading” back to a previous version if there are issues?
    I’m currently having issues with the most up-to-date VLC where I always get a second player window and I didn’t change any settings from the previous version (which worked OK for me on Scientific Linux 7).

  2. Hi,

    First of all, thanks for your work in packaging and hosting the repos, it’s very much appreciated. I’d like to ask about the cuda support and ffmpeg and mpv, I’m trying to use mpv with –hwdec=cuda for HEVC support and it doesn’t work. This is on Fedora 25 with KDE and NVIDIA GTX950m Optimus.

    Trying cuda samples and deviceQuery works and Blender for example works also. But mpv doesn’t. See the mpv log here: https://paste.fedoraproject.org/557645/03268514/ – I just get [vd] Requested hardware decoder not compiled.

    Also NVIDIA 378.13 was just released: https://devtalk.nvidia.com/default/topic/994029/linux/-nvidia-378-13-release-a-new-stable-branch-/ and it seems to have fixed the suspend bug. Can you please update?

    1. Hello, as part of the MPV 0.23.0 update, they removed support for linked CUDA libraries and have adopted the dynamic loading mechanism… that is in FFMpeg git master. So with 3.2.4 it does not work anymore. I completelyt missed that when updating.

      I’m quite reluctant to update to an unreleased FFMpeg just because of MPV. It seems the most feasible thing to do is revert back to mpv 0.22.0 until FFmpeg 3.4.0 is released. Ideas?

      Regarding the driver, sure, I’m about to update to both 375.39 for RHEL/CentOS and 378.13 for Fedora.

      1. Hi again Simone,

        I’d say thats really unfortunate. If you really want to you could revert mpv I guess but I don’t think it’s really feasible or worth your time. Guess I’ll wait until ffmpeg 3.4 is released.

        I was curious to test hevc with this laptop, but it’s not really worth your time reverting this for that.

        Thanks again for your time on this.

    1. Hello, as part of the MPV 0.23.0 update, they removed support for linked CUDA libraries and have adopted the dynamic loading mechanism… that is in FFMpeg git master. So with 3.2.4 it does not work anymore. I completelyt missed that when updating.

      I’m quite reluctant to update to an unreleased FFMpeg just because of MPV. It seems the most feasible thing to do is revert back to mpv 0.22.0 until FFmpeg 3.4.0 is released. Ideas?

  3. On a quick examination it looks like you need

    %{_libdir}/ADM_plugins6/videoEncoders/qt5

    AND

    %{_libdir}/ADM_plugins6/videoFilters/qt5

    in the spec file.

  4. On Scientific Linux 7 (RHEL7) I don’t seem to be able to use the NVIDIA x264 codecs and the Mpeg AVC h264 codecs.
    Should I be able to use both/either, is there a dependency that I’m missing?
    If I uninstall and install avidemux from the nux-dextop repository I can use the 264 AVC codecs but it is an older version of avidemux.

    1. Sorry, mixing with nux-desktop is not supported. Can you be more specific to what your problem is?
      H2764 decoding with Nvidia is through VDPAU (so just installing the Nvidia driver should be fine), software AVC H264 decoding is through FFMpeg (this might come along with other dependencies in your program choice).

      For Avidemux, do you mean you can not encode videos with any H264 encoder? If that’s the case I will check it out.

      1. Sorry for not being clear.
        I can encode with the NVIDIA codec however the codec encoding options seem limited.
        I was hoping to also have the AVC h264 codec also available to choose but it is not available.

        It is OK, I have been able to compile from source.

        Thanks for getting back to me.

        1. Can you give back the information that allowed you to succesfully enable the encoder? So then I can maybe apply the same to the RPM.

          1. I suspect that the following folder and files (when compiled for qt4) are not being installed

            /usr/lib64/ADM_plugins6/videoEncoders/qt4

            libADM_ve_x264_QT4.so libADM_ve_x265_QT4.so

            I assume a similar qt5 folder and files would also be required.

          2. I have now compiled for qt5 (from source tarball) and can confirm that there is a qt5 folder with files below created (which are not installed from the rpm package)

            libADM_ve_x264_QT5.so libADM_ve_x265_QT5.so

          3. Would you mind sharing your compilation options? They are not built at the moment with the current SPEC file.

          4. This was driving me crazy, the files were not under BUILD.
            The “build” command was missing from the buildPluginsQt4 section.
            I’ve also updated the files section. Please change as you prefer.

            Release: 2%{?dist}
            186a187
            > build
            285a287,304
            > %{_libdir}/ADM_plugins6/videoEncoders/qt5/
            > %{_libdir}/ADM_plugins6/videoEncoders/qt5/libADM_ve_x264_QT5.so
            > %{_libdir}/ADM_plugins6/videoEncoders/qt5/libADM_ve_x265_QT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_asharpQT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_chromaShiftQT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_contrastQT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_cropQT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_eq2QT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_glBenchmark.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_glResize.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_HueQT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_logoQT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_mpdelogoQT5.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_rotateGlFrag2.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_sampleGlFrag2.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_sampleGlVertex.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_shaderLoaderGl.so
            > %{_libdir}/ADM_plugins6/videoFilters/qt5/libADM_vf_swscaleResizeQT5.so
            298a318,321
            > * Tue Feb 14 2017 George Seaton – 2.6.18-2
            > – build for QT fixed
            > – Update to 2.6.18-2.
            >

  5. Because I need to use the builtin video card on our server for X and the GPUs purely for computing, I find that I need to use the .run installers for Nvidia along with the flag –no-opengl-files when installing for everything to work correctly. I’d REALLY prefer to use a repo for my files. Is there any way that I could use this repo when this flag is needed?

    1. Could you tell me which component does exactly the driver with the --no-opengl-files switch provide? Everything but the GL libraries and X driver?

      1. I don’t know the specifics. Here’s the info for the flag from the run installer:

        –no-opengl-libs
        Prevents the driver installation from installing NVIDIA’s GL libraries.
        Useful for systems where the display is driven by a non-NVIDIA GPU.
        In such systems, NVIDIA’s GL libraries could prevent X from loading
        properly.

  6. Hello,

    I think I may have found a dependency bug. Whenever I am using GStreamer plugins from the Multimedia repository, any package that depends on “gstreamer1-plugins-bad-free-gtk“, such as “corebird“, cannot be installed at the same time.

    “dnf“ reports:
    “Error: package corebird-1.3.3-1.fc25.x86_64 requires gstreamer1-plugins-bad-free-gtk(x86-64), but none of the providers can be installed“

    “dnf“ with “–allowerasing“ asks to remove any “gstreamer1-plugins-bad“ plugins from “@fedora-multimedia“.

  7. Hello Simone,
    I am the current maintainer of Blender in Fedora repository. As you are aware, ffmpeg support had to be disabled due to the policy. Is there a way to set a condition for blenderplayer to detect support ffmpeg when available? Suggestion welcome. Thanks.

  8. For your next update in regards to cuda-samples, several source files requires updating the path for cuda related header files.

    diff -r samples.orig/common/inc/nvrtc_helper.h samples/common/inc/nvrtc_helper.h
    5,6c5,6
    < #include
    < #include

    > #include
    > #include

    diff -r samples.orig/4_Finance/BlackScholes_nvrtc/BlackScholes.cpp samples/4_Finance/BlackScholes_nvrtc/BlackScholes.cpp
    18c18
    < #include

    > #include

    diff -r samples.orig/4_Finance/binomialOptions_nvrtc/binomialOptions.cpp samples/4_Finance/binomialOptions_nvrtc/binomialOptions.cpp
    24,25c24,25
    < #include
    < #include

    > #include
    > #include

    diff -r samples.orig/4_Finance/binomialOptions_nvrtc/binomialOptions_gpu.cpp samples/4_Finance/binomialOptions_nvrtc/binomialOptions_gpu.cpp
    22c22
    < #include

    > #include

    diff -r samples.orig/4_Finance/quasirandomGenerator_nvrtc/quasirandomGenerator.cpp samples/4_Finance/quasirandomGenerator_nvrtc/quasirandomGenerator.cpp
    13,14c13,14
    < #include
    < #include

    > #include
    > #include

    This is not a complete list.

    Regards, Mario.

      1. Thank you. I was hoping to be able to run make at the top level cuda-samples dir.

        cd /usr/share/cuda/samples
        make <– nvlink error : undefined reference to 'cudaGetParameterBuffferV2' and 'cudaLaunchDeviceV2' in 'cdpSimplePrint.o'

        Not able to run make from the top-level directory led me to run make from inside samples individually. Most work fine, but some not.

        cd /usr/share/samples/4_Finance/binomialOptions_nvrtc
        make <– fatal error: cuda_runtime.h No such file or directory

        It requires manually adding -I/usr/include/cuda to Makefile. Setting the environment variable CCFLAGS=-I/usr/share/cuda does not work when the Makefile sets the variable with blank ( := versus += ).

        In summary, I was hoping to run make from the top-level directory ( cuda-samples package ) and not have to fiddle with Makefiles. From my memory, this worked years ago when installing CUDA from nvidia.com.

        Regards, Mario.

        1. It requires manually adding -I/usr/include/cuda to Makefile. Setting the environment variable CCFLAGS=-I/usr/share/cuda does not work when the Makefile sets the variable with blank ( := versus += ).

          Argh, correct. Will fix it, so I guess the patching (either for CFLAGS or #include) is necessary.
          Sorry but I don’t usually build the samples and no one reported.

  9. Hi,

    I have a fresh install of Fedora 25 with RPMFusion repos configured. I added your multimedia repo in order to install HandBrake-gui but I’m having a conflict with an x265 library:

    dnf install HandBrake-gui
    Error: package HandBrake-gui-1.0.2-1.20170102git063446f.fc25.x86_64 requires libx265.so.102()(64bit), but none of the providers can be installed
    (try to add ‘–allowerasing’ to command line to replace conflicting packages)

    This is what I have:
    rpm -qa | grep -i x265
    x265-libs-1.9-3.fc25.x86_64

    …which has:
    rpm -ql x265-libs | grep libx265.so
    /usr/lib64/libx265.so.79

    If I do “dnf remove x265-libs” almost everything I’ve installed from RPMFusion is going to be removed…

    Can your multimedia repo coexist with RPMFusion? If so, please let me know here so I can open an issue in you github page.

    Thanks,
    Jorge

    1. Sorry but the repositories have diverged too much in terms of versioning. You can’t use them together. I will make it clear in the pages.

      1. On Fedora 25 I am having an issue with dependencies updating the nvidia-driver.
        The cuda drivers will update but dnf complains of broken dependencies and skips updating nvidia-driver and nvidia-driver-libs. 375.26-4.fc25.

        These are the packages I have installed:

        nvidia-persistenced-375.26-1.fc25.x86_64
        nvidia-driver-NVML-375.26-1.fc25.x86_64
        nvidia-driver-375.26-1.fc25.x86_64
        nvidia-driver-cuda-375.26-1.fc25.x86_64
        nvidia-settings-375.26-1.fc25.x86_64
        nvidia-driver-libs-375.26-1.fc25.x86_64
        nvidia-driver-cuda-libs-375.26-1.fc25.x86_64
        nvidia-libXNVCtrl-375.26-1.fc25.x86_64
        dkms-nvidia-375.26-1.fc25.x86_64

          1. Thank you

            I discovered the problem.
            I have xorg-x11-server-Xorg- 1.18.4-5.fc24 installed because my graphics tablet did not work with 1.19 evdev,
            nvidia-driver requires >= 1.19.0-3.
            I guess I’ll have to wait and see if xorg evdev drivers get fixed.

  10. Any way to add the libraries in /usr/lib/nvidia to /etc/ld.so.conf.d/ as some apps and ldd do not find those. Had to manually create the two just to get the tvheadend and a couple other apps to start as they all were failing to locate the libraries.

    1. You’ve already opened an issue on that, no need to double post.

      The drivers do not ship any library in /usr/lib/nvidia or /usr/lib64/nvidia, just the OpenCL override in the CUDA libraries subpackage. And for that, there’s the necessary ldconfig configuration file.

      $ rpm -ql nvidia-driver-libs.x86_64
      /usr/lib64/libEGL_nvidia.so.0
      /usr/lib64/libEGL_nvidia.so.375.26
      /usr/lib64/libGLESv1_CM_nvidia.so.1
      /usr/lib64/libGLESv1_CM_nvidia.so.375.26
      /usr/lib64/libGLESv2_nvidia.so.2
      /usr/lib64/libGLESv2_nvidia.so.375.26
      /usr/lib64/libGLX_indirect.so.0
      /usr/lib64/libGLX_nvidia.so.0
      /usr/lib64/libGLX_nvidia.so.375.26
      /usr/lib64/libnvidia-cfg.so.1
      /usr/lib64/libnvidia-cfg.so.375.26
      /usr/lib64/libnvidia-egl-wayland.so.375.26
      /usr/lib64/libnvidia-eglcore.so.375.26
      /usr/lib64/libnvidia-glcore.so.375.26
      /usr/lib64/libnvidia-glsi.so.375.26
      /usr/lib64/libnvidia-tls.so.375.26
      /usr/lib64/vdpau/libvdpau_nvidia.so.1
      /usr/lib64/vdpau/libvdpau_nvidia.so.375.26
      /usr/share/glvnd/egl_vendor.d/10_nvidia.json

      $ rpm -ql nvidia-driver-cuda-libs.x86_64
      /etc/ld.so.conf.d/nvidia-lib64.conf
      /usr/lib64/libcuda.so
      /usr/lib64/libcuda.so.1
      /usr/lib64/libcuda.so.375.26
      /usr/lib64/libnvcuvid.so.1
      /usr/lib64/libnvcuvid.so.375.26
      /usr/lib64/libnvidia-compiler.so.375.26
      /usr/lib64/libnvidia-encode.so.1
      /usr/lib64/libnvidia-encode.so.375.26
      /usr/lib64/libnvidia-fatbinaryloader.so.375.26
      /usr/lib64/libnvidia-opencl.so.1
      /usr/lib64/libnvidia-opencl.so.375.26
      /usr/lib64/libnvidia-ptxjitcompiler.so.375.26
      /usr/lib64/nvidia
      /usr/lib64/nvidia/libOpenCL.so.1
      /usr/lib64/nvidia/libOpenCL.so.1.0.0

      What are you referring to?

  11. I appears the repo is missing the x86_64 versions of libmfx. This is causing dependency failures with for us. Do you think you can add them?

      1. I see that now…we were not pulling in all of EPEL, so when we resolved dependencies with your repo enabled we got a conflict because your repo only has the i686 version. It looks like EPEL is only providing the x86_64 package. Is that why you chose to publish the i686 package? It seems a bit disjointed to have the same package published in two places with different arch’es. Could you include the x86_64 package as well?

        1. So, the RHEL/CentOS installs provide a lot of i386 for which build dependencies are not satisfied; I would need to put another 32 bit clone from CentOS in the repository. I’m trying to avoid useless duplication between the repositories. So basically anything that can come from base channels or EPEL is there, anything else (extra stuff + 32 bit builds are in the multimedia repository).

          I might change it, but at the moment i’m trying to keep differences to the minimum. I also have a full i386 repository available, but that’s private as I don’t see its use.

  12. New CentOS kernel update broke my system using an NVIDIA card (fortunately, this time, I can still use older kernels). Can this be looked into?

    As usual, thanks for your hard work.

  13. Thanks for adding avidemux to the mix, which overcomes the library-versioning conflict with rpmfusion on Fedora 24. Because the package naming is slightly different, I had to manually remove the rpmfusion avidemux-qt (which has no corresponding negativo package), then I was able to install avidemux-gui from your repo and upgrade the rest of the multimedia set.

    I’m especially impressed that you managed to get a qt5 build working; when we tried @ rpmfusion that failed miserably and it had to be reverted to qt4. (But that was with 2.6.12, not the 2.6.15 you’re distributing.)

    There are unfortunately a few weirdnesses with the avidemux-gui as distribted, though.

    * The keyboard controls don’t seem to function during playback. (Perhaps that’s an avidemux change and not a build issue, but if so it’s a weird regression… being able to seek through the video while it was playing, or drop A/B markers without having to pause, was a useful feature.) …Actually, now that I try it the GUI seeking/marker controls don’t function during playback either, so maybe that is an application change. Or maybe it’s a qt5 issue?

    * The available Filter set is a bit odd. The subtitle-hardcoding plugin is present in the Subtitles section, which is nice because tha’s been long missing from rpmfusion’s builds. But the tradeoff is, the Transform section appears to lack ANY filters for video scaling or cropping, so there’s no way to change the size or dimensions of the reencoded video using filters.

    If I get more conrete info and/or fixes on any of these, I’ll open real Issues in github, but for the moment I just wanted to mention them, but more importantly say thanks!

    1. > I had to manually remove the rpmfusion avidemux-qt (which has no corresponding negativo package), then I was able to install avidemux-gui from your repo and upgrade the rest of the multimedia set.

      Will add an Obsoletes/Provides.

      > But that was with 2.6.12, not the 2.6.15

      Yeah, that’s completely different.

      > If I get more conrete info and/or fixes on any of these, I’ll open real Issues in github

      Yes please do that if you find the fixes. In the meantime I will look if it’s a build problem.

        1. Aha, I may have figured out where that issue came from, though the dnf output is… odd (going the other way, at least; it didn’t feel like it highlighted this properly on the upgrade side).

          When downgrading back from negativo to rpmfusion avidemux (still chasing the keyboard controls issue, now that I see they’ve also updated to 2.6.15), I got this:


          Error: Transaction check error:
          file /usr/lib64/libADM_openGLQT56.so from install of avidemux-libs-2.6.15-1.fc24.x86_64 conflicts with file from package avidemux-gui-2.6.15-2.fc24.x86_64
          file /usr/lib64/libADM_openGLQT56.so from install of avidemux-qt-2.6.15-1.fc24.x86_64 conflicts with file from package avidemux-gui-2.6.15-2.fc24.x86_64

          The avidemux packaging is a little sloppier with the division between gui and non-gui components, so some of the gui libraries are (also) in avidemux-libs… which means (if I’m following this right) that avidemux-gui needs to Obsolete that, as well… but probably not also Provide it? Maybe.

  14. Thanks for your work with this. I am having trouble running MPV now as it seems to expect an older version of ffmpeg and may need rebuilding. See the error output below. (Running Fedora 24)

    ffmpeg library versions:
    libavutil 55.34.100
    libavcodec 57.64.100 (runtime 57.64.101)
    libavformat 57.56.100
    libswscale 4.2.100
    libavfilter 6.65.100
    libswresample 2.3.100
    ffmpeg version: 3.2.1

    mpv was compiled against a different version of FFmpeg/Libav than the shared
    library it is linked against. This is most likely a broken build and could
    result in misbehavior and crashes.

    mpv does not support this configuration and will not run – rebuild mpv instead.

    Exiting… (Fatal error)

    1. Funny, I didn’t know that MPV would complain in such a situation, because it links the shared libraries with only the major version as any other program. In fact all libraries are correctly found:

      $ ldd /usr/bin/mpv | grep libav
              libavutil.so.55 => /lib64/libavutil.so.55 (0x00007f65a8525000)
              libavcodec.so.57 => /lib64/libavcodec.so.57 (0x00007f65a7144000)
              libavformat.so.57 => /lib64/libavformat.so.57 (0x00007f65a6d4e000)
              libavfilter.so.6 => /lib64/libavfilter.so.6 (0x00007f65a3ee5000)
              libavdevice.so.57 => /lib64/libavdevice.so.57 (0x00007f65a1367000)
              libavresample.so.3 => /lib64/libavresample.so.3 (0x00007f659718d000)

      Will trigger a rebuild immediately. Thanks for reporting.

      1. That “special” behavior needs to be patched out, because it’s not really as necessary as mpv makes it out to be…

        1. I was rather surprised to discover that behavior had only been added recently. (July 1, apparently without any fanfare or deeper explanation that I could find.)

          I’d guessed that it was a relic from the olden days of ffmpeg’s endlessly moving-target API, as it’s the sort of measure that would have made some real sense around 2011-2012, when pinning down ffmpeg support could be maddening. But I agree, it seems far less necessary these days. I wonder why they decided to toss it in there so late in the game?

  15. I have this error when launch mpv (Fedora 24), after dnf update:

    $ mpv
    ffmpeg library versions:
    libavutil 55.34.100
    libavcodec 57.64.100 (runtime 57.64.101)
    libavformat 57.56.100
    libswscale 4.2.100
    libavfilter 6.65.100
    libswresample 2.3.100
    ffmpeg version: 3.2.1

    mpv was compiled against a different version of FFmpeg/Libav than the shared
    library it is linked against. This is most likely a broken build and could
    result in misbehavior and crashes.

    mpv does not support this configuration and will not run – rebuild mpv instead.

    Exiting… (Fatal error)

    1. Funny, I didn’t know that MPV would complain in such a situation, because it links the shared libraries with only the major version as any other program. In fact all libraries are correctly found:

      $ ldd /usr/bin/mpv | grep libav
              libavutil.so.55 => /lib64/libavutil.so.55 (0x00007f65a8525000)
              libavcodec.so.57 => /lib64/libavcodec.so.57 (0x00007f65a7144000)
              libavformat.so.57 => /lib64/libavformat.so.57 (0x00007f65a6d4e000)
              libavfilter.so.6 => /lib64/libavfilter.so.6 (0x00007f65a3ee5000)
              libavdevice.so.57 => /lib64/libavdevice.so.57 (0x00007f65a1367000)
              libavresample.so.3 => /lib64/libavresample.so.3 (0x00007f659718d000)

      Will trigger a rebuild immediately. Thanks for reporting.

  16. Not sure if this is relevant, but my dkms-nvidia install failed because I didn’t have the directory “/lib/modules/`uname -r`/extra” Once I created that and ran “dkms install nvidia -v 375.20” my X/gdm session would start correctly. (this occurred after a dnf system-upgrade from 24 to 25)

    1. The extra folder is part of the kernel-modules-extra, that’s historical part of the original kernel package.

      $ rpm -qf /lib/modules/`uname -r`/extra
      kernel-modules-extra-4.8.8-200.fc24.x86_64

      I should probably move them somewhere else. Can you please file a bug here so I can keep track of it? https://github.com/negativo17/dkms-nvidia

      Thanks.

    2. The directory is created at install time, even if it does not exist (i.e. if the kernel-modules-extra are not installed). If you run DKMS in debug mode you can clearly see it:

      + echo ' - Installing to /lib/modules/4.8.10-200.fc24.x86_64/extra/'
      - Installing to /lib/modules/4.8.10-200.fc24.x86_64/extra/
      + mkdir -p /lib/modules/4.8.10-200.fc24.x86_64/extra

      1. Sorry, got distracted by work (stupid work getting in the way of the good stuff).

        The latest 4.8.10 kernel I just upgraded to got the right extra directory created, so I’d say this was fixed.

  17. Your repositories are excellent work. Thanks!

    But, isn’t this change going to create a conflict for those having the proprietary NVIDIA driver (which includes libraries) manually installed?

  18. I’m having issues with mpv since the ffmpeg upgrade. Has anyone else encountered this? I tried rebuilding to mpv 0.22.0 – but same issue. Error message is:
    *** Error in `/usr/bin/mpv’: free(): invalid pointer: 0x00007f11304b1f58 ***

    1. I found the problem… in smplayer I had the Video output driver set to default. Prior to the latest changes that worked fine… I’m not sure what default represents now, but I changed it to “user defined” XV and all is working again. Perhaps something also with F25 – I know the default for GNOME is now wayland, but in KDE (which I use, I believe it is still X).

Leave a Reply