Package Details: ffmpeg-full-git 7.1.r116781.gd89930f866-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.42
First Submitted: 2015-12-27 19:22 (UTC)
Last Updated: 2024-08-27 17:59 (UTC)

Required by (1877)

Sources (9)

Latest Comments

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

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.

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.

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