| Age | Commit message (Collapse) | Author |
|---|
|
xavs2 1.3 stable was released and ffmpeg currently builds fine
with it.
ffmpeg git master currently requires libmysofa git master[1].
References
----------
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/4096c670abefdd361fcfd427e163088979871c6c
|
|
dav1d now has its first stable release, which at the current time
is suitable for building ffmpeg.
|
|
ffmpeg fails to compile with the newly released smbclient 4.9[1].
Currently, there is a pull request[2] at upstream samba that
aparently fixes this, but it still was not accepted at the time
of writing. It is being discussed on the samba mailing list[3].
Disabling libsmbclient until there is a consistent upstream
solution.
References
----------
[1] https://bugs.gentoo.org/666548
[2] https://github.com/samba-team/samba/pull/212/
[3] https://lists.samba.org/archive/samba-technical/2018-October/130668.html
|
|
|
|
Currently, it is now possible to build ffmpeg with the newly
released davs2 stable version.
|
|
- use https for url
- do not rename source clone
- remove the setting of nvcc path on prepare() (now handled by
makepkg)
- pkgver(): declare and assign variables separately
- new upstream options: --enable-{libdav1d,libklvanc,libxavs2}
|
|
|
|
|
|
Now davs2-git provides both CLI and library. It switched from a
split package to a single package.
References
----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=davs2&id=560a908425ed04b67cecfce9832cc8e1bece6fe2
|
|
libvmaf support was previously disabled due to an upstream compile
error. Now it is fixed by upstream.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=87cc7e8d4ef8fa643d8d4822525b9c95cc9e7307
|
|
It requires both lv2 and lilv.
|
|
Note:
--enable-libdavs2 does not work with the current stable version
of libdavs2 (v1.0). It is needed libdavs2-git.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=0ea20124b710e3f05899b2ccea9f2a00f62a76a0
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=5985a1bf72332e10d251ec643e100b5592285819
|
|
ffmpeg fails to build with the newly released vmaf 1.3.7.
Disabling vmaf support until upstream ffmpeg fixes this.
|
|
References
----------
https://www.archlinux.org/packages/extra/x86_64/aom/
|
|
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.
|
|
In order to follow the official repository package, gnutls is used
for providing https support. Upstream ffmpeg can use only one
library at configure time to provide https support, and we have
been explicitly disabling all them (except for gnutls, of course)
in previous package commits.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=62f5c9d68bf6e0f2c1a47cf002629a70a82274fc
|
|
-lpthread was previously required for building with libaom support.
Currently it seems that upstream aom git master has handled this
missing library to its linkage, and this option is not needed here
anymore.
References
----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=a57553ab08c7af23735921498c4393e320b0553b
|
|
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).
|
|
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=d8c0bbb0aa45eed61b159c4842473fe27e77ac12
|
|
Note: this creates a circular dependency between ffmpeg and
vapoursynth, which I do not consider to be a good thing when
dealing with AUR (user controlled) packages. Let's use it
since it's currently working fine.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=7074a7ccd9a4d4e445252780fd182aa0b3778b79
|
|
We previously needed to use vmaf version git master to compile,
and it was necessary to change vmaf dependency to vmaf-git.
Otherwise, a compile error would appear.
It now compiles fine with the latest vmaf stable release version
1.3.4.
References
----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=5ebce0c7d4eadc99db17b79f56053bdb02e567e7
|
|
Enabling xlib requires libXv.so, libX11.so and libXext.so.
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=0736f32a4facddbd953977ca614a3ee6d8a6e1d7
|
|
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.
|