Package Details: ffmpeg-full-git 7.2.r118095.g95217872ad-1

Git Clone URL: https://aur.archlinux.org/ffmpeg-full-git.git (read-only, click to copy)
Package Base: ffmpeg-full-git
Description: Complete solution to record, convert and stream audio and video (all possible features including libfdk-aac; git version)
Upstream URL: https://www.ffmpeg.org/
Keywords: audio codec convert cuda cuvid decklink encoder fdk-aac fdkaac hwaccel libnpp media nvenc svt video
Licenses: LicenseRef-nonfree-and-unredistributable
Conflicts: ffmpeg
Provides: ffmpeg, ffmpeg-full, ffmpeg-git, libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 21
Popularity: 0.055823
First Submitted: 2015-12-27 19:22 (UTC)
Last Updated: 2024-12-20 01:21 (UTC)

Dependencies (134)

Required by (1908)

Sources (8)

Latest Comments

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

dbermond commented on 2018-03-06 21:32 (UTC)

@winneon Can you please provide a pastebin output log of the ffmpeg and mpv commands that are generating these crashes for you? You are the first one to report this.

winneon commented on 2018-03-06 00:53 (UTC)

Are you going to update this package to provide a way to not include CUDA and NVENC-related options? These packages have no use to anyone not on Nvidia GPUs and it causes crashes specifically on AMD GPUs.

winneon commented on 2018-02-12 23:01 (UTC)

Also in an completely unrelated comment, the CUDA and NVENC related options that this package compiles along with ffmpeg cause issues when using ffmpeg and when using other programs such as mpv when not using Nvidia GPUs or Nvidia's drivers. Both ffmpeg and mpv create invalid pointer crashes, and the only way to solve it is to remove everything within the "x86_64" conditional block within the PKGBUILD.

winneon commented on 2018-02-12 22:56 (UTC) (edited on 2018-02-12 22:57 (UTC) by winneon)

While I do agree with everything @dbermond has said, some people just want to have their cake and eat it too, and there shouldn't be anything preventing them from doing that, as long as they understand the risks and are aware that the package that is designed to co-exist with ffmpeg-git/ffmpeg-full-git will become obsolete once 3.5 is released.

Because of this, I created an ffmpeg-full3.4 package on the AUR to solve this problem. Most packages that required the ffmpeg 3.4 libav* libraries will now compile correctly, and for the ones that don't, all you need to do is modify their PKGBUILD and add appropriate CFLAGS & LDFLAGS to /usr/include/ffmpeg3.4 and /usr/lib/ffmpeg3.4 respectively.

dbermond commented on 2018-02-10 00:56 (UTC)

@MichaelChou First of all, having your other software to be broken is a cost that the user needs to accept when living on the bleeding edge by using development (-git) packages, like ffmpeg-full-git and ffmpeg-git. When using such packages (and not the official repositories ones), the user is supposed to be able to handle all the problems that it may cause.

Regarding your described problems: 1) ffmpeg(-full)-git and ffmpeg(-full) are not supposed to coexist, so this is not a problem. 2) Library major version number only changes when ffmpeg switches API, and this happens only once in a while, usually at round ffmpeg version numbers like 3.0, 3.5, etc. Since, ffmpeg is currently preparing for the 3.5 release, we are currently getting incompatibility with previous releases like 3.4. This is normal and expected when using ffmpeg git master, and as I stated above, the person that uses ffmpeg git master is supposed to handle this situation. 3) Since ffmpeg git master is currently changing API, fairly new and incompatible upstream code is being added constantly. You cannot expect that every software out there that depends on ffmpeg will catch these changes so quickly while it is still happening. So, we cannot expect that other software will be able to compile with ffmpeg git master anytime soon. Most probably it will take a while. I have posted some possible solutions for this in an answer to @Nothing4You a few comments back when he asked about firefox.

Regarding your questions about ffmpeg-full-git and ffmpeg-git: development (-git) packages definitively should not be modified to coexist with the corresponding packages from the official repositories. So I will not change ffmpeg-full-git and ffmpeg-git to match this approach.

Regarding your suggestion: Personally, I think that creating another AUR package based on ffmpeg-full-git and ffmpeg-git with the goal to make it coexist with ffmpeg from the official repositories is not a good idea. Mostly because this new proposed package will be useful only when ffmpeg is switching API (and major library version number) like now. For example, when 3.5 is released, this new proposed package will be useless until ffmpeg reaches 4.0 (supposing that upstream development cycle stays the same as it was). Creating an AUR package just for this short period of time while API is switching during upstream preparation for 3.5 does not seems logical to me. Other reasons also apply, like increased complexity (remember that Arch tries to keep it simple ;). What you could do, is to use a modified ffmpeg-full-git PKGBUILD to make it install elsewhere, just for your personal needs. I have done this in the past when this same situation happened during the 2.8 to 3.0 transition, but now I prefer to simply don't use software that is not compatible with current ffmpeg git master.

MichaelChou commented on 2018-02-09 04:49 (UTC)

@dbermond

For the following somehow related problems: 1. ffmpeg(-full)-git and ffmpeg(-full) can not co-exist. 2. Packages depend on ffmpeg libs need to recompile every time the so version number changes. And that's a lot of them. 3. A few software are not compatible with the ffmpeg(-full)-git.

I have a suggestion: create a ffmpeg git package just like the official ffmpeg2.8 (https://www.archlinux.org/packages/extra/x86_64/ffmpeg2.8/).

I wonder what's your opinion about this? - Should this package change to that structure? - Or should we make another package to do that? And if this is the way to go, I can find some time to maintain that. What package name do you suggest this package to have?

dbermond commented on 2018-02-03 23:56 (UTC)

@ahjolinna Thank you for pointing this and for the interest in ffmpeg-full-git. Switched zimg-git dependency back to zimg.

ahjolinna commented on 2018-02-03 16:54 (UTC)

zimg 2.7.3 is now in repos, git version shouldn't be needed anymore (at least for now :D)

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