Package Details: ffmpeg6.1 6.1.2-2

Git Clone URL: https://aur.archlinux.org/ffmpeg6.1.git (read-only, click to copy)
Package Base: ffmpeg6.1
Description: Complete solution to record, convert and stream audio and video (legacy v6.1)
Upstream URL: https://ffmpeg.org
Licenses: GPL-3.0-only
Submitter: patlefort
Maintainer: patlefort
Last Packager: patlefort
Votes: 4
Popularity: 0.50
First Submitted: 2024-06-24 13:43 (UTC)
Last Updated: 2024-11-08 01:02 (UTC)

Pinned Comments

patlefort commented on 2024-11-08 04:08 (UTC) (edited on 2024-11-09 04:22 (UTC) by patlefort)

To avoid problem with versioned dependencies, please build in a clean container/chroot and use a local repository. https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

Tools like mine pat-aur or others like paru or aura can do it and make your life easier.

Latest Comments

1 2 Next › Last »

patlefort commented on 2024-11-09 03:40 (UTC)

Also aur helpers really need to make building in a clean containers the default. It is the correct way and would solve many problems with the aur. The Arch community needs to be hit over the head about it.

patlefort commented on 2024-11-09 03:31 (UTC)

The package was designed this way when it was in the official repos so I kept it that way assuming there is a good reason. Of course it's more trouble on the AUR since we aren't in perfect lockstep with official repos.

jianglai commented on 2024-11-09 03:11 (UTC) (edited on 2024-11-09 03:19 (UTC) by jianglai)

@patlefort Maybe it is worth having a pinned comment about this? I imagine the same problem will come up every time these dependent libraries update. (In fact it was brought up multiple times in the comments. I just checked.)

I now understand what you meant by "It just needs recompilation". While it is technically correct, people might not realize what the correct steps are. I certainly didn't when I first saw it.

On a side note, (this might be a silly question), why does the compilation process dynamically link to a library with the specific x.y.z version pinned? It would be better if it only pins to major versions, or if the upgrade of a dependent library automatically triggers a recompilation of this package. Or maybe just statically link the library so you never have to worry about it changing again.

patlefort commented on 2024-11-08 04:08 (UTC) (edited on 2024-11-09 04:22 (UTC) by patlefort)

To avoid problem with versioned dependencies, please build in a clean container/chroot and use a local repository. https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

Tools like mine pat-aur or others like paru or aura can do it and make your life easier.

jianglai commented on 2024-11-08 03:47 (UTC) (edited on 2024-11-09 03:06 (UTC) by jianglai)

OK, it looks like this package dynamically links to librubberband and libx265 with the versions pinned at compile time. Therefore upgrading the dependencies breaks the package. To solve this, delete ffmpeg6.1, upgrade the dependencies, and install ffmpeg6.1 again to pin to the newer version.

jianglai commented on 2024-11-08 00:35 (UTC)

It breaks rubberband and x265:

:: installing rubberband (4.0.0-1) breaks dependency 'librubberband.so=2-64' required by ffmpeg6.1
:: installing x265 (4.0-1) breaks dependency 'libx265.so=209-64' required by ffmpeg6.1

username227 commented on 2024-11-07 22:25 (UTC) (edited on 2024-11-07 22:47 (UTC) by username227)

the version needs to be bumped. But also, i'm getting a build error:

libavcodec/libx265.c: In function ‘libx265_encode_frame’: libavcodec/libx265.c:708:59: error: passing argument 5 of ‘ctx->api->encoder_encode’ from incompatible pointer type [-Wincompatible-pointer-types] 708 | pic ? &x265pic : NULL, &x265pic_out); | ^~~~ | | | x265_picture * libavcodec/libx265.c:708:59: note: expected ‘x265_picture *’ but argument is of type ‘x265_picture ’ CC libavcodec/lzf.o make: *** [ffbuild/common.mak:81: libavcodec/libx265.o] Error 1 make: *** Waiting for unfinished jobs....

EDIT: i was able to bulid by changing libx265 to disable. Don't know if this will disable a codec of some kind though.

patlefort commented on 2024-10-04 16:34 (UTC)

I've removed the signature check for now, that version is signed with an expired key.

humanfish451 commented on 2024-09-22 15:41 (UTC)

Got it, thanks. Working now.

patlefort commented on 2024-09-22 13:54 (UTC)

Again, it just need recompilation.

1 2 Next › Last »