Package Details: ffmpeg-full-git 7.2.r117638.g153a6dc8fa-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.113902
First Submitted: 2015-12-27 19:22 (UTC)
Last Updated: 2024-10-24 20:29 (UTC)

Dependencies (134)

Required by (1917)

Sources (8)

Latest Comments

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

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)

dbermond commented on 2017-12-06 17:56 (UTC)

@ahjolinna That's true. I'm using zimg-git too for the last days. I was hoping that zimg version 2.6.3 would solve this issue, but currently it really needs zimg git master. I have temporarily switched zimg dependency to zimg-git. Thank you for the interest.

ahjolinna commented on 2017-12-05 16:17 (UTC)

I needed to install zimg-git for this to compile, didn't compile with "stable" 2.6.2 (nor 2.6.3 )

dbermond commented on 2017-11-01 19:40 (UTC) (edited on 2017-11-01 19:52 (UTC) by dbermond)

@Nothing4You This is normal and expected. That's because ffmpeg git master has switched API in preparation for the next 3.5 release. For this, they increased the so-version-number of the libraries. Since repository packages are compiled against ffmpeg 3.4, they will fail to locate the older target libraries that have lower so-version-numbers. Some possible options are: 1) Recompile all your software that depends on ffmpeg. But many of these software will fail to compile with the newer ffmpeg git master, since this is fairly new code. An example is Firefox. At least, it did not compiled for me on the last time that ffmpeg switched API. I didn't even tried recompile Firefox this time (it takes a lot of time). An example that currently works is vlc, but you will need to use vlc-git from aur. 2) Use another software. For example, I'm using chromium, which does not depend on ffmpeg. 3) If you cannot live without Firefox or any other favorite software, currently you need to use ffmpeg 3.4 (from the official repositories or ffmpeg-full if you wish), or ask upstream to support ffmpeg git master.

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