libaom 1.0.0 was released and now upstream ffmpeg is accepting
to compile with this stable version, which was not possible with
libaom 0.1.0.
This will remove the dependency on a -git package, which is good
and desirable when possible.
opencl: opencl-icd-loader was replaced by ocl-icd. Although ocl-icd
currently provides opencl-icd-loader, let's use the newer
approach by depending directly on ocl-icd.
opengl: it seems that the best approach for depending on libGL is
to use libgl instead of mesa. Currently it is provided by
libglvnd package (or by nvidia-340xx-utils for legacy
nvidia users).
At the time of ffmpeg 4.0 release, the latest version of vmaf was
1.3.1. At that time, ffmpeg 4.0 needed vmaf git master to compile.
Now vmaf 1.3.4 was released and ffmpeg builds fine with it.
Since intel-media-sdk is needed not only for building with
Intel QSV support but also for Intel QSV to work during runtime, it
makes sense to stay in depends as a needed component. Forgot to do
it in previous commit. Another option instead of placing it only in
depends would be to place it in makedepends + optdepends because
ffmpeg runs without intel-media-sdk installed (libmfx.a is a static
dispatcher library that calls other sdk components at runtime).
Currently I'm sticking with the depends-only solution.
intel-media-sdk, the open source version of
intel-media-server-studio, has now reached an acceptable stable
release that can be used here to provide libmfx.
This brings 2 important results:
1) The experimental state can be removed from the Intel QSV
support, since intel-media-sdk also provides libmfxhw64
and plugins for hardware accelerated decode and encode.
2) Finally we can get rid of the unsecure rpath in ffmpeg
binaries!
intel-media-sdk is now a makedepend, instead of an optdepend
as previously. If fact, I should have switched it to
intel-media-server-studio in optdepends some time ago when
it has changed to the open source version, but I letted this
way while waiting for an acceptable stable release of, which
taked a while to happen.
Users should remove the libmfx{-git} package and stay only with
intel-media-sdk{-git} package, since the former is the complete
solution with the dispatcher library (libmfx.a), libmfxhw64 and
plugins.
Note1:
------
For the proper use of Intel QSV in ffmpeg the user must set the
vaapi/libva driver to 'iHD' through the 'LIBVA_DRIVER_NAME'
environment variable. The 'iHD' vaapi/libva driver is provided by
intel-media-driver{-git} package, which at the current time is
already a dependency of intel-media-sdk{-git} package. Setting
the vaapi/libva driver to 'iHD' can be done, for example, by
uncommenting the proper line in '/etc/profile.d/intel-media.sh'.
Note2:
------
intel-media-sdk is currently at a pre-release state. This can
lead to bugs when using Intel QSV.
Note3:
------
Not all Intel platforms are supported by intel-media-sdk. At the
current time, it claims to support only 5th and 6th Generation
Intel® Core™ processors (Broadwell and Skylake). For details,
please see the MediaSDK and media-driver documentation:
- https://github.com/Intel-Media-SDK/MediaSDK/
- https://github.com/intel/media-driver/
Note4:
------
Intel QSV is available in x86_64 systems only.
Also in this commit:
--------------------
- depends: moved 'libbs2b' and 'sndio' from the AUR section to
the official repositories section, since they are now at the
[community] official repository.
flite1 package has some problems that were exposed by upstream
ffmpeg git commit 6dfcbd8 (this change is still not in ffmpeg
3.4). The linking in flite1 needs to be fixed, otherwise ffmpeg
versions 3.5 and later (and the current ffmpeg git master) will
not compile, failing to detect libflite. flite1 can also have
other improvements, as follows.
flite version 1 is an old software from 2009. Since there, many
issues have been discovered, including the security issue
CVE-2014-0027. There are patches out there that addresses many of
the discovered issues, and also adds some fixes and enhancements.
I have already asked the flite1 AUR package maintainer to patch it
in order to fix these issues, but after almost five months I got
no response from him. Since I need a fixed flite1 package for AUR
package ffmpeg-full-git, I'm also adding this improved package
here at ffmpeg-full.
References:
-----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6dfcbd80ad446ff163b47f2bf432bbf706436ea8
Removed cuvid and cuda (actually named ffnvcodec on current ffmpeg
git master) from the x86_64 specific options (it can be build with
them on i686). Only cuda_sdk and libnpp seems to be x86_64 specific
(at least from the build perspective).
also on this commit:
- improved command to detect presence of nvidia-340xx-utils
- removed nvidia-304xx-utils from being searched (not maintained
anymore, was dropped from official repositories and currently
there is no AUR package for it).
- moved the nvcc path configuration to the prepare() function
- cosmetic changes
Package ndi-sdk has now an automated source download process (no
more manual source download required, at least currently).
It will be necessary to remove support for NewTek's libndi if
package ndi-sdk will break this automated source download process
in the future.
This seems to not work currently with the Intel binary version of
Media SDK. But the correct is to provide this path for ffmpeg to
try the hardware accelerated encoders before falling back to
software mode. Only software mode seems to be working currently,
and then intel-media-sdk optdepend will still remain marked as
experimental.
The recent toolchain changes (PIE and SSP enabled by default in
gcc) makes the need to rebuild packages that uses static
libraries as makedepends. A static library that is in makedepends
of ffmpeg-full have triggered a rebuild (libmfx).
Also, packages that uses hardening-wrapper will need a rebuild
without it since it is being dropped from official repositories
due to the recent toolchain changes. Although hardening-wrapper
was not being used in this package it is a good practice to
rebuild against the recent toolchain changes.
References:
-----------
https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028909.htmlhttps://www.archlinux.org/todo/pie-rebuild/https://www.archlinux.org/todo/hardening-wrapper-removal/
Daniel Bermond