Age | Commit message (Collapse) | Author |
|
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
|
|
|
|
|
|
|
|
Note: at the time of writing ffmpeg does not compile with the
stable release of libmysofa (v0.4). It requires code from git
master. So 'libmysofa-git' was added as the dependency.
Reference:
----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2336c76b224628f20ed0ef8a683ad602ed1739c3
|
|
|
|
|
|
|
|
Although GPL3 is present in the resuling complex license mix, it
does not seem to make sense leaving GPL3 in the license list. The
output of configure script clearly says that the resulting license
is nonfree and unredistributable, and this is what should be
clearly stated to the user.
The ffmpeg documentation says that in such cases, like we are using
here with --enable-nonfree, the resulting binaries are under a
complex and restrictive license mix. But it does not provide clear
licensing terms for such situation. So I just created a LICENSE
file and added generic notes to it which seems to better describe
this nature than the previously used UNREDISTRIBUTABLE.txt file.
Also, the presence of a LICENSE file is something more standard and
is described in the Wiki.
References:
-----------
https://github.com/FFmpeg/FFmpeg/blob/a47273c803edfbc43793349b74429ae29b05c003/configure#L101-L102
https://github.com/FFmpeg/FFmpeg/blob/a47273c803edfbc43793349b74429ae29b05c003/configure#L6554-L6555
https://github.com/FFmpeg/FFmpeg/blob/a47273c803edfbc43793349b74429ae29b05c003/LICENSE.md#incompatible-libraries
https://ffmpeg.org/pipermail/libav-user/2012-November/003179.html
|
|
|