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