| Age | Commit message (Collapse) | Author |
|---|
|
nvidia-utils is now a dependency for cuda, so we do not need to
specify it here anymore.
Although I prefer to explicitly list dependencies, nvidia-utils is
a cuda component because it provides 'libcuda.so.1'. So it makes
sense to let it only with cuda.
References
----------
https://bugs.archlinux.org/task/58408
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/cuda&id=b9d76ab707c8deb25cd9734e99e15e965f05f570
|
|
Also on this commit:
- Cosmetic changes: place prepare() before pkgver()
|
|
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.
|
|
Note
----
Currently, using -lpthread is needed for compiling with libaom.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c438899a706422b8362a13714580e988be4d638b
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a2fc8dbae85339d1b418d296f2982b6c04c53c57
|
|
There is a know upstream ffmpeg compile error when enabling
libopencv. It should compile opencv code in C++ mode but it
is compiling in C mode. Disabling libopencv support while a
fix is not provided either by upstream ffmpeg or by opencv
repository package.
References:
-----------
http://trac.ffmpeg.org/ticket/7059
https://github.com/opencv/opencv/issues/10963
https://bugs.archlinux.org/task/57811
|
|
libflite was temporarily disabled in ffmpeg-full-git by a previous
commit due to an issue in AUR package flite1 that was exposed by
upstream ffmpeg git commit 6dfcbd8. The linking in AUR package
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. Now I think that it's more than the time to
readd the --enable-libflite option by using the fixed AUR
flite1-patched package.
References:
-----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6dfcbd80ad446ff163b47f2bf432bbf706436ea8
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=5fa7781fe4fe6e074af0eb34b24b0279efb2e94d
|
|
Previous commit was missing this build options part.
References:
-----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=80181d111a0a7c0045007627dd68d0da610eba48
|
|
It seems that vmaf needs x86_64. As a result, i686 builds will
not have libvmaf enabled.
References:
-----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=vmaf-git&id=6b0252294ad37c2435622a4ba31e5b5af33b2f2f
|
|
Removed cuvid and ffnvcodec 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:
- pkgver(): switched cut command to awk
- 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 a prepare() function
- cosmetic changes
|
|
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=5787908e8c63bcb9206a59961031bdb54682ab0a
|
|
Upstream ffmpeg stopped to provide the nvidia headers on their
internal source tree. Now they require it to be installed as an
external separated package.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=27cbbbb33f259de7c795d2b75edf7b240f0f82e6
|
|
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=f958f431eced497f42220d8f9890506215742512
|
|
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.
|
|
|
|
A while ago it was needed zimg version git master to compile,
and it was necessary to change zimg dependency to zimg-git.
Otherwise, a compile error would appear.
It now compiles fine with the latest zimg stable release version
2.7.3 from the official repositories.
References
----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=55f217543e8d37587f280b7193a13bfcc41b7328
|
|
Also, explicitly added --disable-libtls.
|
|
ffmpeg git master currently requires libvmaf git master to compile.
Currently it does not compile with libvmaf stable release version.
As soon as ffmpeg compiles with libvmaf stable release version it
will be switched back to libvmaf dependency.
|
|
ffmpeg git master currently requires zimg git master to compile.
Currently it does not compile with zimg stable release version.
As soon as ffmpeg compiles with zimg stable release version it
will be switched back to zimg dependency.
|
|
|
|
It should be used only to allow installing libraries in paths
not part of the dynamic linker search path.
|
|
gnutls and openssl cannot be used together anymore. Otherwise,
configure script will fail with the following message:
"GnuTLS and OpenSSL must not be enabled at the same time"
Now it's necessary to use only one of them.
Quote directly from ffmpeg upstream commit that originated this:
"Both libraries provide similar functionality and cannot be used
together. When both are enabled one is used and the other ignored
arbitrarily. Error out instead and have the user choose which
library to use."
Since ffmpeg from Arch official repositories uses gnutls, let's
stick with it.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4600b0619afc58b58de1a21d7a2c472e0d788282
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=ed434be106a4615e0419b3ac7664220741afda2d
|
|
RockChip Media Process Platform (MPP).
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=f3aefb3e1c3c6afeaca889d4fd2648458fd74dfe
|
|
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a2a7b02fbd9d96ff12280cfa03bbce6b8c797932
|
|
flite1 package has some problems that were exposed by upstream
ffmpeg git commit 6dfcbd8. The linking in flite1 needs to be
fixed, otherwise ffmpeg git master will not compile, failing
to detect libflite.
I have already asked the flite1 package maintainer to patch it
in order to fix the issue, also pointing the directions. Until
this moment I got no response from him, but let's give some
more time to see if he fixes it, at least one month counting
from my request.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6dfcbd80ad446ff163b47f2bf432bbf706436ea8
https://aur.archlinux.org/packages/flite1/
|
|
|
|
|
|
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.
|
|
References
----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=f37bcddcbca31ed3b2be95e2cfa422f2e2f5b4d9
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/cuda&id=ae90e4d243510e9565e66e9e8e08c509f5719fe0
https://bugs.archlinux.org/task/55580
|
|
The newly released glibc 2.26 is currently producing a compile
error with vf_scale_cuda. Disabling cuda_sdk makes it to build
fine. This option will be enabled again when there is an upstream
fix.
References
----------
https://trac.ffmpeg.org/ticket/6648
|
|
This option is Apple (MacOSX) specific. Recent upstream changes
makes the build to fail when using it on Linux.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=260ea7a7b395891b12eeddbd9042e0a4d3c72db9
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1cf23e3fddd1a804281b9ffc1b80c62151a46753
|
|
ALSA, JACK and sndio audio backends were already enabled in the
build. These new upstream options now only makes a strict
specification of them.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b447629093d75f18d0a8fc44ec768022322b2182
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b7fbb3516a99ebfa511143bdd8f63d8bd0d89385
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e090e750bac863f066515cff6fd363c157ea3c21
|
|
This instructs the user on how to enable support for the new
upstream option '--enable-libndi_newtek'.
Unfortunately, the package 'ndi-sdk' needs registration at the
upstream webiste and manual download to be built. This breaks
ffmpeg-full-git automated builds by AUR helpers. In this way,
libndi support in ffmpeg-full-git should be manually enabled by
the user too.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2634927fe30ea4a821db515c6b7f77458f5c4bc5
|
|
|
|
|
|
|
|
|
|
References:
-----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=615479d51c6a76275c114888b5600b929309f4c4
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=d8f198263975f45fab1f9b44f870131abc1d6e36
|
|
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-git 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. The ffmpeg from oficial
repositories uses hardening-wrapper. Although hardening-wrapper
was not being used in ffmpeg-full-git, it seems a good practice
to rebuild against the recent toolchain changes.
References:
-----------
https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028909.html
https://www.archlinux.org/todo/pie-rebuild/
https://www.archlinux.org/todo/hardening-wrapper-removal/
|
|
This commit in attempt to fix the issue described in bug report
FS#54758 (optdepends are displayed in red in some AUR packages).
A commit seems necessary to regenerate the AUR database.
References:
-----------
https://bugs.archlinux.org/task/54758
https://bbs.archlinux.org/viewtopic.php?id=228091
|
|
Now using the recommended Arch Linux Wiki method, showing
'RELEASE.rREVISION.gSHORTHASH'. Please note that, despite this
change, the package revision number will still match the FFmpeg
internal git versioning (the package revision number will match
the revision number that is displayed at the ffmpeg command line).
|
|
|
|
When libmysofa dependency was added (--enable-libmysofa), ffmpeg
was not compiling with the stable version of libmysofa and
required code from libmysofa git master. Now it is building fine
with libmysofa stable version.
Reference:
----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=8308c335dc46aa7837086485d213f03aa5393550
|
|
|
|
Switched libmfx dependency from libmfx-git to libmfx (stable release).
Moved it to makedepends (static library).
|
|
|
|
Reference:
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4f9297ac3b39098547863d28fbc8d2a906d5be49
|
|
|
|
|
|
|