Arch Linux User Repository

For those wondering: I intentionally keep this package as close to the native package as possible, to the extent of the available dependencies. FFMPEG package sees a lot of modifications through time and I prefer to follow the changes applied to the native PKGBUILD as much as possible. The more it goes, the more flags are added and the more often we need to cherrypick commits (until a new release comes in).

This means I'll keep the dependencies around even if there is no obvious usecase for them.

Also, since openjpeg2 is still used with the native package, I'll also keep it around. Last thing I read about the JPEG2000 internal decoder was that it was faster, but that it was still introducing errors in the rendering. This probably explains why it is still enable in the native package. I look at it once in a while and things may have evolved since, but a quick checkup didn't bring up any tangible answer.

Now, if someone would like to take the ownership of this package, I would be more than pleased to hand it over. The same goes for any related packages that I maintain mostly for FFMPEG. lib32-libffmpeg and lib32-ffmpeg could be merged back together to simplify its maintenance.

Let me know if this is something you're interested in.

About GPG, it is up to you to import the missing public key. If you receive an error about it, this is ffmpeg's project public key. Something like the following should do the trick: gpg --recv-keys B4322F04D67658D8

@Patola

The PKGBUILD requires git to build properly. https://aur.archlinux.org/packages/lib32-x265/

You could try https://wiki.archlinux.org/index.php/unofficial_user_repositories#archlinuxcn for prebuilt aur binaries. Trusting a 3rd party repo is entirely up to you.

how do I get lib32-x265=3.4? Seems a game on Steam is not working due to the lack of lib32-gst-plugins-bad, which wont compile with lib32-x265=3.5.

@oxalin: Small note, as I've just realised by trying to upgrade only lib32-ffmpeg without also upgrading x264 and x265:

In PKGBUILD's depends version constraint,

depends=('lib32-x264>=0.161')

does not enforce lib32-x264=3:0.160.r3011.cde9a93-4 to be upgraded to 3:0.161.r3039.544c61f-1.

Reason is: because of the epoch value of 3, any 3:V (V: version string) will be higher than 0.160 because the latter is considered as 0:0.160.

You should try to declare your intended version constraint like below:

depends=('lib32-x264>=3:0.161')

@oxalin You wrote:

"As a matter of fact, the native ffmpeg package
doesn't have a version check on these dependencies."

The package might not have that check, but the build config of ffmpeg does have it in case of checking x265 in /usr/lib32:

Quote from my previous build log src/ffmpeg/ffbuild/config.log below (check the command line parameters calling the tests: -L/usr/lib32).

check_func_headers x265.h x265_api_get -L/usr/lib32 -lx265
test_ld cc -L/usr/lib32 -lx265
test_cc -L/usr/lib32
BEGIN /tmp/ffconf.WwFZr5sp/test.c
    1   #include <x265.h>
    2   #include <stdint.h>
    3   long check_x265_api_get(void) { return (long) x265_api_get; }
    4   int main(void) { int ret = 0;
    5    ret |= ((intptr_t)check_x265_api_get) & 0xFFFF;
    6   return ret; }
END /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=native -O2 -pipe -fstack-protector-strong -fno-plt -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-traditional -Wno-unused-but-set-variable -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libmodplug/ -I/usr/include/openjpeg-2.4 -I/usr/include/opus -I/usr/include/opus -D_REENTRANT -I/usr/include/srt -I/usr/include/libvmaf -DX264_API_IMPORTS -L/usr/lib32 -c -o /tmp/ffconf.WwFZr5sp/test.o /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--as-needed -Wl,-z,noexecstack -L/usr/lib32 -o /tmp/ffconf.WwFZr5sp/test /tmp/ffconf.WwFZr5sp/test.o -lx265
/usr/bin/ld: /tmp/ffconf.WwFZr5sp/test.o: in function `check_x265_api_get':
test.c:(.text+0xc): undefined reference to `x265_api_get_192'
collect2: error: ld returned 1 exit status
ERROR: x265 not found using pkg-config

@oxalin: You wrote:

"I specifically updated lib32-x265 and lib32-x264 in par to the
native packages prior to updating lib32-ffmpeg's PKGBUILD and
I cleaned out lib32-ffmpeg's build folder to be sure."

-- I will try to do the same, in that order again. (Though that order was the one that I did it the first time and which caused the build-time failures for my lib32-libffmpeg package.)

I suspect that the other way around would be workable though -- first installing the older x264 and x265, then installing the latest lib32-libffmpeg, then upgrading x264 and x265.

@oxalin: Thank you for checking this issue. I've started to have my doubts when I saw that Arch maintainers were able to rebuild the x86_64 version of ffmpeg v4.3.2 against the newer versions of x264 and x265, seemingly without any adaptations on their part.

I will try to do a full rebuild of lib32 versions from AUR PKGBUILDs after making sure I removed the previous versions and cleaned my caches. I use ccache so I will double-check to make sure I cleaned that as well.

Meanwhile I realized that it might be harder to maintain version checks in AUR PKGBUILDs than what binary repo maintainers can do. For each depends=(some_library.so) entry in the PKGBUILD, the makepkg will, during build time, check the installed library file version and hard-code that version in the package tarball - e.g., save it as depends=(some_library.so=1.1) in the .PKGINFO of the binary package.

