Package Details: lib32-ffmpeg 2:7.0.1-1

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.042020
First Submitted: 2013-05-18 04:43 (UTC)
Last Updated: 2024-08-03 20:23 (UTC)

Required by (292)

Sources (2)

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

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 21 Next › Last »

oxalin commented on 2020-09-30 05:37 (UTC)

@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 (UTC)

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 (UTC) (edited on 2020-09-28 13:18 (UTC) by DDoSolitary)

@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 (UTC)

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 (UTC) (edited on 2020-09-26 17:21 (UTC) by Lakso)

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 (UTC)

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 (UTC)

~ ❯❯❯ 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 (UTC)

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

Samega7Cattac commented on 2020-08-14 21:27 (UTC) 

/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 (UTC)

Hi

why is splitted? this is arch, no ubuntu

greetings

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 21 Next › Last »