Package Details: lib32-ffmpeg 2:6.1.1-2

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.98
First Submitted: 2013-05-18 04:43 (UTC)
Last Updated: 2024-04-12 00:28 (UTC)

Required by (267)

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

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

unit73e commented on 2024-04-14 15:49 (UTC)

Just to confirm that it works now. Thanks.

oxalin commented on 2024-04-11 11:35 (UTC)

@unit73e as much as possible, with some exceptions where 32bit libraries are unavailable. Unavailable features are still listed in PKGBUILD with a mention about it.

unit73e commented on 2024-04-10 17:48 (UTC)

@oxalin so if I understood correctly, you have lib32-ffmpeg identical to ffmpeg?

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 2024-04-08 20:31 (UTC)

About nvenc build error, it seems to be related to the new ffnvcodec-headers 12.2. Downgrading ffnvcodec-headers will probably fix the error.

A part of the build error can be fixed by commit:

avcodec/nvenc: stop using long deprecated format specifiers

git cherry-pick -n 43b417d516b0fabbec1f02120d948f636b8a018e

But then, we have a problem with ffnvcodec-headers 12.2, so we need commit

avcodec/nvenc: support SDK 12.2 bit depth API

git cherry-pick -n 06c2a2c425f22e7dba5cad909737a631cc676e3f

Still, it fails with a SEGFAULT. I don't have time to dig deeper at the moment and I know it will pop in the native package. And we will probably update to 6.2 (to be released) or upgrade to 7.0 (released) at this point.

xiota commented on 2024-04-08 17:19 (UTC)

Clean chroot. Same errors as @unit73e. Build succeeds with option changed to disable-nvenc.

unit73e commented on 2024-04-07 13:56 (UTC)

I haven't checked yet why but it doesn't compile on my machine:

libavcodec/nvenc.c: In function ‘nvenc_setup_hevc_config’:
libavcodec/nvenc.c:1373:9: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘pixelBitDepthMinus8’
 1373 |     hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
      |         ^~
libavcodec/nvenc.c: In function ‘nvenc_setup_av1_config’:
libavcodec/nvenc.c:1458:8: error: ‘NV_ENC_CONFIG_AV1’ has no member named ‘inputPixelBitDepthMinus8’
 1458 |     av1->inputPixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
      |        ^~
libavcodec/nvenc.c:1459:8: error: ‘NV_ENC_CONFIG_AV1’ has no member named ‘pixelBitDepthMinus8’
 1459 |     av1->pixelBitDepthMinus8 = (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) ? 2 : 0;
      |        ^~
libavcodec/nvenc.c: In function ‘nvenc_map_buffer_format’:
libavcodec/nvenc.c:1692:16: error: ‘NV_ENC_BUFFER_FORMAT_YV12_PL’ undeclared (first use in this function); did you mean ‘NV_ENC_BUFFER_FORMAT_YV12’?
 1692 |         return NV_ENC_BUFFER_FORMAT_YV12_PL;
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                NV_ENC_BUFFER_FORMAT_YV12
libavcodec/nvenc.c:1692:16: note: each undeclared identifier is reported only once for each function it appears in
libavcodec/nvenc.c:1694:16: error: ‘NV_ENC_BUFFER_FORMAT_NV12_PL’ undeclared (first use in this function); did you mean ‘NV_ENC_BUFFER_FORMAT_NV12’?
 1694 |         return NV_ENC_BUFFER_FORMAT_NV12_PL;
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                NV_ENC_BUFFER_FORMAT_NV12
libavcodec/nvenc.c:1700:16: error: ‘NV_ENC_BUFFER_FORMAT_YUV444_PL’ undeclared (first use in this function); did you mean ‘NV_ENC_BUFFER_FORMAT_YUV444’?
 1700 |         return NV_ENC_BUFFER_FORMAT_YUV444_PL;
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                NV_ENC_BUFFER_FORMAT_YUV444
make: *** [ffbuild/common.mak:81: libavcodec/nvenc.o] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

Something to do with Nvidia libraries. I don't have an Nvidia card so maybe there's a missing dependency.

ukbeast commented on 2024-03-13 23:27 (UTC)

Add a patch to fix build with latest vulkan headers

Fix build with latest vulkan headers

git cherry-pick -n fef22c87ada4517441701e6e61e062c9f4399c8e

Source: https://gitlab.archlinux.org/archlinux/packaging/packages/ffmpeg/-/commit/7949dedb0749ce00ff24a025ceaa662f82ca73a3

MarsSeed commented on 2023-12-20 15:51 (UTC)

And lib32-openjpeg2 is totally superfluous as well: FFMPEG has an internal JPEG2000 video codec which is even faster.

MarsSeed commented on 2023-12-20 15:40 (UTC)

Additionally, there are no existing applications that would possibly use lib32-libbluray (demuxing BluRay formats), lib32-vpx (open format alternative to BluRay video codecs), lib32-x264 (Blu-Ray codec) and lib32-x265 (better-than-BluRay codec).

Same is true for lib32-aom and lib32-libdav1d - open format alternatives to h.265 / x265.

Nor do any bin32 applications use the Secure Reliable Trabsport protocol from 2018 (lib32-srt).

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