Package Details: ffmpeg-full 7.1-1

Git Clone URL: https://aur.archlinux.org/ffmpeg-full.git (read-only, click to copy)
Package Base: ffmpeg-full
Description: Complete solution to record, convert and stream audio and video (all possible features including libfdk-aac)
Upstream URL: https://www.ffmpeg.org/
Keywords: audio codec convert cuda cuvid decklink encoder fdk-aac fdkaac hwaccel libnpp media nvenc svt video
Licenses: LicenseRef-nonfree-and-unredistributable
Conflicts: ffmpeg
Provides: ffmpeg, libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so
Submitter: rpolzer
Maintainer: dbermond
Last Packager: dbermond
Votes: 136
Popularity: 1.41
First Submitted: 2013-01-24 11:17 (UTC)
Last Updated: 2024-11-07 22:45 (UTC)

Required by (1915)

Sources (10)

Pinned Comments

dbermond commented on 2024-06-24 15:59 (UTC)

@LordSIGSEGV avoid creating files not tracked by pacman in the system reserved directories, specially symlinks to shared libraries, as this have the potential to completely break your system. I have already notified the quirc maintainer in the aur web page of the package in April-2024. While this issue is not solved in quirc, I recommend to use quirc-git, which currently has a better packaging and does not suffer from this problem.

Latest Comments

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 24 25 26 27 .. 55 Next › Last »

dbermond commented on 2019-04-03 00:41 (UTC)

@clpwn There are some ways to do this. For example, temporarily uninstall x264 with 'pacman -Rdd' to ignore the dependencies check. Then install it back again with 'pacman -Syu --asdeps x264' and then rebuild ffmpeg-full against the new x264.

clpwn commented on 2019-04-01 02:50 (UTC)

There's a dependency conflict with the new x264 version released.

error: failed to prepare transaction (could not satisfy dependencies)
:: installing x264 (2:157.r72db4377-1) breaks dependency 'libx264.so=155-64' required by ffmpeg-full

dbermond commented on 2019-03-13 20:55 (UTC)

@BrLi This is not possible with ffmpeg because when you enable a component at build time it will be always needed when running the final binary, otherwise you will get a 'cannot load shared library' error.

brli commented on 2019-03-11 14:26 (UTC)

Can any part of the dependencies be optional? I mean, I'd like to have a full ffmpeg but works like the official package with additional functions when I install corresponding libs/packages.

Martchus commented on 2019-03-06 09:50 (UTC) (edited on 2019-03-06 09:50 (UTC) by Martchus)

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 (UTC)

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 (UTC)

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 (UTC)

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

petko10 commented on 2019-02-25 15:19 (UTC)

I added the lines ''export LD_LIBRARY_PATH=/opt/cuda/lib64 export PATH=$PATH:/opt/cuda/bin'' to the PKGBUILD install section and that also works

Stefanitsky commented on 2019-02-09 08:21 (UTC) (edited on 2019-02-11 07:17 (UTC) by Stefanitsky)

Alltime headache = building this package

What problems did i had:

1) AUR packages missing
Solution: manual installation of each package

2) "One or more PGP signatures could not be verified! (unknown public key B4322F04D67658D8)"
Solution: $ gpg --recv-keys B4322F04D67658D8

3) nvcc: command not found
Solution: add /opt/cuda to your PATH variable in your .bashrc or whatever your shell is.
export LD_LIBRARY_PATH=/opt/cuda/lib64
export PATH=$PATH:/opt/cuda/bin

And also restart (reopen) your terminal to apply changes.

I hope this will help someone!

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 24 25 26 27 .. 55 Next › Last »