x265 HEVC Encoder

[benwaggoner]

Originally Posted by qyot27

Copied straight from the instructions I drew up for the build I posted before:

Install CMake and Ninja from either Homebrew or MacPorts or however you prefer.

...

Awesome, thank you! I put that all in a .sh and ran it.

It does the big hard parts by downloading the git and does a lot of cmake, with a lot of version warnings, but still fails, as the /lib/ folder isn't getting made so there's nothing to link from it.

These are the first instances of potentially relevant warnings/errors:

CMake version complaints:
CMake Warning (dev) at CMakeLists.txt:19 (project):
cmake_minimum_required() should be called prior to this top-level project()
call. Please see the cmake-commands(7) manual for usage documentation of
both commands.
This warning is for project developers. Use -Wno-dev to suppress it.

Does this need NUMA for some reason?
CMake Warning (dev) at /opt/local/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to `find_package_handle_standard_args` (NUMA) does
not match the name of the calling package (Numa). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/FindNuma.cmake:43 (find_package_handle_standard_args)
CMakeLists.txt:115 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

And a Nasm error. I confirmed it was installed with home-brew:
"CMake Warning (dev) at /opt/local/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to `find_package_handle_standard_args` (nasm) does
not match the name of the calling package (Nasm). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/FindNasm.cmake:23 (find_package_handle_standard_args)
CMakeLists.txt:415 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it."