This same strict locking might not always be viable here on AUR, even less so if dependencies are maintained by different people at different points in time. If a dependency's PKGBUILD does not manually declare provided library versions with something like provides=(somethings.so=1.1), then for the dependant (consumer) package, hard-coding the main pkg version of the dependency is the only other locking option. And that might just be unnecessarily strict and cause more installations to fail due to unsatisfied dependency versions.

I currently use yay, and that seems to not behave too well with strict dependency version locking, even when two or three interrelated AUR packages are selected to be installed as part of the same transaction.*

(*Note: yay can be configured to build all selected AUR packages first, and install them all at once at the end. This could help during install-time, if interrelated, version-locked package dependencies get installed the same time as the dependant (consumer) package. But in that case, if ffmpeg does indeed check already installed library versions in /usr/lib32, then it will have checked the wrong libraries, because they have not yet been updated.)

@MarsSeed : Hi there. Just to let you know, I specifically updated lib32-x265 and lib32-x264 in par to the native packages prior to updating lib32-ffmpeg's PKGBUILD and I cleaned out lib32-ffmpeg's build folder to be sure.

Also, as another check, I re-installed lib32-ffmpeg from pacaur.

It seems you could either have a remnant of a previous lib32-ffmpeg build or your x265 | lib32-x265 and x264 | lib32-x264 were out of sync.

As a matter of fact, the native ffmpeg package doesn't have a version check on these dependencies. However, maintainers have to provide incremental updates each time the dependies are updated. It was updated a few days ago because of x265 and x264 updates.

What I can do and should have done though (forgot about them) is to update the dependencies' version. This would prevent building lib32-ffmpeg if there is a mismatch with dependies and force ffmpeg to update its configuration at build time. I'll be updating the PKGBUILD file right away.

Also in this version (v2:4.3.2-1), build fails if current lib32-x264=0.161 is installed. Build requires lib32-x264=0.160 to succeed.

More specifically, lib32-libffmpeg v2:4.3.2-1 requires libx264.so=160-32 provided by lib32-x264=0.160(.r3039.544c61f-1).

See build log excerpt:

/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffplay_g] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffprobe_g] Error 1
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `x264_encoder_open_160'
collect2: error: ld returned 1 exit status
make: *** [Makefile:114: ffmpeg_g] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

Since the latest update (v2:4.3.2-1), build fails if lib32-x265=3.5 is installed. Build succeeds if lib32-x265=3.4 is installed instead.

A build config test expects the following result from the installed usr/lib32/libx265.so: 'x265_api_get_192'. The lib32-x265=3.4 provides libx265.so=192-32 whereas lib32-x265=3.5 provides libx265.so=199-32.

Log excerpt:

==> Making package: lib32-ffmpeg 2:4.3.2-1 (27 March 2021, 21:09:41 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Starting build()...
ERROR: x265 not found using pkg-config

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.
==> ERROR: A failure occurred in build().
    Aborting...

From src/ffmpeg/ffbuild/config.log:

require_pkg_config libx265 x265 x265.h x265_api_get
check_pkg_config libx265 x265 x265.h x265_api_get
test_pkg_config libx265 x265 x265.h x265_api_get
pkg-config --exists --print-errors x265
check_func_headers x265.h x265_api_get -L/usr/lib32 -lx265
test_ld cc -L/usr/lib32 -lx265
test_cc -L/usr/lib32
BEGIN /tmp/ffconf.WwFZr5sp/test.c
    1   #include <x265.h>
    2   #include <stdint.h>
    3   long check_x265_api_get(void) { return (long) x265_api_get; }
    4   int main(void) { int ret = 0;
    5    ret |= ((intptr_t)check_x265_api_get) & 0xFFFF;
    6   return ret; }
END /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=native -O2 -pipe -fstack-protector-strong -fno-plt -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-traditional -Wno-unused-but-set-variable -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/fribidi -I/usr/include/libmodplug/ -I/usr/include/openjpeg-2.4 -I/usr/include/opus -I/usr/include/opus -D_REENTRANT -I/usr/include/srt -I/usr/include/libvmaf -DX264_API_IMPORTS -L/usr/lib32 -c -o /tmp/ffconf.WwFZr5sp/test.o /tmp/ffconf.WwFZr5sp/test.c
gcc -m32 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--as-needed -Wl,-z,noexecstack -L/usr/lib32 -o /tmp/ffconf.WwFZr5sp/test /tmp/ffconf.WwFZr5sp/test.o -lx265
/usr/bin/ld: /tmp/ffconf.WwFZr5sp/test.o: in function `check_x265_api_get':
test.c:(.text+0xc): undefined reference to `x265_api_get_192'
collect2: error: ld returned 1 exit status
ERROR: x265 not found using pkg-config

@Cysioland : is it still a problem? Maybe you were in the middle of an update? Maybe lib32-openjpeg2 and openjpeg2 packages were not of the same version (this last option should now be fixed, I just pushed an update to lib32-openjpeg2)?