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 .. 8 9 10 11 12 13 14 Next › Last »

dbermond commented on 2017-07-20 03:11 (UTC)

@SolarAquarion Clean builds can enabled by the user through makepkg -C/--cleanbuild option. Building in a separate directory is not needed by ffmpeg build system. Why are you asking this?

SolarAquarion commented on 2017-07-19 22:52 (UTC)

@dbermond can you enable clean builds, like in a seperate "build directory"

dbermond commented on 2017-04-21 14:08 (UTC)

ffmpeg-full-git can now have a fully automated build/install with AUR helpers! This was not possible previously because some dependencies could only be installed manually with plain makepkg, but now this is solved. Tested and currently working with pacaur and yaourt in x86_64. packer currently fails, being unable to solve cuda dependency (as stated in the Wiki, packer is not a reliable parser and solver). I have made a pull request in packer GitHub webpage (#156) that fixes this, and it is waiting for the developer to merge it.

dbermond commented on 2016-12-11 16:04 (UTC)

@cRaZy-bisCuiT "Installing Intel Media SDK in the correct manner" means that you need to follow the procedure described in Intel documentation, otherwise it's not correctly installed and will not work. It needs kernel patches and other system modifications. According to the documentation it seems that the latest supported kernel version for 2017 R1 is 4.4.0. The installation scripts and patches are targeted at this kernel version. Intel Media SDK is made mainly for servers and only CentOS 7.2.1511 is considered to be a "Gold" installation for version 2017 R1. Other Linux distributions and kernels are considered "Generic" installations and might not work or even need additional adjustments in scripts/patches. Installation instructions are here: https://software.intel.com/sites/default/files/media_server_studio_getting_started_guide.pdf A table on this page more directly specifies the supported kernel version: https://software.intel.com/en-us/articles/driver-support-matrix-for-media-sdk-and-opencl If you cannot see these pages then login to Intel website first. I know nothing about AMD + Intel setups.

cRaZy-bisCuiT commented on 2016-12-08 22:45 (UTC)

@Bermond: Thanks for the answer. What exactly does "Unless you install Intel Media SDK in the correct manner you'll not be able to use Intel QSV encoder in ffmpeg." mean exactly? In what kind of way? Did either you or anyone got it working so far? In addition, what would be the newest supported kernel? Do I need to follow the instructions here [0]? By the way, would it be working using AMD RX 480 for gaming and showing me the actual picture but using Intel for QuickSync? [0] http://www.intel.de/content/www/de/de/cloud-computing/quicksync-video-ffmpeg-install-valid.html

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.

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