| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
|
|
When installing cuda for the first time, the cuda binaries appear
on PATH only after the user do a relogin.
As a consequence, the cuda binaries will not be available if cuda
is being installed for the first time as a dependency of
ffmpeg-full-git. This can be fixed by strictly specifying the full
path of nvcc.
Reference:
----------
https://git.archlinux.org/svntogit/community.git/tree/trunk/cuda.install?h=packages/cuda
|
|
Note that both nvidia-340xx-utils and nvidia-304xx-utils provides
nvidia-utils.
|
|
In short:
---------
nvidia-utils is needed as a dependency to enable cuda_sdk features.
The long story:
---------------
ffmpeg configure script defines that cuda_sdk requires libcuda.so
(-lcuda). Two packages provides it: cuda and the nvidia-utils
family. Note that cuda provides only libcuda.so and nvidia-utils
provide the more complete set of libraries with so-version number,
in this case libcuda.so.1.
Binaries from the resulting compilation links to libcuda.so.1
even if we try to use libcuda.so from cuda package. When trying
to build using libcuda.so from cuda package, namcap gives this
warning: "Referenced library 'libcuda.so.1' is an uninstalled
dependency". As fas as I can tell, this warning is harmless, but
it should happen only for libraries provided by the package that
is been compiled (ffmpeg-full-git).
The only package providing the needed file libcuda.so.1 is the
nvidia-utils family. This library name and so-version is strictly
defined in ffmpeg source code.
Of course this can be revised in future if some other clue is
found.
References:
-----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6a3740572dfeef2628a1c54ba61e7e413bfb55f8
https://github.com/FFmpeg/FFmpeg/blob/edf686f089d68092c3b17a23cc48667665b5a069/configure#L5772
https://github.com/FFmpeg/FFmpeg/blob/edf686f089d68092c3b17a23cc48667665b5a069/compat/cuda/dynlink_loader.h#L54
|