| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
|
|
FFmpeg was having a compilation error when both openjpeg and
openjpeg2 2.1.x were installed. Have previously handled this
by an own patch and now the issue is fixed by upstream.
Fixed by upstream git commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=7a65aef00d113a38e0d1a54df49eead9df6aa15c
Upstream bug report fixed:
https://trac.ffmpeg.org/ticket/5694
|
|
libfaac was removed in the following upstream git commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=dc0f711459e0c682bf9f94ba38d26736e90cff45
|
|
FFmpeg currently doesn't support libopenjpeg 2.1.1 (libopenjp2).
Readded libopenjpeg by using a patch the enables only the
use of libopenjpeg 1.5.
|
|
FFmpeg exchanged SDL for SDL2
Upstream commits:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=3877e3d8a8bdd09f6f13b99a555d963bdb0f16f5
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=47ea6f5c9d1bb5a3a6b9429857dbd6ee32809b0e
|
|
FFmpeg bundled the nvEncodeAPI v7 SDK header file into the source code.
Now ffmpeg-full-git builds without the nvidia-sdk package, so there is
no need to have it in dependencies anymore.
This change was made by the following FFmpeg git commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=325e56479ff64c884f3bcccf922a7f7163488b89
|
|
|
|
|
|
Fixed by upstream git commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=293676c476733e81d7b596736add6cd510eb6960
Upstream bug reports fixed:
https://trac.ffmpeg.org/ticket/5417
https://github.com/cisco/openh264/issues/2505
|
|
The newly released libopenh264 1.6.0 introduced a compile error.
|
|
|
|
|
|
|
|
They really like to change it.
|
|
The newly released openjpeg2 2.1.1 introduced a compile error at
link time. ffmpeg uses openjpeg2 when both openjpeg and openjpeg2
are installed.
|
|
|
|
|
|
Compilation fixed by upstream bug report:
https://trac.ffmpeg.org/ticket/5653
|
|
|
|
|
|
and --enable-libebur128
|
|
|
|
--enable-zlib
|
|
libnpp depends on cuda, which is already included
|
|
User can choose among any supported java SDK that provides
'java-environment' (OpenJDK 7/8/..., Orcacle JDK 6/7/8/9/...).
|