Package Details: lib32-libffmpeg 2:4.3.1-5

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 - library (32 bit)
Upstream URL: http://ffmpeg.org/
Licenses: GPL3
Provides: lib32-ffmpeg, libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so
Submitter: lano1106
Maintainer: oxalin
Last Packager: oxalin
Votes: 29
Popularity: 0.020949
First Submitted: 2013-05-18 04:43
Last Updated: 2020-11-22 22:30

Dependencies (53)

Required by (104)

Sources (3)

Pinned Comments

oxalin commented on 2018-02-25 07:37

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

Latest Comments

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

oxalin commented on 2020-09-30 05:37

@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.

oxalin commented on 2020-09-28 14:55

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

DDoSolitary commented on 2020-09-28 13:18

@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.

PedroHLC commented on 2020-09-28 12:52

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.

Lakso commented on 2020-09-26 17:20

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...

csts commented on 2020-08-17 16:33

Fixed with:

gpg --keyserver hkp://keys.gnupg.net --recv-keys 7FE6B095B582B0D4

gpg --keyserver hkp://keys.gnupg.net --recv-keys B4322F04D67658D8

csts commented on 2020-08-17 15:13

~ ❯❯❯ 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

oxalin commented on 2020-08-15 02:50

@Samega7Cattac update x264 to version 0.160. I'll update the PKGBUILD file to enforce it.

Samega7Cattac commented on 2020-08-14 21:27

/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

sl1pkn07 commented on 2020-07-15 19:11

Hi

why is splitted? this is arch, no ubuntu

greetings