Hi,
yay -S -d x265
Worked as a charm for me ;)
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: | 137 |
Popularity: | 1.06 |
First Submitted: | 2013-01-24 11:17 (UTC) |
Last Updated: | 2025-07-28 20:24 (UTC) |
« First ‹ Previous 1 .. 16 17 18 19 20 21 22 23 24 25 26 .. 57 Next › Last »
Hi,
yay -S -d x265
Worked as a charm for me ;)
Same as Verequies here with vmaf 1.3.15:
-> Running ffmpeg configure script...
ERROR: libvmaf >= 1.3.9 not found using pkg-config.
Confirming it compiles successfully without --enable-libvmaf
.
@FraYoshi You need to rebuild ffmpeg-full every time that one of its dependencies get a soname bump. In this case, dav1d got a soname bump when upgrading it from 0.4.0 to 0.5.0.
ffmpeg-full
breaks chromium
(/usr/lib/chromium/chromium: error while loading shared libraries: libdav1d.so.2: cannot open shared object file: No such file or directory
)
and NetFlix (Error Code: F7355
)
for me...
Solved replacing with ffmpeg
standard
Fails with x265 (3.2.1-1), dependency 'libx265.so=176-64' 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'.
@ganthore
1) hm is not a dependency for ffmpeg-full, so it's not needed here. vmaf and blackmagic-decklink-sdk are already in makedepends.
pocketsphinx currently builds fine for me. If you have any concerns about pocketsphinx please direct it to its package maintainer.
2) nvcc path is not missing, this was already answered. Please see the 2 comments from 2019-06-11. In short: nvcc path is handled by makepkg because it automatically sources the profile file when pulling and installing cuda.
ffmpeg-full is building fine in a chroot with devtools so it builds fine in a fresh Arch install.
There are two problems that need to be corrected with the PKGBUILD.
1) Missing or broken deps
On a fresh install of arch, the PKGBUILD building phase will fail due to the following packages not being set as dependencies:
hm (required for kvazaar to build) vmaf blackmagic-decklink-sdk
Also note that the pocketsphinx PKGBUILD is broken, so it may be better to use the pocketsphinx-git package as a workaround.
2) nvcc is missing
The build process will fail because you're assuming people have /opt/cuda/bin in their system or root shell path. An easy workaround is to export this into the PATH during the build phase: "export PATH=$PATH:/opt/cuda/bin"
strange, I had intel-svt-hevc installed at 1.4.0-1. Still, after rebuilding and installing it, I was able to build ffmpeg.
@craeckie Package is building fine. Please make sure that you have an updated intel-svt-hevc (currently at 1.4.0-1).
I'm getting this error when building:
CC libavcodec/libtheoraenc.o
libavcodec/libsvt_hevc.c: In function ‘config_enc_params’:
libavcodec/libsvt_hevc.c:140:14: error: ‘EB_H265_ENC_CONFIGURATION’ {aka ‘struct EB_H265_ENC_CONFIGURATION’} has no member named ‘encoderColorFormat’
140 | param->encoderColorFormat = EB_YUV420;
| ^~
libavcodec/libsvt_hevc.c:140:37: error: ‘EB_YUV420’ undeclared (first use in this function)
140 | param->encoderColorFormat = EB_YUV420;
| ^~~~~~~~~
libavcodec/libsvt_hevc.c:140:37: note: each undeclared identifier is reported only once for each function it appears in
libavcodec/libsvt_hevc.c:143:14: error: ‘EB_H265_ENC_CONFIGURATION’ {aka ‘struct EB_H265_ENC_CONFIGURATION’} has no member named ‘encoderColorFormat’
143 | param->encoderColorFormat = EB_YUV422;
| ^~
libavcodec/libsvt_hevc.c:143:37: error: ‘EB_YUV422’ undeclared (first use in this function)
143 | param->encoderColorFormat = EB_YUV422;
| ^~~~~~~~~
libavcodec/libsvt_hevc.c:145:14: error: ‘EB_H265_ENC_CONFIGURATION’ {aka ‘struct EB_H265_ENC_CONFIGURATION’} has no member named ‘encoderColorFormat’
145 | param->encoderColorFormat = EB_YUV444;
| ^~
libavcodec/libsvt_hevc.c:145:37: error: ‘EB_YUV444’ undeclared (first use in this function)
145 | param->encoderColorFormat = EB_YUV444;
| ^~~~~~~~~
libavcodec/libsvt_hevc.c:154:15: error: ‘EB_H265_ENC_CONFIGURATION’ {aka ‘struct EB_H265_ENC_CONFIGURATION’} has no member named ‘encoderColorFormat’
154 | if ((param->encoderColorFormat >= EB_YUV422) &&
| ^~
libavcodec/libsvt_hevc.c: In function ‘read_in_data’:
libavcodec/libsvt_hevc.c:232:15: error: ‘EB_H265_ENC_CONFIGURATION’ {aka ‘struct EB_H265_ENC_CONFIGURATION’} has no member named ‘encoderColorFormat’
232 | if (config->encoderColorFormat == EB_YUV420)
| ^~
libavcodec/libsvt_hevc.c:232:39: error: ‘EB_YUV420’ undeclared (first use in this function)
232 | if (config->encoderColorFormat == EB_YUV420)
| ^~~~~~~~~
libavcodec/libsvt_hevc.c:234:20: error: ‘EB_H265_ENC_CONFIGURATION’ {aka ‘struct EB_H265_ENC_CONFIGURATION’} has no member named ‘encoderColorFormat’
234 | else if (config->encoderColorFormat == EB_YUV422)
| ^~
libavcodec/libsvt_hevc.c:234:44: error: ‘EB_YUV422’ undeclared (first use in this function)
234 | else if (config->encoderColorFormat == EB_YUV422)
| ^~~~~~~~~
make: *** [ffbuild/common.mak:59: libavcodec/libsvt_hevc.o] Error 1
make: *** Waiting for unfinished jobs....
==> ERROR: A failure occurred in build().
Aborting...
Finished with result: exit-code
Main processes terminated with: code=exited/status=4
Service runtime: 6min 47.295s
Maybe a version mismatch with the HEVC codec?
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.