x264 is a free library for encoding H.264/AVC (aka MPEG-4 Part 10)
video streams.
Encoder features
* CAVLC/CABAC
* Multi-references
* Intra: all modes (4x4 and 16x16 with all predictions)
* Inter P: all partitions (from 16x16 down to 4x4)
* Inter B: partitions from 16x16 down to 8x8 (including SKIP/DIRECT)
* Ratecontrol: constant quantizer, constant bitrate, or multipass ABR
* Scene cut detection
===> The following configuration options are available for x264-0.165.3223_1:
BASH=on: Install programmable completions for Bash
FFMS=on: FFmpeg Source input support
LAVF=on: libav* format input support (requires FFmpeg)
SWSCALE=on: Resize video filter
====> MPEG-4 output: you can only select none or one of them
LSMASH=on: L-SMASH library support
===> Use 'make config' to modify these settings
multimedia/*x264: Update to 0.165.3223 and transfer maintainership
* Switch to GStreamer's meson branch as it simplifies builds and is
faster
* Transfer maintainership to multimedia
* Remove DEBUG, GPAC, OPENCL and PGO options
By switching to Meson we can utilize the framework for debug builds
GPAC is broken upstream
OPENCL (lookahead) has very little advantage now that core count for
CPUs are much higher than a decade ago and with x264's limited
parallelization. It's also much simplier than x264's other code paths.
PGO pulls in GCC with no to little benefit
* Add LTO and OPTIMIZED_CFLAGS options
Available only on aarch64 and amd64, enabled by default
Reviewed by: bofh (previous iteration and discussed on Matrix)
multimedia/*: Update dependencies to reflect gpac-libgpac rename
Update consumer ports to use multimedia/gpac following the consolidation and
renaming of the library port.
Sponsored by: Netflix
all: drop support for FreeBSD 13.2 which reached EOL today
Thanks again to jbeich for noticing various things I overlooked.
Reviewed by: acm, ashish, eduardo, ehaupt, eugen, jbeich, martymac, mat,
nobukata, sunpoet, tagattie, yuri, arrowd, kde
Differential Revision: https://reviews.freebsd.org/D45141
*/*: Fix build with llvm16 on 13.2-STABLE
As like as HEAD(14.0-RELEASE) llvm16 was merged in base for 13.2-STABLE
with the OSVERSION 1302507.
- Utilize USE_CXXSTD=c++14 or similar solution where applicable
- Update conditionals to addtionally check for OSVERSION greater than
1302507 and less than 1400000
Approved by: portmgr (blanket)
Sponsored by: The FreeBSD Foundation
bsd.sites.mk: Update all ports using USE_GITLAB
Replace GL_COMMIT by GL_TAGNAME in all ports. The new GL_TAGNAME is
backwards-compatible (accepting any commit hash as before), but also
understands an actual tag name. Moving to tag names where appropriate is
left to individual ports' maintainers.
Approved by: portmgr (tcberner, mentor)
Differential Revision: https://reviews.freebsd.org/D37077
Remove WWW entries moved into port Makefiles
Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.
This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.
Approved by: portmgr (tcberner)
Add WWW entries to port Makefiles
It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.
Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.
There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.
(Only the first 15 lines of the commit message are shown above )
*/*: Replace USE_GCC=any with USE_GCC=yes
USE_GCC=any has been equivalent to USE_GCC=yes in most cases (such
as i386 and amd64 since 12.x and depending on configuration 11.x,
most newer installations on other platforms, and 13.x across the
board).
Since commit 96c17633d90386b5bcf8 Mk/bsd.gcc.mk is treating them as
different spellings of the same, so continue the deorbiting of the
USE_GCC=any form and simply replace it with USE_GCC=yes.
This should not make any functional difference at all.
Discussed with: mat, linimon, pkubaj
Regenerate all distfiles using gitlab as source.
This regeneration is required as the new gitlab version changed
the address and the directory the source files can be downloaded.
This commit also applies some small fixes to make sure all ports using
gitlab are buildable.
Reviewed by: mat
Approved by: portmgr
Differential Revision: https://reviews.freebsd.org/D29628
multimedia/{lib,}x264: return to building with clang on powerpc64 elfv2
Head r359981 and r359994 reverted commits that caused clang to run in infinite
loop, allocating all available memory and crashing the system.
multimedia/x264: fix build on powerpc64 elfv2
Clang has the same problem with x264 that happened with security/nss (workaround
in r528305).
It takes all available memory due to infinite loop. Switch to GCC for now to fix
build.
multimedia/x264 - use base compiler on powerpc* when using clang
Switch powerpc platforms to USES=compiler:c11. This will make them use base
clang when it's available.
Submitted by: Alfredo Dal'Ava Junior
Reviewed by: koobs (maintainer)
Differential Revision: https://reviews.freebsd.org/D22688
Bump PORTREVISION for ports depending on the canonical version of GCC
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
New libx264 releases now seem to detect and use Altivec during
compilation, which breaks with base GCC because it doesn't support
some functions that libx264 uses.
Set GCC option by default for powerpc and powerpc64.
PR: 236679
Submitted by: Piotr Kubaj
Approved by: portmgr (tier-2 blanket)
Bump PORTREVISION for ports depending on the canonical version of GCC
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
Bump PORTREVISION for ports depending on the canonical version of GCC
in the ports tree (via Mk/bsd.default-versions.mk and lang/gcc) which
has now moved from GCC 6 to GCC 7 by default.
This includes ports
- featuring USE_GCC=yes or USE_GCC=any,
- featuring USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and those
- with USES=compiler specifying one of openmp, nestedfct, c11, c++0x,
c++11-lib, c++11-lang, c++14-lang, c++17-lang, or gcc-c++11-lib.
PR: 222542
multimedia/x264: enable FFMS, LAVF, SWSCALE by default
Without FFmpeg-based demuxers x264 CLI can only read raw formats as
source. So, enable more options to allow the binary package not only
write but also read mp4/mkv.
PR: 220694
Approved by: koobs (maintainer)
MFH: 2017Q3 (usability improvement)
Differential Revision: https://reviews.freebsd.org/D11566
multimedia/x264: yasm is only used by libx264, so move ASM option there
PR: 220694
Approved by: koobs (maintainer)
MFH: 2017Q3 (minor build optimization)
Differential Revision: https://reviews.freebsd.org/D11566
Bump PORTREVISIONs for ports depending on the canonical version of GCC and
lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some
circumstances such as versions of FreeBSD or platforms).
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using using Mk/bsd.octave.mk which in turn has USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang,
c++11-lang, c++0x, c11, or gcc-c++11-lib.
PR: 216707
Bump PORTREVISIONS for ports depending on the canonical version of GCC and
lang/gcc which have moved from GCC 4.8.5 to GCC 4.9.4 (at least under some
circumstances such as versions of FreeBSD or platforms).
In particular that is ports with USE_GCC=yes, USE_GCC=any, or one of
gcc-c++11-lib, openmp, nestedfct, c++11-lib as well as c++14-lang,
c++11-lang, c++0x, c11 requested via USES=compiler.
multimedia/{lib,}x264: unbreak ASM on mips* after r422672
ASM=on is nop on many Tier2 and Tier3 architectures: arm + armeb, mips +
mipsel, ia64, sparc64. mips64 may be able to use MSA optimizations but the
ancient GCC in base doesn't support -msa flag and lang/gcc* are broken.
arm (aka armv4t) failed as:
You specified a pre-ARMv6 or Thumb-1 CPU in your CFLAGS.
If you really want to run on such a CPU, configure with --disable-asm.
mips (o32) failed as: [1]
You specified a pre-MSA CPU in your CFLAGS.
If you really want to run on such a CPU, configure with --disable-asm.
PR: 213443
Reported by: pkg-fallout [1]
Obtained from: PkgSrc
Approved by: portmgr blanket
multimedia/x264: add OPENCL option, enabled by default
Before OpenCL can be used for lookahead install at least one
implementation: devel/freeocl, devel/pocl, lang/beignet or lang/clover.
$ x264 --fullhelp | fgrep opencl
--opencl Enable use of OpenCL
--opencl-clbin <string> Specify path of compiled OpenCL kernel cache
--opencl-device <integer> Specify OpenCL device ordinal
where the options also work in other apps e.g.,
$ ffmpeg -i <input-file> -codec:v libx264 -x264opts opencl:opencl-device=1
<output-file>
$ mpv --ovc libx264 --ovcopts-add x264opts=opencl:opencl-device=1 -o
<output-file> <input-file>
Differential Revision: https://reviews.freebsd.org/D7958
Approved by: koobs (maintainer)
multimedia/x264: don't require SSE on i386 with ASM=on (default)
Remove "-march=i686 -mfpmath=sse -msse" and "-msse2" on later versions
when building C files. This doesn't affect hand-written assembly which
relies on CPUID but may pessimize compiler (around 2.3 % on Skylake).
Differential Revision: https://reviews.freebsd.org/D7958
Approved by: koobs (maintainer)
multimedia/{,lib}x264: modernize
- Convert to option helpers
- Convert to USES=localbase + respect CPPFLAGS
- Convert to USES=shebangfix (can be zsh->bash symlink)
- Simplify SLAVE_PORT conditionals into ?=, += and !target()
- Drop unnecessary `cd` before PGO sample
- Drop no longer necessary .include <bsd.port.options.mk>
Approved by: koobs (maintainer, via private mail)
Differential Revision: https://reviews.freebsd.org/D5862
Fix x264 on AArch64. quant-a.S and deblock-a.S have syntax the LLVM
assembler complains about. Pull in two upstream changes to fix these until
they are on the stable branch.
Without these these ports fail to build on AArch64.
Approved by: koobs
Differential Revision: https://reviews.freebsd.org/D4781
multimedia/libx264: Move libx264 stdin.h patch to x264 port
Move the libx264 patch for stdint.h handling on FreeBSD to the multimedia/x264
port, as FILESDIR is inherited from there, thus causing the patch not to be
applied.
Reported by: kwm
Reviewed by: kwm
Tested by: kwm
Differential Revision: https://reviews.freebsd.org/D3168
multimedia/{lib}x264: Fix distinfo's
Delete distinfo from libx264 since it is s now subordinate to the x264 port.
Also correctly update distinfo for x264, including the example.y4m.bz2 video
file for profile guided optimization (OPTION: PGO).
PR: 201260
Reported by: Ajtim <lumiwa gmail com> (via email)
multimedia/{lib}x264: Update to 0.144.2533 and major refactor
- Update to 0.144.2533 (from upstream stable branch) [1]
- Switch x264 and libx264 ports to master/slave ports respectively
- Bump PORTREVISION for dependent ports as the shared library version
has changed.
multimedia/x264:
- Clean up and update "updating instructions" in Makefile header
- Tweak COMMENT
- Only LIB_DEPENDS on libx264 and add PLIST_FILES if this isn't the
libx264 port.
- Allow COMMENT, USES, OPTIONS_*, CONFIGURE_ARGS to be overriden in
libx264 port.
(Only the first 15 lines of the commit message are shown above )
multimedia/{lib}x264: Update minimum yasm version
Update the minimum version of yasm required in BUILD_DEPENDS.
PR: 196991
Submitted by: takefu airport.fm
multimedia/x264: Use libx264's config headers
An encoding error condition is created when HI10P is enabled
in libx264, since the x264 is not built with that options.
Make x264 use the headers provided by the libx264 port, not the ones
that come with the sources, so the configuration options between the
two ports (libx264 and x264) can't end up mismatched.
Thanks to astrodog and a_b (IRC) for coming up with an elegant solution. [1]
While I'm here:
- Update COMMENT to reflect this is just the x264 CLI frontend
- Add LICENSE_FILE
(Only the first 15 lines of the commit message are shown above )
- Remove options' descriptions which are already in the standard pool
- Improve wording and make sure they all fit nicely in 80-char window
Approved by: maintainer (koobs)
multimedia/x264: General overhaul
- Split x264 into two ports: the CLI application (x264), and the library
(libx264). This will allow x264 to use lavf and friends from ffmpeg for
decoding and demuxing while preventing a circular dependency between the
two: x264 can depend on ffmpeg, but ffmpeg will depend on libx264 rather
than x264.
- Add the LAVF option to the CLI port, making the dependency on ffmpeg
optional.
- Update to 0.142.2455.
- Amend fixes to local patches so that they can apply to the new upstream
files.
- Provide the git revision and other version information to the build
environment, allowing the CLI binary to display this information (like the
Windows builds).
- Remove unsupported build options (X11_OUTPUT).
- Ensure that the library and CLI ports each have the appropriate options.
- Add notes for future contributors who wish to update the ports.
- Bump PORTREVISION for all dependent ports.
PR: 187805
Differential Revision: https://reviews.freebsd.org/D1159
Submitted by: Andrew Berg <aberg010@my.hennepintech.edu>
Approved by: koobs (maintainer, mentor)
Prevent x264 to link to ffmpeg if ffmpeg is already installed on the system
which will lead to a circular dependencies which is revealed by pkg autodeps
functionnality
Reported by: kwm
multimedia/x264: Turn HI10P option off by default.
Inadvertently left the new HI10P option included in OPTIONS_DEFAULT in the
last commit while I was testing. Remove it.
PR: ports/186138
Submitted by: Anton Sayetsky <vsjcfm@gmail.com>
multimedia/x264: Remove PGO as a default OPTION, Big cleanup.
- Remove PGO as a default option, because RESTRICTED DISTFILES is
causing >500 package builds to be skipped/ignored. I've found a
number of more liberally licensed test sequences that can be used
in a future update.
- Bump PORTREVISION
While I'm here:
- Rename GCC44 option to GCC (4.4 is no longer the default)
- Split out GCC and ASM options, allowing a user to select to use
a modern GCC version, and continue to opt-in-or-out of ASM
optimizations for performance comparisons, benchmarks or the like.
- Honour WITH_DEBUG from make.conf in DEBUG option
(Only the first 15 lines of the commit message are shown above )
Replace USE_GCC=4.6+ and USE_GCC=4.4+ by USE_GCC=yes.
Right now this is a noop in the former case and a noop in the latter
case unless lang/gcc44 has been installed explicitly.
This puts a bit more emphasis on standardizing on a canonical version
"current" GCC and makes it easier to update that canonical version
by changing the default in Mk/bsd.gcc.mk and updating the lang/gcc port.
That is, USE_GCC=yes means "use a decent/modern version of GCC" without
having to worry about details.
Approved by: portmgr (bdrewery)
Attempt to force this port to build only with gcc. It is known to be
broken on clang.
However, setting USE_GCC=any appears to be insufficient: the too-clever
configure glop sees that clang is installed and attempts to use it
regardless.
This commit is thus a temporary measure.
Hat: portmgr
Number of commits found: 200 (showing only 100 on this page)
