High Efficiency Video Coding (HEVC) is the latest generation video compression
standard.
* This standard was developed by the ISO/IEC Moving Picture Experts Group
(MPEG) and ITU-T Video Coding Experts Group (VCEG), through their Joint
Collaborative Team on Video Coding (JCT-VC)
* HEVC is also known as ISO/IEC 23008-2 MPEG-H Part 2 and ITU-T H.265
* HEVC provides superior video quality and up to twice the data compression
as the previous standard (H.264/MPEG-4 AVC)
* HEVC can support 8K Ultra High Definition video, with a picture size up to
8192x4320 pixels
===> The following configuration options are available for x265-4.3:
SVTHEVC=off: HEVC encoding via SVT-HEVC
VMAF=off: VMAF scores
====> Options available for the multi PIXELWIDTH: you have to choose at least one of them
HI10P=on: Enable 10-bit pixels (may break on i386)
HI12P=on: Enable 12-bit pixels (may break on i386)
HI8P=on: Enable 8-bit pixel-width (you, probably, want this)
====> Options available for the radio OPTIMIZATION: you can only select none or one of them
DEBUG=off: Enable debugging (and -O0 -g)
OPTIMIZED_FLAGS=on: Enable O3 optimization
===> Use 'make config' to modify these settings
multimedia/x265: fix build on powerpc*
A couple of fixes:
1. Altivec code also uses VSX, so it should be enabled by default only
on powerpc64le. Additionaly ENABLE_ALTIVEC needs to be specified along
with CPU_POWER8.
2. Altivec code is 64-bit only, so the option should be removed on
powerpc altogether. On powerpc64 it should stay non-default.
3. Altivec code works only with 8 bits and causes build issues
elsewhere.
multimedia/x265: fix build on powerpc, fix runtime on older powerpc64 CPUs
1. Assembly on powerpc seems to be not supported:
ld: error: undefined reference due to --no-allow-shlib-undefined:
x265::setupAssemblyPrimitives(x265::EncoderPrimitives&, int)
2. Do not optimize for POWER8, since our baseline is G5.
multimedia/x265: update to 3.6
The latest edition provides fixes for the 32-bit ARM, and drops the need
for gcc/binutils on the 64-bit ARM (aarch64). Many thanks to fuz@ for
providing remote access to the two ARM-systems.
The libvmaf-support remains broken, because our port of the dependency
has been upgraded to 3.0.0, which is only supported by x265-4.0. Not
removing this option for the sake of those, who might have kept the
older vmaf on their systems.
The ASM is no longer an option -- it was always a requirement on some
platforms, and is very useful on others.
PR: 281680
multimedia/x265: Refresh distfile
Footer in patch file x265-asm-warnings.patch now reports 2.46.1 instead
of 2.46.0 which causes a checksum mismatch
PR: 281550
Approved by: Mikhail T. <freebsd-2024@virtual-estates.net> (maintainer)
MFH: 2024Q3
multimedia/x265: fix HDR10+ support
Currently, the FreeBSD build of multimedia/x265 fails to include HDR10+
(a.k.a. HDR10plus or "dynamic HDR") support. It only includes HDR10
support (without "plus", sometimes referred to as "static HDR").
That problem also affects the ffmpeg port because it uses the x265 port
for encoding. And that, in turn, affects many other ports that use
ffmpeg or its library for encoding. In other words, the problem renders
several ports unable to produce HDR10+ video content.
There is a non-default cmake build option ENABLE_HDR10_PLUS, but the
port does not handle it correctly.
PR: 280208
Approved by: Mikhail T. <freebsd-2024@virtual-estates.net> (maintainer)
multimedia/x265: include <sys/types.h> before <md5.h>
Though it worked on some releases, where another header quietly
drags-in the types.h, it was broken on FreeBSD-12.x.
Suggested by: John Hein
PR: 274526
multimedia/x265: remove explicit setting of -DNDEBUG
Looks like CMake sets this automatically now, making our own
setting redundant.
Prodded by: diizzy
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 )
multimedia: remove 'Created by' lines
A big Thank You to the original contributors of these ports:
* Aaron LI <aly@aaronly.me>
* Alexander Botero-Lowry <alexbl@FreeBSD.org>
* Alexander Logvinov <ports@logvinov.com>
* Alexey Dokuchaev <danfe@FreeBSD.org>
* Anders Nordby <anders@FreeBSD.org>
* Andrew Pantyukhin <infofarmer@FreeBSD.org>
* Andrew Thompson <andy@fud.org.nz>
* Andrew Thompson <thompsa@FreeBSD.org>
* Angel Carpintero <ack@telefonica.net>
* Anish Mistry (with help from mean)
* Anonymous <swell.k@gmail.com>
(Only the first 15 lines of the commit message are shown above )
multimedia/vmaf: unbreak legacy API consumers after 1868dedecc9a
$ aomenc --tune=vmaf --output=foo.mp4 foo.y4m
Pass 1/2 frame 1/0 0B 0 us 0.00 fpm [ETA unknown] libvmaf
ERROR could not read model from path: "/usr/local/share/model/vmaf_v0.6.1.json"
Fatal error: Failed to load VMAF model.
$ ffmpeg -i foo.y4m -i bar.y4m -lavfi libvmaf -f null -
[...]
libvmaf INFO `compute_vmaf()` is deprecated and will be removed in a future
libvmaf version
libvmaf ERROR could not read model from path:
"/usr/local/share/model/vmaf_v0.6.1.pkl"
libvmaf ERROR support for pkl model files has been removed, use json
libvmaf ERROR problem loading model file: /usr/local/share/model/vmaf_v0.6.1.pkl
[Parsed_libvmaf_0 @ 0x8061b3b40] libvmaf encountered an error, check log for
details
While we were testing the new code, upstream have removed the 3.4
release from download area. Change our port to download using
Bitbucket's method.
Although the upstream branch Release_3.4 is very similar to what
used to be available as 3.4, there are a few improvements -- in
particular, one of our patches is no longer necessary, which is
nice.
PR: 247035
Reported by: John Kennedy, Tomoaki AOKI
Sponsored by: United Marsupials
Be sure, PIC is enabled for all builds. Upstream was turning
it on on amd64 automatically, and on i386 it was not necessary,
but our other platforms broke.
Reported by: jbeich
My usage of -fuse-ld=lld has hidden a linking problem reported
by several people. Rework for the default linker to work as well.
Also, fix the build on i386, where use of assembler code needs
to be disabled for pixel-widths other than 8.
PR: 238773
Reported by: VVD, Alan Valentine, kib@, jbeich@
Actually enable all of the user-selected bit-widths. Previously
we were building only for the highest-selected value.
PR: multimedia/x265
Submitted by: Jamie Landeg-Jones
multimedia/vmaf: add new port
VMAF is a perceptual video quality assessment algorithm developed by
Netflix. VMAF Development Kit (VDK) is a software package that
contains the VMAF algorithm implementation, as well as a set of tools
that allows a user to train and test a custom VMAF model.
https://github.com/Netflix/vmaf
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
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
multimedia/x265: add -znotext to LDFLAGS on i386, for lld
This port links some non-PIC code, which fails with lld as it defaults
to disallowing relocations against read-only segments. For i386 we can
just add -znotext unconditionally: for GNU BFD ld it just affirms BFD's
existing default.
Approved by: portmgr (lld blanket)
Sponsored by: The FreeBSD Foundation
Fix the underlying problem in the code, which previously
required disabling AVX as a work-around:
PR: 229788
Submitted by: dim@
Also, switch the build-dependency from yasm to nasm -- upstream
made the switch in version 2.6
Reported by: Callum Aitchison
Bump PORTREVISION...
multimedia/x265: unbreak on non-x86 archs after r474814
common/param.cpp:636:24: error: no matching function for call to 'parseCpuName'
p->cpuid = parseCpuName(value, bError);
^~~~~~~~~~~~
common/param.h:36:7: note: candidate function not viable: requires 3 arguments,
but 2 were provided
int parseCpuName(const char *value, bool& bError, bool bEnableavx512);
^
Approved by: portmgr blanket (unblock ffmpeg consumers)
Upgrade x265 from 2.6 to 2.8 and:
. Explicitly disable use of AVX with clang (see patch for links)
. Put non-SSL sources back on the list of MASTER_SITES
Bump PORTREVISION in the depending ports as appropriate.
- Add back CMAKE_ARGS=-DENABLE_PIC=on to fix port on arm achitectures.
- Bump PORTREVISION since this influences binaries on other archs too.
Reported by: mmel
ake advatnage of USES=compiler:c++14-lang instead of forcing clang
5.0 usage.
This should play better with non intel architectures we support.
Suggested by: jbeich@ (Thanks)
- Update multimedia/x265 to 2.6
- Use the distfile provided by the VideoLAN project
- Add options for HI10P and HI12P (available only for amd64)
- Add DEBUG option
- Add OPTIMIZED_CFLAGS option
- Force using clang 5.0 on 10.4. Base provided clang fails during
compilation
- Chase shlib bump in dependent ports
PR: 225431
Submitted by: daniel.engberg.lists@pyret.net
Approved by: Maintainer timeout
multimedia/x265: unbreak on aarch64[1] and mips
/usr/bin/ld: common/CMakeFiles/common.dir/common.cpp.o: relocation
R_AARCH64_ADR_PREL_PG_HI21 against external symbol `__stderrp@@FBSD_1.0' can not
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: common/CMakeFiles/common.dir/common.cpp.o(.text+0x1e0):
unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol
`__stderrp@@FBSD_1.0'
/usr/bin/ld: final link failed: Bad value
/usr/bin/ld: x265: hidden symbol `__sync_fetch_and_add_4' in
/usr/lib/libgcc.a(stdatomic.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
PR: 216473 [1]
Reported by: pkg-fallout
Submitted by: mikael.urankar@gmail.com [1]
Approved by: portmgr blanket
Upgrade x265 from 1.8 to 1.9. Add the test-target to utilize upstream's bundled
tests and make myself the maintainer to deal with fallout, if any.
Bump PORTREVISION of the two other ports, which depend on x265 by default.
PR: 206864
Add multimedia/x265, the H.265/High Efficiency Video Coding (HEVC) codec.
High Efficiency Video Coding (HEVC) is the latest generation video compression
standard.
* This standard was developed by the ISO/IEC Moving Picture Experts Group
(MPEG) and ITU-T Video Coding Experts Group (VCEG), through their Joint
Collaborative Team on Video Coding (JCT-VC)
* HEVC is also known as ISO/IEC 23008-2 MPEG-H Part 2 and ITU-T H.265
* HEVC provides superior video quality and up to twice the data compression
as the previous standard (H.264/MPEG-4 AVC)
* HEVC can support 8K Ultra High Definition video, with a picture size up to
8192x4320 pixels
WWW: http://www.x265.org
