| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
References:
-----------
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a3deeaade32db5a1b736b8d3365e52254f3fa6ac
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=220b24c7c97dc033ceab1510549f66d0e7b52ef1
|
|
|
|
This provides a quick view of AUR dependencies.
|
|
|
|
|
|
|
|
In commit 4bbf8aa we have putted flite1 in makedepends.
Not sure if something changed upstream or if it was a mistake, but
now ffmpeg executable is linking against flite1 libraries.
Reference:
----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=4bbf8aa31abc4ff2a4cf32ad67b77581a1efb926
|
|
|
|
|
|
|
|
In short:
---------
ffmpeg-full-git can now have a fully automated build/install with AUR
helpers! This was not possible previously because some dependencies
could only be installed manually with plain makepkg, but now this is
solved. Tested and currently working with pacaur and yaourt in x86_64.
The long story:
---------------
This package has dependencies that _previously_ did not support AUR
helpers and could only be built manually by running plain makepkg:
1) blackmagic-decklink-sdk, which needed a manual source file
download from the upstream website;
2) flite1, which had problems when building with the popular yaourt
(although it could be normally built with other AUR helpers like
pacaur and packer).
As a result, ffmpeg-full-git also was not supporting AUR helpers and
could only be built manually with plain makepkg. This situation was
very sad.
Fortunately, now this is solved:
1) blackmagic-decklink-sdk as of version 10.8.3-2 does not need
manual source file download anymore and can be build with AUR
helpers;
2) flite1 was "fixed" to allow building with yaourt.
It means that everything that was preventing ffmpeg-full-git from
being used by AUR helpers is solved. Now this package can have a
fully, 100% automated build/install with AUR helpers. Tested and
currently working with pacaur and yaourt in x86_64.
packer still cannot build ffmpeg-full-git because it does not support
dependencies with architecture-specific names. I have made a pull
request in packer GitHub webpage (#156) that fixes this, and it is
waiting for the developer to merge it. One can use the patch from
this pull request in order to make packer to build ffmpeg-full-git.
This AUR git commit is just a marker. Cheers...
References:
-----------
https://aur.archlinux.org/cgit/aur.git/commit/?h=blackmagic-decklink-sdk&id=67b2558b34166f3ef448420ddaa35b74f3007aef
https://aur.archlinux.org/cgit/aur.git/commit/?h=flite1&id=5dd3596cf67ddf105834e8817cd41ac59b6e21ef
https://github.com/keenerd/packer/pull/156
|
|
It was being used due to jni which in turn was removed in a
previous git commit.
Reference:
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=3e2ed8fa639f069e252360bf4d5844d85f1a2559
|
|
configure script allows jni only if, among other things, the
'target_os' is android. There was a recent upstream git commit
that causes configure script to fail with --enable-jni if the
requirements are not met. And mediacodec requires jni on
configure script, so it fails too. At least, currently they
seem to run only on android. mediacodec was already expected
to have this behavior.
On 'configure' file, notice these (non-consecutive) lines:
enabled jni && { [ $target_os = "android" ] ...
enabled mediacodec && { enabled jni ...
Reference:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d839c4716cdcecf3b46d05d0aec8f460cdb4ce23
|
|
x11grab was removed from upstream. It was a legacy option for xlib
(libx11) users and was superseded by xcbgrab using libxcb.
Although xcbgrab is shown at configure time, x11grab still remains
as the X screen capture format name at the current moment
(currently there is no xcbgrab in 'ffmpeg -formats', but only
x11grab).
References:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4a9c5f6bc5a825f10b77f6ce084aa840d5c1d93e
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4fef648d10bf3bcfd4b8fa5755c1128966a2427c
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=f6d61eb6f95aaf3a529397f205dd61d5dc47bce0
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=5ed4644d6de7f6112431dc2d9a5cfe9a0a75a688
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2f6661c940161e97c7d5a2275e398264b171e001
|
|
In a previous AUR git commit from 2016-11-26 it was needed to change
zimg dependency to zimg-git to fix a compile error. It seems that
ffmpeg git master was (is?) using code from zimg git master. Now that
a new zimg version (v2.4) was released a while ago there is no more
compile error.
If there will be another similiar issue in the future of course we
can consider to change this again.
Reference:
https://aur.archlinux.org/cgit/aur.git/commit/?h=ffmpeg-full-git&id=8fed268043cb2c3fcbcab550c429caf4e7f0e300
|
|
Changed flite-fpic to flite1. flite-fpic uses static libraries and
flite1 uses shared ones, so flite1 is preferred.
It seems that flite is needed only at building time since it's not
linked in any binaries and namcap does not complain about it.
flite functionality in ffmpeg and ffplay works as expected when
deleting flite1 after installing ffmpeg-full-git.
Also, the flite detection code on prepare() seems to be not needed
since everything works without it.
Note: flite (2.x) that is present at [community] repository is not
supported by ffmpeg.
|
|
This will fix errors when running the configure script. These
components are only for Apple systems and does not need to be
enabled in Linux anyway.
Also removed the initial comment section about the not
available options.
The errors in configure script were caused by the following
upstream git commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=8aad209c13c2a66a9256e37d7f44b5f9f19b13b2
|
|
In short:
depends: changed from ocl-icd to opencl-icd-loader.
Moved opencl-headers to makedepends.
The long story:
This will match the approach used in PKGBUILDs from many repository
packages that depends on opencl. These packages doesn't place a
direct dependency to package ocl-icd like we were doing here, but
instead they depends on libcl or on opencl-icd-loader that is
provided by ocl-icd. Also, opencl-headers is not needed at runtime
and should be placed in makedepens.
Some examples of these packages that depends (or optdepends) on
opencl are: imagemagick, opencv and wine.
It's hard to tell for which one we should replace ocl-icd (if for
libcl or for opencl-icd-loader), since, among other things, some
repository packages points to libcl and others to
opencl-icd-loader. But recent changes in package lib32-ocl-icd and
on these repository packages that depends on opencl can maybe
suggest that pointing the 'depends' array to opencl-icd-loader is
preferred over libcl. For instance, by a recent update in
lib32-ocl-icd it no more provides lib32-libcl while ocl-icd, being
without recent updates, still does provides libcl. Another argument
is the fact that packages like imagemagick and wine recently
changed dependency from libcl to opencl-icd-loader.
References:
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/lib32-ocl-icd&id=c3211f4f1f20744432daade51bc1ac44af0a770b
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/imagemagick&id=193cd1967d79f4de07019e94cda75aaff9947a3d
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/wine&id=6ecc1ba30eef9898e29faf2d0bfc42bb03f6bd68
|
|
The following compile error occurs if using zimg release version (currently at 2.3):
libavfilter/vf_zscale.c:387:16: error: ‘ZIMG_TRANSFER_IEC_61966_2_1’ undeclared (first use in this function)
FFmpeg seems to be using code from zimg git version since using zimg-zit fix this error.
This was introduced in the following upstream git commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b96a6e2024fa2b52d6a2473a7cf16ee20a8ab5c8
When zimg releases a new version we can consider to change back this dependency.
|
|
|
|
libebur128 was removed in the following upstream git commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=005d058f4230f3207ebcf1131df7426d4f57392f
|
|
|