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.

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

  1. 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.

  2. 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?

  3. 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.

  4. 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.

  5. 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?

  6. 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