Package Details: ffmpeg-full-git 7.2.r118095.g95217872ad-1

Git Clone URL: https://aur.archlinux.org/ffmpeg-full-git.git (read-only, click to copy)
Package Base: ffmpeg-full-git
Description: Complete solution to record, convert and stream audio and video (all possible features including libfdk-aac; git version)
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, ffmpeg-full, ffmpeg-git, libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 21
Popularity: 0.061836
First Submitted: 2015-12-27 19:22 (UTC)
Last Updated: 2024-12-20 01:21 (UTC)

Required by (1914)

Sources (8)

Latest Comments

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

dbermond commented on 2024-11-02 14:32 (UTC)

@EndlessEden If you think the upstream build system is not correctly handling the compiler environment variables like 'CC', you should report this to them. Arch Linux packages are built with the default compiler in the distribution, which is gcc. Using another compiler is not supported, unless the package requires it explicitly. Upstream may not support building with clang (the last time I tried, it failed).

EndlessEden commented on 2024-11-02 11:00 (UTC) (edited on 2024-11-02 12:50 (UTC) by EndlessEden)

@dbermond -- idk if its my build environment, but i just noticed ./configure is ignoring makepkg.conf variables. (like CC, CXX, LD) breaking building on systems with tuned makepkg.conf. While it seems to grab CFLAGS, it ignores CC, even when its added inline in the PKGBUILD with ./configure.

Ive added the following just to ensure, and its working. \ --cc=$CC --cxx=$CXX \

Sidenote #1: id recommend checking if CC=clang, and set --nvcc=clang as well. It prevents some headaches with using NVCC with clang. | apparently with testing this is bad, as clang errors out out "-ptx"

Sidenote #2: Make also ignores $MAKEFLAGS, i confirmed this on multiple hosts.

dbermond commented on 2024-07-04 21:30 (UTC)

@spacemann yes, there is a a reason: it does not build against the stable lensfun package from the official repositories. ffmpeg requires the lensfun function 'lf_db_create', which is present only in lensfun git master. When trying to build with the stable lensfun from the official repositories, ffmpeg will complain about not finding lensfun with pkg-config, and the build log will show this: "error: 'lf_db_create' undeclared (first use in this function); did you mean 'lf_db_save'?". The lensfun-git package has not received an update in two years because the maintainer judged that there is no need for this, as it is a VCS package which is currently building fine and thus not requiring any intervention from him since then. This is perfectly normal in VCS packages, which can stay without an update during long times, as pkgver is automatically updated by makepkg. I've just checked, and ffmpeg-full-git is building perfectly fine using lensfun-git. I cannot reproduce your issue.

spacemann commented on 2024-07-04 16:24 (UTC)

Is there any reason why this depends specifically on lensfun-git, rather than extra/lensfun or lensfun-git? the -git version hasn't been updated since 2022, and I'm running into an error in my automated build related to it. ERROR: lensfun not found using pkg-config

dbermond commented on 2024-06-27 02:09 (UTC)

@spacemann package updated to match the latest upstream changes.

dbermond commented on 2024-06-27 02:08 (UTC)

@scjet the vpl-runtime is not used in systems without an Intel iGPU or dGPU, so it does not make any difference for you. Anyway, I've moved it to optdepends so it will easy the dependency burden on non-Intel users.

spacemann commented on 2024-06-20 22:11 (UTC) (edited on 2024-06-20 22:13 (UTC) by spacemann)

Looks like there was a change to ffmpeg, adding libvvenc, and the various flags for it were added at the exact points where libsvtvp9 is patched in via 030-ffmpeg-add-svt-vp9-g3b9a3fa.patch. I manually edited the 030 patch file to get it running again. It only involved changing configure, libavcodec/Makefile, and libavcodec/allcodecs.c, so I'm just including those changed parts of the patch.

If any run across this before the package is updated, you'll need to clone the repo, run makepkg -s, edit the PKGCONFIG file to skip the signature check, and edit the top of the 030 patch to the following, and then give it a final makepkg -si, as per usual:

From bcecbfb0188680c2f4e355ad843639f6198b36da Mon Sep 17 00:00:00 2001
From: hassene <hassene.tmar@intel.com>
Date: Fri, 15 Feb 2019 17:43:54 -0800
Subject: [PATCH] Add ability for ffmpeg to run svt vp9

Signed-off-by: hassene <hassene.tmar@intel.com>
Signed-off-by: Jing Sun <jing.a.sun@intel.com>
Signed-off-by: Austin Hu <austin.hu@intel.com>
Signed-off-by: Andrei Bich <dronimal@yandex-team.ru>
Signed-off-by: Guo Jiansheng <jiansheng.guo@intel.com>
---
 configure               |   4 +
 libavcodec/Makefile     |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/libsvt_vp9.c | 701 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 707 insertions(+)
 create mode 100644 libavcodec/libsvt_vp9.c

diff --git a/configure b/configure
index 71386c3920..3d3e7ba5a5 100755
--- a/configure
+++ b/configure
@@ -292,6 +292,7 @@ External library support:
   --enable-libvorbis       enable Vorbis en/decoding via libvorbis,
                            native implementation exists [no]
   --enable-libvpx          enable VP8 and VP9 de/encoding via libvpx [no]
