Package Details: ffmpeg-full-git 7.2.r119449.g1b643e3f65-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, libswresample.so, libswscale.so
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 22
Popularity: 0.48
First Submitted: 2015-12-27 19:22 (UTC)
Last Updated: 2025-05-07 20:18 (UTC)

Required by (1963)

Sources (8)

Latest Comments

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

dbermond commented on 2016-05-07 15:56 (UTC)

@danboid libmfx is just a dispatcher library for Intel QSV encoder (a library that chooses another one to do the real encoding). In order to use this encoder with ffmpeg you also need Intel Media SDK installed in the correct manner, but in Linux the installation is tricky, needing to modify the system: it requires a specific (and older) kernel version to be patched and other library modifications. It's mainly aimed at servers so Intel doesn't support current kernel versions. Unless you install Intel Media SDK in the correct manner you'll not be able to use Intel QSV encoder in ffmpeg. That's why you're getting these results. Currently, 'intel-media-sdk' doesn't provide the necessary installation procedure because it would need to modify too much the system, and that's stated in the package description: "only SDK files, no kernel patches, no system modifications". To remark this tricky situation with Intel Media SDK in Linux I marked the support as experimental in this package.

danboid commented on 2016-05-05 13:44 (UTC)

Has anybody got QSV (Intel QuickSync) h264 encoding to work using this package w/ libmpx-git? I have tried it with intel-media-sdk installed too but that didn't help. As I understand it we should be able to encode h264 (h265 and MPEG2) in hardware with this package so long as you're running it on a compat. Intel CPU and you have libmpx-git installed. intel-media-sdk shouldn't be required and that only works with a specific, patched kernel version - right? ffmpeg -i VID.mp4 -vf "transpose=1" -c:a copy -c:v h264_qsv -preset:v faster HW.mp4 Gives the error: [h264_qsv @ 0x1323680] Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode. and Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height Whilst something like: ffmpeg -i VID.mp4 -vf "transpose=1" -c:a copy -c:v h264_qsv -preset:v faster -b:v 2M -look_ahead 0 HW.mp4 Gives the error: [h264_qsv @ 0x1506c40] Error retrieving encoding parameters. Instead of the first error, whilst the second error is the same. I've so far only tried QSV encoding with ffmpeg on a i7-4700MQ but I have a Braswell-based NAS I'd like to use for video encoding too. Thanks!

dbermond commented on 2016-05-01 13:44 (UTC)

@tuankiet65 Exactly, it dramatically increases compile time. It would not be good for people that compile it daily (like me). And still, I would not mess with those toolchain options for a public PKGBUILD release, at least not at the moment, because it can cause more problems than benefits. The only one that I use from them is "--cpu=native" but only in my own buildings using a separate PKGBUILD-cpu file that I maintain internally for my use.

tuankiet65 commented on 2016-05-01 07:41 (UTC) (edited on 2016-05-01 07:55 (UTC) by tuankiet65)

How about adding --enable-lto? EDIT: probably not a good idea since LTO takes a lot of time to finish.

EndlessEden commented on 2016-01-26 09:42 (UTC)

@bermond: IMO there is a difference between being "full" and "Platform Specific". nvenc and intel_accel, are platform specific options. Not universal options(like codecs, and Generic Hardware Acceleration{vdpau}) Having those be detected is a far more fitting solution than forcing installing packages not supported on hardware. Groups: Im primarily referring to meta-packages/groups such as libva, libcl, libgl. as they allow a choice in source and dont cause conflicts. decklink: Again, more of a personal opinion then, but this does break all forms of automated build systems. flite-fpic: ive attempted to build on 3 seperate systems, only on x86(x86_32) did it compile without any issues. but it may be a package or customisation on one of these systems causing the issue. chromaprint: i rest my case on that, that does make sense. - You should consider making a static version package in this pkgbuild for people wanting to link against the repo version. libquvi: Im aware after i originally posted that. I filed a bug in the mailing list. Really wish FFMPEG would get out the dark ages when handling bugs... +libutvideo-asm-git: I always perfer choices over forced selection. That way it makes package-building more transparent between systems and updates. nvidia-sdk: "adding 'nvidia-sdk' to the system and --enable-nvenc in ffmpeg impacts nothing to people that doesn't have a NVIDIA card." | nvidia-sdk used to conflict with amdappsdk, but it doesnt anylonger. so i retract my request, on that point. But, its still not very Elegant. About ARM and cross-platform: Your package, your choice. - Just a suggestion. Intel Specific: libva-intel is no-longer conflicting with libva-mesa-driver. it used to softlink over *_drv_video.so in /usr/lib/dri/. - so ignore my previous statement. - but id suggest you offer libva-mesa-driver and libva-vdpau-driver as optionals to make it 'full' in the accelerated decoding functionality. $MAKEFLAGS: Sorry, last i knew makepkg had a 'feature'(regression) causing $MAKEFLAGS var to be ingored unless specified in the pkgbuild. to prevent compiler issues on some sources, that dont support multiple make-jobs. (Sorry i dont have a whole lot of time to keep up-to-date on arch-packages) ---- Please do not think, i am not greatful for this pkgbuild. i am, thank you for tanking the time to upload it. These are more personal concerns, cosmetic or system-universal.

