summarylogtreecommitdiffstats
AgeCommit message (Collapse)Author
2017-10-24Temporarily disable libflite due to flite1 package issueDaniel Bermond
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/
2017-10-15cuda 9.0 rebuildDaniel Bermond
2017-10-11New upstream options: --enable-libxml2 and --enable-libdrmDaniel Bermond
2017-09-13Added Intel Media SDK plugins path for hw-accelerated QSV encodersDaniel Bermond
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.
2017-09-13Readded cuda-sdk after cuda fix for glibc 2.26Daniel Bermond
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
2017-09-09Temporarily disable cuda-sdk option due to glibc 2.26 compile errorDaniel Bermond
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
2017-09-09Removed --enable-videotoolboxDaniel Bermond
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
2017-09-03New upstream options: --enable-alsa, --enable-jack and --enable-sndioDaniel Bermond
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
2017-09-03Added note about enabling new upstream option --enable-libndi_newtekDaniel Bermond
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
2017-08-25opencv 3.3.0 rebuildDaniel Bermond
2017-08-16libvmaf 1.3.1 rebuildDaniel Bermond
2017-08-16x265 2.5 rebuildDaniel Bermond
2017-07-18libmfx 1.23 rebuildDaniel Bermond
2017-07-16New upstream option: --enable-libvmafDaniel Bermond
References: ----------- http://git.videolan.org/?p=ffmpeg.git;a=commit;h=615479d51c6a76275c114888b5600b929309f4c4 http://git.videolan.org/?p=ffmpeg.git;a=commit;h=d8f198263975f45fab1f9b44f870131abc1d6e36
2017-07-16PIE static libraries rebuild / Recent toolchain changes rebuildDaniel Bermond
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/
2017-07-11Atempt to fix FS#54758Daniel Bermond
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
2017-07-09Changed versioning methodDaniel Bermond
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).
2017-07-09Changed variables to local typeDaniel Bermond
2017-06-30depends: changed libmysofa-git to libmysofaDaniel Bermond
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
2017-06-24Added sndio supportDaniel Bermond
2017-06-24libmfx dependency changingsDaniel Bermond
Switched libmfx dependency from libmfx-git to libmfx (stable release). Moved it to makedepends (static library).
2017-06-24Updated descriptionDaniel Bermond
2017-06-21makedepends: switched yasm to nasm to follow upstream changeDaniel Bermond
Reference: ---------- http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4f9297ac3b39098547863d28fbc8d2a906d5be49
2017-06-18Fixed nvcc path assignmentDaniel Bermond
2017-06-17openh264 1.7.0 rebuildDaniel Bermond
2017-06-17Cosmetic changingsDaniel Bermond
2017-06-10Upstream option switch: --enable-netcdf to --enable-libmysofaDaniel Bermond
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
2017-06-10Changed PKGBUILD file modeDaniel Bermond
2017-06-10Cosmetic changingsDaniel Bermond
2017-06-03Updated provides and conflictsDaniel Bermond
2017-05-31license: changed to just nonfree and unredistributableDaniel Bermond
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
2017-05-31depends: cosmetic changingsDaniel Bermond
2017-05-31depends: removed libva-intel-driverDaniel Bermond
2017-05-31Fix build if package is installing cuda for the first timeDaniel Bermond
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
2017-05-31cuda_sdk: fix build in systems with nvidia-{340,304}xx-utilsDaniel Bermond
Note that both nvidia-340xx-utils and nvidia-304xx-utils provides nvidia-utils.
2017-05-31New upstream option: --enable-cuda-sdkDaniel Bermond
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
2017-05-30Removed --enable-libnut and --enable-libschroedinger (removed from upstream)Daniel Bermond
References: ----------- http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a3deeaade32db5a1b736b8d3365e52254f3fa6ac http://git.videolan.org/?p=ffmpeg.git;a=commit;h=220b24c7c97dc033ceab1510549f66d0e7b52ef1
2017-05-29New upstream option: --enable-librsvgDaniel Bermond
2017-05-29Split dependencies into official repository and AUR groupsDaniel Bermond
This provides a quick view of AUR dependencies.
2017-05-29depends: changed jack placementDaniel Bermond
2017-05-29depends: added jack and libx11Daniel Bermond
2017-05-29Changed order or dependencies to match configure scriptDaniel Bermond
2017-05-29Moved flite1 to dependsDaniel Bermond
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
2017-05-29White space and cosmetic changingsDaniel Bermond
2017-05-08libcdio-paranoia 10.2+0.94+1 rebuildDaniel Bermond
2017-04-30opencv 3.2.0-3 / libwebp 0.6.0 rebuildDaniel Bermond
2017-04-21A fully automated build/install with AUR helpers is now supportedDaniel Bermond
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
2017-03-21depends: removed java-environmentDaniel Bermond
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
2017-03-21Removed jni and mediacodec (support in ffmpeg is for android only)Daniel Bermond
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
2017-03-15Removed --enable-x11grab (removed from upstream)Daniel Bermond
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