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.107057
First Submitted: 2015-12-27 19:22 (UTC)
Last Updated: 2024-10-24 20:29 (UTC)

Required by (1916)

Sources (8)

Latest Comments

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

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.

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.

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