dbermond commented on 2016-01-15 22:49 (UTC)

Recent commits in upstream ffmpeg git master has fixed the vulnerability. Update package by running makepkg.

dbermond commented on 2016-01-14 17:18 (UTC) (edited on 2016-01-14 17:19 (UTC) by dbermond)

The recently discovered ffmpeg vulnerability described in https://bugs.archlinux.org/task/47738 seems to be temporaly handled in the following upstream git commit: https://github.com/FFmpeg/FFmpeg/commit/7145e80b4f78cff5ed5fee04d4c4d53daaa0e077 No need to update PKGBUILD. Just update package by running makepkg.

dbermond commented on 2016-01-13 20:16 (UTC) (edited on 2016-01-14 00:26 (UTC) by dbermond)

@mnovick1988 As the name of the package suggests, this is intended to be a ffmpeg build compiled with as most enabled options as possible, hence the name "full". Having this in mind, if I put any dependency as optional this build will not be "full" anymore. That's why I putted everything in the depends array. About groups: I see no need to use groups/meta in this PKGBUILD. What do you suggest? About blackmagic-decklink-sdk: blackmagic-decklink-sdk AUR package is not broken and is not poorly writen. Please refer to my answer to your comment on its AUR page. About flite-fpic: flite-fpic AUR package is not broken. I can build, install and use it with no problems. Also, ffmpeg-full-git compiles normally with it. You must be doing something wrong. Please contact the package maintainer if you need any assistance to compile it. About chromaprint-fftw: This is something tricky. I can't use simply 'chromaprint' as a dependency because it's necessary to force linking against a chromaprint that is not the one in Arch Linux [extra] repository and not the one in chromaprint-git. The reason is as follows. Both [extra]'s chromaprint and chromaprint-git depends on 'ffmpeg'. The problem is that ffmpeg source code from the git repository has different library version numbers and API changes in comparison with [extra]'s ffmpeg (the regular version). So if you compile ffmpeg-full-git using [extra]'s chromaprint or chromaprint-git you'll get an error when trying to execute ffmpeg in command line: libavcodec.so.56 shared library not found. Why? Because ffmpeg from git provides libavcodec.so.57 and you would have linked ffmpeg-full-git against [extra]'s chromaprint (or chromaprint-git) which in turn is linked against libavcodec.so.56. So, in order to overcome this I made a chromaprint-fftw package that does not depend on ffmpeg, being thus suitable to compile ffmpeg from git without giving errors on command line. This kind of situation impacts any package that depends on 'ffmpeg'. About libquvi0.4: ffmpeg does not support libquvi API version 0.9, which is the version provided in Arch Linux [extra] repository. ffmpeg uses API from libquvi 0.4. About libutvideo-asm-git: No, I didn't mean libutvideo-git. There are two libutvideo packages in AUR now. One with ASM optimizations enabled and other without. I choosed the one with ASM optimizations enabled. libutvideo does not compile a shared library with ASM optimizations enabled, but only a static one. It's size is 455Kb and seems like nothing compared to the 10+ Mb libavcodec.so library. Since both AUR versions has "libutvideo" as a "provides" on their PKGBUILDs what I could do is change the required dependency to just 'libutvideo' so the user could choose the desired version. Not sure if it's a good idea. About nvidia-sdk: Already answered. This is a "full" ffmpeg build. And as far as I know, adding 'nvidia-sdk' to the system and --enable-nvenc in ffmpeg impacts nothing to people that doesn't have a NVIDIA card. About ARM and cross-platform: As stated on PKGBUILD the architecture of this package is for x86 systems only. According to the Arch Linux Wiki ARM is not officially supported, but only i686 and x86_64, so there is no need to provide a PKGBUILD with portability in mind. You will need to manually modify it in order to make it compile on ARM systems. About Intel specific libraries and AMD: Already answered. This is a "full" ffmpeg build. What I'm planning to do is put as optional (or remove) the 'intel-media-sdk' dependency because it's a very tricky package and seems to not work as it should do. As far as I know you can install Intel specific libraries in an AMD system with no problems. The libva-intel-driver PKGBUILD file does not have a conflicts array and thus seems to not conflict with AMD packages. Please correct me if I'm wrong. Can you please provide more information about breaks on AMD systems after installing Intel libraries? (Note: 'libva' is already included as a dependency) About $MAKEFLAGS: In order to speed up compilation by adding job options to 'make' you need to adjust your MAKEFLAGS variable in '/etc/makepkg.conf'. You should not use PKGBUILDs build() function for this. Doing this should be used only to speed _down_ compilation for specific package reasons. Please refer to the Arch Linux Wiki for more information: https://wiki.archlinux.org/index.php/makepkg

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