Package Details: ffmpeg-full-nvenc 1:4.2.2-1

Git Clone URL: (read-only, click to copy)
Package Base: ffmpeg-full-nvenc
Description: Record, convert, and stream audio and video (all codecs including Nvidia NVENC)
Upstream URL:
Keywords: ffmpeg
Licenses: custom: nonfree and unredistributable
Conflicts: ffmpeg
Provides: ffmpeg,,,,,,,,
Submitter: dark-saber
Maintainer: dark-saber
Last Packager: dark-saber
Votes: 29
Popularity: 0.022226
First Submitted: 2015-08-04 08:01
Last Updated: 2020-01-10 14:35

Dependencies (97)

Required by (985)

Sources (3)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Martchus commented on 2020-02-05 07:47

Also the official/regular ffmpeg package now has nvenc support so there's likely no point having this package anymore.

FabioLolix commented on 2020-02-04 21:20

Hi, what is the difference with 'ffmpeg-full' which also have ffnvcodec-headers in makedepends?

N3oTraX commented on 2019-12-12 19:29


yay -S -d x265

Worked as a charm for me ;)

Gatenkaas commented on 2019-11-08 17:41

Fails with x265 (3.2.1-1), dependency '' Obviously there is no automatic code update when a so-name bump occurs. The solution therefore is to force the installation of 'x265' with 'yay -S -d x265' and then rebuild with 'yay -S ffmpeg-full-nvenc'.

dark-saber commented on 2019-08-02 10:36


Fixed, thanks!

chowbok commented on 2019-07-27 19:08

I had to install vmaf manually to get this to build; maybe that should be listed as a dependency?

Martchus commented on 2019-03-06 09:50

Why would that be the right thing to do?

Like I said, some people are actually using the testing repos.

But not bumping the pkgrel at all is an option, too. When this is the case I usually increase the pkgrel myself to e.g. 1.1 so I would still get an update if the pkgrel changes because a patch has been added or something else in the package has been changed.

If I'm fast enough I sometimes even build against staging and move the package later from my own staging to my own testing or regular repository. For this increasing the pkgrel in the AUR is not really helpful anyways. So that kind of sophisticated way to build packages also speaks for just letting the users manage this on their own.

spider-mario commented on 2019-03-06 07:45

Why would that be the right thing to do? And for an AUR package, wouldn’t it make more sense to just let users rebuild the package when needed?

Martchus commented on 2019-03-05 12:13

I think it is o.k. to update it now - some people are actually using the testing repos. Other users can simply postpone the rebuild or build the package using makechrootpkg against the testing version and install that package later. Using makechrootpkg instead of makepkg is the right thing to do anyways - especially for this package.

spider-mario commented on 2019-03-05 07:47

Isn’t that cuda rebuild a bit early? The new cuda version is still in [community-testing].