| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
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.
|
|
The latest upstream git master requires libXv.so, libX11.so and
libXext.so for enabling xlib. Although this requirement is
currently present only on git master, by examining the changes
it seems to make sense to add it here too.
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
|
|
|
|
|
|
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.
|
|
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
|
|
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
|
|
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&id=bc0e50657db7c6317135d1e59e02a2b5d041aac8
|
|
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.
|
|
|
|
References
----------
https://trac.ffmpeg.org/ticket/6834
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c6f84106366c6f243a8b07dbffcc7880009aa904
Also important
--------------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2ca65fc7b74444edd51d5803a2c1e05a801a6023
|
|
|
|
|
|
It should be used only to allow installing libraries in paths
not part of the dynamic linker search path.
|
|
RockChip Media Process Platform (MPP).
References
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=f3aefb3e1c3c6afeaca889d4fd2648458fd74dfe
|
|
|
|
|
|
|
|
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.html
https://www.archlinux.org/todo/pie-rebuild/
https://www.archlinux.org/todo/hardening-wrapper-removal/
|
|
|
|
Switched libmfx dependency from libmfx-git to libmfx (stable release).
Moved it to makedepends (static library).
|
|
|
|
Currently it's only needed in git master version. It will be
needed in future releases when the stable version catches
code from git master.
|