+  --enable-libsvtvp9       enable VP9 encoding via svt [no]
   --enable-libvvenc        enable H.266/VVC encoding via vvenc [no]
   --enable-libwebp         enable WebP encoding via libwebp [no]
   --enable-libx264         enable H.264 encoding via x264 [no]
@@ -1948,6 +1949,7 @@ EXTERNAL_LIBRARY_LIST="
     libshaderc
     libshine
     libsmbclient
+    libsvtvp9
     libsnappy
     libsoxr
     libspeex
@@ -3537,6 +3539,7 @@ libvpx_vp8_decoder_deps="libvpx"
 libvpx_vp8_encoder_deps="libvpx"
 libvpx_vp9_decoder_deps="libvpx"
 libvpx_vp9_encoder_deps="libvpx"
+libsvt_vp9_encoder_deps="libsvtvp9"
 libvvenc_encoder_deps="libvvenc"
 libwebp_encoder_deps="libwebp"
 libwebp_anim_encoder_deps="libwebp"
@@ -6995,6 +6998,7 @@ enabled libvpx            && {
     fi
 }

+enabled libsvtvp9         && require_pkg_config libsvtvp9 SvtVp9Enc EbSvtVp9Enc.h       eb_vp9_svt_init_handle
 enabled libvvenc          && require_pkg_config libvvenc "libvvenc >= 1.6.1" "vvenc/vvenc.h" vvenc_get_version
 enabled libwebp           && {
     enabled libwebp_encoder      && require_pkg_config libwebp "libwebp >= 0.2.0" webp/encode.h WebPGetEncoderVersion
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8c8c2ce659..2a00269821 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1149,6 +1149,7 @@ OBJS-$(CONFIG_LIBVPX_VP8_DECODER)         += libvpxdec.o
 OBJS-$(CONFIG_LIBVPX_VP8_ENCODER)         += libvpxenc.o
 OBJS-$(CONFIG_LIBVPX_VP9_DECODER)         += libvpxdec.o
 OBJS-$(CONFIG_LIBVPX_VP9_ENCODER)         += libvpxenc.o
+OBJS-$(CONFIG_LIBSVT_VP9_ENCODER)         += libsvt_vp9.o
 OBJS-$(CONFIG_LIBVVENC_ENCODER)           += libvvenc.o
 OBJS-$(CONFIG_LIBWEBP_ENCODER)            += libwebpenc_common.o libwebpenc.o
 OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)       += libwebpenc_common.o libwebpenc_animencoder.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 2386b450a6..58b17d4c34 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -799,6 +799,7 @@ extern const FFCodec ff_libvpx_vp8_encoder;
 extern const FFCodec ff_libvpx_vp8_decoder;
 extern FFCodec ff_libvpx_vp9_encoder;
 extern const FFCodec ff_libvpx_vp9_decoder;
+extern const FFCodec ff_libsvt_vp9_encoder;
 extern const FFCodec ff_libvvenc_encoder;
 /* preferred over libwebp */
 extern const FFCodec ff_libwebp_anim_encoder;

scjet commented on 2024-06-19 08:11 (UTC) (edited on 2024-06-19 08:30 (UTC) by scjet)

Hi, I'm using AMD system, is there any advantage to choosing "vpl-runtime" over the default "intel-media-sdk", or should I just stick to the default option. ?


...
:: There are 2 providers available for vpl-runtime:
:: Repository extra
    1) intel-media-sdk 2) vpl-gpu-rt 

Enter a number (default=1): 

...

kentslaney commented on 2024-06-02 08:15 (UTC) (edited on 2024-06-02 08:43 (UTC) by kentslaney)

@dbermond Oh, my mistake on the AUR package. I'm going to copy/paste over to ffmpeg-full if you don't mind, similar problems have been bothering me for a while now and fwiw the script should be robust to changes in the linked file path. (libavutil/hwcontext_cuda.o and ffnvcodec) I can delete my previous comment on this thread if it matters.

There's nothing wrong with the package, my mistake was that I had previously created a manual build in /usr/share/lib so the version included was out of date. I know there were at least a couple comments on the non-git version with the same problem.

No pkgbuild patches necessary. Thanks for the repo.

Re AUR helpers: this doesn't install the package, it just helps diagnose the problem by outputting something like this to STDOUT:

# 1 "/usr/include/ffnvcodec/dynlink_loader.h" 1 3 4
# 33 "/usr/include/ffnvcodec/dynlink_loader.h" 3 4
# 1 "/usr/include/ffnvcodec/dynlink_cuda.h" 1 3 4
# 31 "/usr/include/ffnvcodec/dynlink_cuda.h" 3 4
# 32 "/usr/include/ffnvcodec/dynlink_cuda.h" 2 3 4
# 44 "/usr/include/ffnvcodec/dynlink_cuda.h" 3 4
# 416 "/usr/include/ffnvcodec/dynlink_cuda.h" 3 4
# 34 "/usr/include/ffnvcodec/dynlink_loader.h" 2 3 4
# 1 "/usr/include/ffnvcodec/dynlink_nvcuvid.h" 1 3 4
# 38 "/usr/include/ffnvcodec/dynlink_nvcuvid.h" 3 4

(though not with the correct path if the include path is wrong)

dbermond commented on 2024-06-02 04:07 (UTC)

@kentslaney First of all, AUR helpers are not supported, use makepkg. Second, this package is not ffmpeg-full, but ffmpeg-full-git. That being said, I cannot reproduce your issue. The package is building perfectly fine for me.

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