| Git Clone URL: | https://aur.archlinux.org/lib32-ffmpeg.git (read-only, click to copy) |
|---|---|
| Package Base: | lib32-ffmpeg |
| Description: | Complete solution to record, convert and stream audio and video (32 bit) |
| Upstream URL: | http://ffmpeg.org |
| Licenses: | GPL-3.0-only |
| Conflicts: | lib32-libffmpeg |
| Provides: | libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so |
| Replaces: | lib32-libffmpeg |
| Submitter: | lano1106 |
| Maintainer: | oxalin |
| Last Packager: | oxalin |
| Votes: | 37 |
| Popularity: | 0.006711 |
| First Submitted: | 2013-05-18 04:43 (UTC) |
| Last Updated: | 2024-09-27 17:48 (UTC) |
ERROR: libopenjp2 >= 2.1.0 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.
@PedroHLC, as stated by DDoSolitary, 32-bit apps are not necessarily old or legacy. Let's take Valve's Steam as an example: the client and some games are running 32 bit code.
As long as there will be needs for some closed source apps, we will be stuck with 32 bit dependencies, even for recent apps.
That being said, I'm mostly mirroring the native package. I could offer a leaner package with less dependencies. However, since the native package offers some functionalities, some may expect them under 32 bit as well.
There is an issue reported upstream with a commit fixing the issue. I'll update FFMPEG:
Upstream issue: https://trac.ffmpeg.org/ticket/8760
Patch / commit: https://git.videolan.org/?p=ffmpeg.git;a=patch;h=7c59e1b0f285cd7c7b35fcd71f49c5fd52cf9315
@PedroHLC I don't think it's good idea. While 32-bit binaries are dying out in normal Linux systems, they're still ubiquitous in many places and being 32-bit alone doesn't necessarily mean they're legacy or old-dated things. For example, a large number of modern Windows applications are still delivered as 32-bit binaries for compatibility reasons, and Wine needs these lib32-* packages to run these applications. Removing support for new formats is very likely to break these use cases.
Not calling for any action, but in the future, this package may need some rethinking.
Like, we use lib32-* packages for "legacy" apps that weren't brought to the "x64" era.
Why would a so old-dated app need x265, av1, knows how to use nvenc, etc... These new formats increase dependencies and the frequency we need to rebuild this package. And these features play much nicer in your native arch.
What I mean is: at some point, I think it will be interesting to pick a year and feature freeze this package to that year's formats.
Can't build the package, returns error
libavformat/libsrt.c: In function ‘libsrt_set_options_pre’:
libavformat/libsrt.c:317:66: error: ‘SRTO_STRICTENC’ undeclared (first use in this function); did you mean ‘SRTO_STATE’?
317 | (s->enforced_encryption >= 0 && libsrt_setsockopt(h, fd, SRTO_STRICTENC, "SRTO_STRICTENC", &s->enforced_encryption, sizeof(s->enforced_encryption)) < 0) ||
| ^~~~~~~~~~~~~~
| SRTO_STATE
libavformat/libsrt.c:317:66: note: each undeclared identifier is reported only once for each function it appears in
libavformat/libsrt.c:336:50: error: ‘SRTO_SMOOTHER’ undeclared (first use in this function); did you mean ‘SRTO_SENDER’?
336 | (s->smoother && libsrt_setsockopt(h, fd, SRTO_SMOOTHER, "SRTO_SMOOTHER", s->smoother, strlen(s->smoother)) < 0) ||
| ^~~~~~~~~~~~~
| SRTO_SENDER
libavformat/libsrt.c: In function ‘libsrt_setup’:
libavformat/libsrt.c:409:5: warning: ‘srt_socket’ is deprecated [-Wdeprecated-declarations]
409 | fd = srt_socket(cur_ai->ai_family, cur_ai->ai_socktype, 0);
| ^~
In file included from libavformat/libsrt.c:24:
/usr/include/srt/srt.h:754:41: note: declared here
754 | SRT_ATR_DEPRECATED_PX SRT_API SRTSOCKET srt_socket(int, int, int) SRT_ATR_DEPRECATED;
| ^~~~~~~~~~
make: *** [ffbuild/common.mak:59: libavformat/libsrt.o] Error 1
==> ERROR: A failure occurred in build().
Aborting...
Fixed with:
gpg --keyserver hkp://keys.gnupg.net --recv-keys 7FE6B095B582B0D4
gpg --keyserver hkp://keys.gnupg.net --recv-keys B4322F04D67658D8
~ ❯❯❯ gpg --recv-keys 7FE6B095B582B0D4
gpg: keyserver receive failed: No name
~ ❯❯❯ gpg --search-keys 7FE6B095B582B0D4
gpg: error searching keyserver: No name
gpg: keyserver search failed: No name
~ ❯❯❯ gpg --recv-keys B4322F04D67658D8
gpg: keyserver receive failed: No name
~ ❯❯❯ gpg --search-keys B4322F04D67658D8
gpg: error searching keyserver: No name
gpg: keyserver search failed: No name
@Samega7Cattac update x264 to version 0.160. I'll update the PKGBUILD file to enforce it.
/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
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: ffplay_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: ffprobe_g] Error 1
Pinned Comments
oxalin commented on 2024-04-09 22:05 (UTC)
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.
oxalin commented on 2018-02-25 07:37 (UTC) (edited on 2020-05-25 15:55 (UTC) by oxalin)
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