And where it finally fails. I confirmed that the /lib/ folder has not been created. I tried running with sudo which didn't change anything.
-- Performing Test CC_HAS_STACK_REALIGN
-- Performing Test CC_HAS_STACK_REALIGN - Success
-- GIT_EXECUTABLE /usr/bin/git
-- GIT LIVE REPO VERSION RETRIEVED
-- X265 RELEASE VERSION 3.6+34-0dfbe6dee
-- Detected CXX compiler using -O3 optimization level
-- The ASM compiler identification is AppleClang
-- Found assembler: /Library/Developer/CommandLineTools/usr/bin/cc
-- Looking for strtok_r
-- Looking for strtok_r - found
-- Looking for include file getopt.h
-- Looking for include file getopt.h - found
-- Configuring done (2.2s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/benwagg/x265_macos_arm_build/x265_git/source/x265-build/8bit
ninja: error: '/Users/benwagg/x265_macos_arm_build/x265_git/lib/libx265_main10.a', needed by 'x265', missing and no known rule to make it

I'm also attaching the full console output as a .rtf.zip

Any suggestions?

[qyot27]

Oh yeah, that's because the instructions I copied from also included building obuparse, L-SMASH, and AviSynth+ for x265-Yuuki, and those would have created that set of install directories before running the cp operation on the 12bit and 10bit runs. I simply forgot about that when I opted not to copy those parts over.

git clone https://bitbucket.com/multicoreware/x265_git && \
cd x265_git && \
mkdir -p source/x265-build/{12bit,10bit,8bit}

should be

git clone https://bitbucket.com/multicoreware/x265_git && \
cd x265_git && \
mkdir -p source/x265-build/{12bit,10bit,8bit} && \
mkdir -p $HOME/x265_macos_arm_build/x265_git/lib

(technically, you could combine both mkdir commands into one, but this way it's clearer that it's creating a second directory in a different location)


Considering nasm is explicitly for x86(-64) assembly, it's not relevant on ARM. It probably shouldn't even be checking for it once it knows it's building for AArch64.

[FranceBB]

Originally Posted by jpsdr

If i understand properly, the code is included in the build automaticaly, but you have to activate/select it when running x265, is it correct ?

Yep. Correct.

[Boulder]

Does anyone know if the -12 limit for chroma offsets is just "a number" or would it hurt to extend the range? As we know, x265 sometimes tends to mangle chroma quite a lot even with the largest possible negative offset so it would be interesting to test a bigger value. With svt-av1, I noticed that it requires offsets like -32 to allow the chroma enough bits. Of course, different encoders and probably a different approach, but goes to show that sometimes insanely high (or low ) values might be needed.

[rwill]

Originally Posted by Boulder

Does anyone know if the -12 limit for chroma offsets is just "a number" or would it hurt to extend the range? As we know, x265 sometimes tends to mangle chroma quite a lot even with the largest possible negative offset so it would be interesting to test a bigger value. With svt-av1, I noticed that it requires offsets like -32 to allow the chroma enough bits. Of course, different encoders and probably a different approach, but goes to show that sometimes insanely high (or low ) values might be needed.

A cb/cr offset outside of the range +/- 12 is invalid.

I would also like to note that -12 already means around 2 more bits precision in comparison to luma quantization, which is quite a lot.

[Emulgator]

Ah, that coincides well with my findings: wanting to set x265 UHD-BD qcr, qcb more to the negative than with x264 BD, at least to -4.
TMPG's x264 BD presets came out well at -2, and I concur for x264.
Did not think about going as negative for x265 as to -12, but this confirms my guessed-upon x265 approach:
To depart from x264 and offer considerable bitrate savings on paper:
Let's starve bits where the majority does not complain (chroma, grain),
right from the outset, and preprocess/encode that way to cut bandwidth.

So the quality-driven user might have to counteract to some of these defaults.

[LigH]

New upload: x265 3.6+35-83a7df0be

[Windows][GCC 14.1.0][32/32XP/64 bit] 8bit+10bit+12bit

[benwaggoner]

Originally Posted by rwill

A cb/cr offset outside of the range +/- 12 is invalid.

I would also like to note that -12 already means around 2 more bits precision in comparison to luma quantization, which is quite a lot.

Yeah, I've never seen a value more than -6 be used for anything, and even -1 is sufficient in many cases.

[FranceBB]

Originally Posted by LigH

New upload: x265 3.6+35-83a7df0be

[Windows][GCC 14.1.0][32/32XP/64 bit] 8bit+10bit+12bit

My XP says "thank you". :P

[tormento]

Originally Posted by Emulgator

Ah, that coincides well with my findings: wanting to set x265 UHD-BD qcr, qcb more to the negative than with x264 BD, at least to -4.
TMPG's x264 BD presets came out well at -2, and I concur for x264.
Did not think about going as negative for x265 as to -12, but this confirms my guessed-upon x265 approach:
To depart from x264 and offer considerable bitrate savings on paper:
Let's starve bits where the majority does not complain (chroma, grain),
right from the outset, and preprocess/encode that way to cut bandwidth.

So the quality-driven user might have to counteract to some of these defaults.

Much better you do some VMAF measurement and report us

[benwaggoner]

Originally Posted by tormento

Much better you do some VMAF measurement and report us

VMAF is a luma-only metric, so doesn't pick up any impact of chroma offsets.

Optimizing for VAMF would tend to push the offsets to high positive values in order to save bits to reduce luma QP.

[Boulder]

I ran into some interesting experimental x265 modifications, especially the cutree-strength part is something that could be used to avoid the detail/grain loss which cutree may cause.

Based on my initial tests, running a normal encode using aq-auto 6 (jpsdr's mod part for HDR) results in a much smoother image than in the vanilla jpsdr mod. This can be reverted nicely with --limit-aq1. Furthermore, --cutree-strength 1.5 would make cutree have the same weight it has when qcomp is raised to 0.7 from the default 0.6. (Cutree's weight is 5.0 * (1.0 - qcomp) by default in x265). I think some users have battled the too strong cutree by raising qcomp and also adjusting CRF to compensate the increase in bitrate it inevitably causes. With this mod, cutree can be tamed without doing anything else.

I'm not at all sure if any of the other stuff is working or not, but those mentioned seem fine.

This is the commit:
https://github.com/AmusementClub/x26...6db7fa36837672

This file can be applied on top of the current x265 repo to get the changes in. Hope I didn't make any mistakes
Patch file for jpsdr's and AmusementClub's modifications to use with MABS
Building with Visual Studio won't work, the dreaded "nested too deeply" problem strikes again and I'm not confident on how to fix it.

[BuccoBruce]

Originally Posted by benwaggoner

You need to use --repeat-headers for adaptive streaming as well, especially for HDR to make sure the 2084 metadata goes into each GOP.

Huh. I've only briefly played with DASH, all SDR, and I always just used --idr-recovery-sei...

Tangent warning: most web/JS DASH/HLS players out there, or I guess the way Chromium based browsers implement ffmpeg, really do NOT like open GOP content. Bizarrely enough if you DASH some crazy long GOP open GOP stuff and try and play it back in mpv or VLC...it works fine. Not that you should, I understand why open GOP shouldn't be used for streaming at least on a technical level.
Closed GOP + RADL instead and still managed to get away with using scene-cut/GOP of differing lengths as long as the keyframe interval from the highest encode on the ladder got used as is for all the others. Then I realized most of the clients were all accessing the highest quality stream and rarely if ever accessed the streams lower on the ladder unless their browser started "lower" and then ramped right up...a handful of hits showing up on the server for "1000k_blah_blah_init.mp4" and maybe the first half dozen segments and then...nothing but traffic on the 6-12 Mbps stuff so now any of my "adaptive streaming" stuff is just the one encode

Have I been doing it wrong, or would I need "--repeat-headers" there too? Am I even gaining anything by using --idr-recovery-sei...

Tangent 2: Chrome itself adding HEVC support has been delightful for DASH!

[benwaggoner]

Originally Posted by BuccoBruce

Huh. I've only briefly played with DASH, all SDR, and I always just used --idr-recovery-sei...

Tangent warning: most web/JS DASH/HLS players out there, or I guess the way Chromium based browsers implement ffmpeg, really do NOT like open GOP content. Bizarrely enough if you DASH some crazy long GOP open GOP stuff and try and play it back in mpv or VLC...it works fine. Not that you should, I understand why open GOP shouldn't be used for streaming at least on a technical level.

specifically, Open GOP doesn't work with adaptive streaming. If there aren't other streams that need to be seamlessly switched, open GOP is fine. And was commonly used in the pre-http adaptive streaming era.

Closed GOP + RADL instead and still managed to get away with using scene-cut/GOP of differing lengths as long as the keyframe interval from the highest encode on the ladder got used as is for all the others. Then I realized most of the clients were all accessing the highest quality stream and rarely if ever accessed the streams lower on the ladder unless their browser started "lower" and then ramped right up...a handful of hits showing up on the server for "1000k_blah_blah_init.mp4" and maybe the first half dozen segments and then...nothing but traffic on the 6-12 Mbps stuff so now any of my "adaptive streaming" stuff is just the one encode

RADL is pretty much there to give Open GOP like encoding efficiency boost and interfragment consistency while still preserving seamless switching.

And absolutely, if occasionally buffering is okay when using mobile data and the top bitrate isn't lots of Mbps, a single bitrate can work just fine, and certainly simplifies a lot. It's a rare household in developed countries that can't sustain 4 Mbps almost all the time.

And among other things, only providing a single, good bitrate will force suboptimal player heuristics to start at high quality instead of slowly ramping up.

Have I been doing it wrong, or would I need "--repeat-headers" there too? Am I even gaining anything by using --idr-recovery-sei...

--repeat-headers is needed for HDR so that the metadata gets repeated every GOP, but generally isn't needed for SDR. I don't think there's a downside to including it, though. Bitrate impact is minimal and may make it easier to start playback mid-stream. I don't think --idr-recovery-sei does anything with DASH-like http delivery; it would be more for UDP streaming.

Tangent 2: Chrome itself adding HEVC support has been delightful for DASH!

Agreed! The number of H.264-only client devices is shrinking enormously. Essentially all of mobile supports HEVC now, and it's only very old PC/Mac systems that don't support at least software decoding of HEVC, and the vast majority support full HW and DRM decoding.

[FranceBB]

Originally Posted by benwaggoner

--repeat-headers is needed for HDR so that the metadata gets repeated every GOP, but generally isn't needed for SDR. I don't think there's a downside to including it, though. Bitrate impact is minimal and may make it easier to start playback mid-stream.

Yep, I always include it anyway in the rare cases in which I have to make end-users encodes (for both SDR and HDR contents), so I don't think there's any harm to it.

Originally Posted by benwaggoner

The number of H.264-only client devices is shrinking enormously. Essentially all of mobile supports HEVC now, and it's only very old PC/Mac systems that don't support at least software decoding of HEVC, and the vast majority support full HW and DRM decoding.

Can someone please tell this to the BBC, itv and Channel 4? Please? xD

[benwaggoner]

Originally Posted by FranceBB

Yep, I always include it anyway in the rare cases in which I have to make end-users encodes (for both SDR and HDR contents), so I don't think there's any harm to it.

Can someone please tell this to the BBC, itv and Channel 4? Please? xD

Ah, but most is not all, and if you only want to use one codec on any player, H.264 is really the only choice. It may still be the only choice a decade from now.

We can make some statements, like HEVC is available on all players that support X level of hardware DRM, and HEVC would be safe to have as the only codec in those cases.

[LigH]

Just building: Latest commit adds support for alpha channel, requires compile option enabled, requires YUVA420 input when alpha processing is enabled.

This might have broken building libavcodec and ffmpeg, though... to be confirmed.
__

New upload: x265 3.6+46-7e38fcc9c

[Windows][GCC 14.2.0][32/32XP/64 bit] 8bit+10bit+12bit

Alpha Encode Options
===================

.. option:: --alpha

Enable alpha layer encoding support in x265.This option can be enabled
only when ENABLE_ALPHA is set during the make of x265.When enabled
--alpha always expects an input file in YUVA420 format.

**CLI_ONLY**

[LigH]

Just building: Latest commit adds support for MultiView (a.k.a. stereo) video streams (separate MVC or H/V SBS), requires compile option enabled, configuration via text file is recommended.
__

New upload: x265 3.6+56-3a802d9d1

[Windows][GCC 14.2.0][32/32XP/64 bit] 8bit+10bit+12bit

Multiview Encode Options
===================

Enable multiview encoding support in x265.This option can be enabled only when ENABLE_MULTIVIEW is set during the make of x265.

.. option:: --num-views <integer>
Specify the number of views in the multiview input video.

.. option:: --format <integer>
Specify the format of the input video
0 : Two separate input videos
1 : One input video with both views in left and right format
2 : One input video with both views in top and bottom format

.. option:: --multiview-config <filename>
File containing the configurations to enable multiview encoding.

Sample config file::

--num-views 2
--format 0
--input multiview-input-01.yuv
--input multiview-input-02.yuv

Other input parameters such as input-csp/input-depth/input-res/fps must be configured through normal CLI and is expected to be same for all views

**CLI_ONLY**

[ShortKatz]

Originally Posted by LigH

Just building: Latest commit adds support for MultiView (a.k.a. stereo) video streams (separate MVC or H/V SBS), requires compile option enabled, configuration via text file is recommended.
__

New upload: x265 3.6+56-3a802d9d1

[Windows][GCC 14.2.0][32/32XP/64 bit] 8bit+10bit+12bit

Cool, that x265 has now also support for MV-HEVC, ffmpeg is also working on it.
Did you also enable alpha layer encoding support in your build with ENABLE_ALPHA?

[LigH]

Obviously, yes. Both sets of new CLI options are reported in the help output.