Age | Commit message (Collapse) | Author |
|
Also add lto to match repository package.
|
|
|
|
rockchip-mpp was disabled[1] a while ago because the upstream
repository was temporarily set to private[2] (hidden from the
public). Now the rockchip-mpp repositry is public[3] again and
we can re-enable this feature.
References
----------
[1] https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full&id=a224acc3d9b2d35eee6100a60e3df5822d1845dd
[2] https://github.com/HermanChen/mpp/issues/15#issuecomment-690804709
[3] https://github.com/rockchip-linux/mpp/
|
|
|
|
smbclient support was previously removed[1] due to a build failure
with samba 4.9. It looks like that the recently released samba 4.13
fixed[2][3] the issue and now ffmpeg is building fine with it.
References
----------
[1] https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full&id=f12ec9acea516c773870506abae2b0e7fd2a1067
[2] https://github.com/samba-team/samba/pull/212/
[3] https://github.com/samba-team/samba/commit/1114b02a72ce0c86a5301816560d270ec47f8be3
|
|
|
|
Upstream repository for rockchip mpp is gone.
It was at: https://github.com/rockchip-linux/mpp/
I could not find any upstream word about it. The Rockchip Wiki
still points to this repository, without saying if it was really
dropped or moved to another place.
Due to this, new users now cannot build rockchip-mpp package.
Disabling it so new users can build ffmpeg-full.
|
|
|
|
|
|
cuda 11.0 minimum supported architecture is 5.2 (compute_52/sm_52).
svt-vp9 support is better now with the current upstream stable
version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's buggy at the current moment, not working properly at all.
|
|
|
|
|
|
intel-media-sdk is now installed on '/usr' prefix. No need to
specify the pkg-config search path anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Patches for intel svt components will be different at each
component release, so they better be versioned.
This commit updates intel-svt-av1 patch from version 0.5.0
to 0.6.0.
|
|
|
|
|
|
|
|
|
|
upstream ffmpeg excects[1] : /usr/include/tensorflow/
tensorflow package ships[2]: /usr/include/tensorflow/tensorflow/
References
----------
[1] https://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=a9644e211bebb342fb9066190f1be70e55f68ec0;hb=4154f8967820ca734a77ce91bb590cd77649dee8#l6138
[2] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/tensorflow&id=d6b6fa4eb56d8e6055268504d6b0110c6fddde7e
|
|
|
|
|
|
|
|
xavs2 1.3 stable was released and ffmpeg currently builds fine
with it.
|
|
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.
|
|
|
|
|
|
|
|
It requires both lv2 and lilv.
|
|
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.
|
|
|
|
-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).
|