x265 HEVC Encoder

[LigH]

New upload: x265 3.6+13-0ed28893d (https://www.mediafire.com/file/r2da9fqj12w0fjj/x265_3.6+13-0ed28893d.7z/file)

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

[Barough]

x265 v3.6+28 (GCC 14.1.0)
https://www.mediafire.com/file/p3zsun9oj3gcutu

[LigH]

Please note that most of the latest patches are related to AArch64 / ARM64 architecture and instruction set. There won't be any relevant improvement for intel x86-64 CPUs.

[benwaggoner]

Is anyone providing builds of x265 for Silicon (ARM) Mac OS yet?

I'm finally around to trying out 3.6 on my laptop, and getting the normal "I am not a developer" issues with Xcode, brew, and lack of downloads.

[jfcarbel]

Ben or others that test x265 with CPUs, looks like AMD soon be released Zen 5 has full 512bit like Intel and TestSpot article is showing some crazy handbrake gains and wonder if attributed Zen 5 with better optimizations and prediction for encoding AVX512 implementation support.

https://www.techspot.com/news/103823-amd-teases-ryzen-7-9700x-performance-ahead-july.html

Would love to see if the Zen 5 is really that much impact on x265 encodes with AVX512 vs prior Zen 4.

[FranceBB]

Would love to see if the Zen 5 is really that much impact on x265 encodes with AVX512 vs prior Zen 4.

Yeah I look forward to seeing the new benchmarks as well, but on paper it should almost definitely make the difference.
Real AVX512 has quite literally been the only reason companies stuck with Intel Xeon and dual socket CPUs despite AMD's success in the consumer sector. Now that AMD has implemented true hardware AVX512 instructions sets, I'm really worried about Intel. Their new AMX instructions didn't really find any real world use cases as servers were better off using NVIDIA GPUs directly to make neural network calculations anyway. Intel really is in trouble, they really need to step up their game, but one thing is sure, this is all gonna benefit us as users as it's gonna drive innovation.

[jpsdr]

Stupid question because i think i've read a post about it : Is x265 like x264 and using automaticaly (if CPU support) AVX512 because asm optimized code is automaticaly included, or is there some build option to activate to have AVX512 code included in x265 ?

[Emulgator]

Weighing in the necessary effort I don't think that this had been done in ASM, at least recently.
Compiler option ? Patman has AVX512-enabled builds, so it may well be worth to study his repo.
Just checked: 3.6+13-avx512-msvc1939.
https://github.com/Patman86/x265-Mod-by-Patman/releases/tag/3.6%2B13%2B1

[FranceBB]

I don't know if things changed, but up until very recently AVX512 were included by default but on runtime in the BAT you had to specify

--asm AVX512

That's what I've been doing up until now on the Xeon I have at work.

(For those wondering I'm broke so at home I only have AVX2 'cause Intel didn't love consumers enough).

[LigH]

As long as I remember, AVX512 is not included in the SIMD extensions which get activated automatically when detected because the ratio between additional encoding performance and additional power consumption (often causing a throttling due to heating) is questionable. In other words: Up to AVX2 is enabled when available, but AVX512 needs to be enabled manually, at own risk.

[benwaggoner]

Is anyone providing builds of x265 for Silicon (ARM) Mac OS yet?

I'm finally around to trying out 3.6 on my laptop, and getting the normal "I am not a developer" issues with Xcode, brew, and lack of downloads.
Ach, anyone have a x265 Mac binary, or could make one?

My haven't-written-code-for-money-since-1995 self has spent another three fruitless hours trying to get a high bit depth binary to compile or install on Mac. Homebrew and MacPorts aren't giving me high depth. Trying to build myself yields weird cmake errors I can't make head nor tail of.

[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.

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

Build 12-bit:
cd source/x265-build/12bit && \
cmake ../../ -G "Ninja" \
-DHIGH_BIT_DEPTH:bool=on -DMAIN12:bool=on -DENABLE_SHARED:bool=off \
-DENABLE_HDR10_PLUS:bool=on -DEXPORT_C_API:bool=off -DENABLE_CLI:bool=off && \
ninja && \
cp libx265.a $HOME/x265_macos_arm_build/x265_git/lib/libx265_main12.a

Build 10-bit:
cd ../10bit && \
cmake ../../ -G "Ninja" \
-DHIGH_BIT_DEPTH:bool=on -DENABLE_SHARED:bool=off \
-DENABLE_HDR10_PLUS:bool=on -DEXPORT_C_API:bool=off -DENABLE_CLI:bool=off && \
ninja && \
cp libx265.a $HOME/x265_macos_arm_build/x265_git/lib/libx265_main10.a

Build 8-bit and the full CLI:
cd ../8bit && \
cmake ../../ -G "Ninja" -DCMAKE_INSTALL_PREFIX=$HOME/x265_macos_arm_build \
-DENABLE_SHARED:bool=off -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT:bool=on -DLINKED_12BIT:bool=on \
-DEXTRA_LIB="$HOME/x265_macos_arm_build/x265_git/lib/libx265_main10.a;$HOME/x265_macos_arm_build/lib/libx265_main12.a" \
-DENABLE_HDR10_PLUS:bool=on && \
ninja && \
ninja install

[FranceBB]

AVX512 is not included in the SIMD extensions which get activated automatically when detected because the ratio between additional encoding performance and additional power consumption (often causing a throttling due to heating) is questionable. In other words: Up to AVX2 is enabled when available, but AVX512 needs to be enabled manually, at own risk.

Correct, hence the --asm avx512 switch needs to be forced in the BAT. The rationale was that in the initial tests, CPUs were getting so hot that thermal throttling came into play and were performing worse than they would have done on AVX2 only. On the other hand, not only new CPUs are much better (it's been a long way since 2019), but in a server room you have very controlled temperatures and even with air cooling you can prevent thermal throttling entirely and get the speed improvement. In other words, it's 2024, I think that rule should be changed and x265 should follow x264 in turning them on by default automatically if they're detected in the CPU.
Speaking of x264, unfortunately AVX512 are available only for the 8bit version but not for the 10bit one which is still limited to AVX2. :(

[jpsdr]

I wasn't clear enough in my question but i have my answer. What i wanted to know is that if a specific switch was needed during the build to include AVX512 code in x265.
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 ?

[Boulder]

I don't recall seeing any such option in CMake, just one for enabling assembly. So I think it's always there but just needs to be enabled by the user.

[benwaggoner]

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]

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 :p) values might be needed.

[rwill]

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 :p) 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 (https://www.mediafire.com/file/ny423r44jsm4zpz/x265_3.6+35-83a7df0be.7z/file)

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

[benwaggoner]

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]

New upload: x265 3.6+35-83a7df0be (https://www.mediafire.com/file/ny423r44jsm4zpz/x265_3.6+35-83a7df0be.7z/file)

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

My XP says "thank you". :P

[tormento]

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 [emoji56]

[benwaggoner]

Much better you do some VMAF measurement and report us [emoji56]
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/x265/commit/87155154d789d3e2faf323dcb46db7fa36837672

This file can be applied on top of the current x265 repo to get the changes in. Hope I didn't make any mistakes :o
Patch file for jpsdr's and AmusementClub's modifications to use with MABS (https://drive.google.com/file/d/1T25ZdsryaE-aqVNgWTznigwNLDQy1qvJ/view?usp=drive_link)
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]

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 :p so now any of my "adaptive streaming" stuff is just the one encode :D

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]

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 :p so now any of my "adaptive streaming" stuff is just the one encode :D
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]

--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.


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]

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 (https://www.mediafire.com/file/qjlztku3jp45frv/x265_3.6+46-7e38fcc9c.7z/file)

[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 (https://www.mediafire.com/file/ppn674zgtjfywaq/x265_3.6+56-3a802d9d1.7z/file)

[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]

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 (https://www.mediafire.com/file/ppn674zgtjfywaq/x265_3.6+56-3a802d9d1.7z/file)

[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.

[Barough]

x265 v3.6+46
Built on August 08, 2024, GCC 14.1.0

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

DL :
https://www.mediafire.com/file/b3pdvab5olo4nbw

[LigH]

Just building: Latest commit adds support for Screen Content Coding (https://hevc.hhi.fraunhofer.de/scc), requires compile option enabled

The Screen Content Coding (SCC) extensions will improve compression capability for video containing a significant portion of rendered (moving or static) graphics, text, or animation rather than (or in addition to) camera-captured video scenes. Example applications include wireless displays, remote computer desktop access, and real-time screen sharing for videoconferencing.
__

New upload: x265 3.6+65-3c3d03746 (https://www.mediafire.com/file/5zoll6p8s1hvdnn/x265_3.6+65-3c3d03746.7z/file)

[Windows][GCC 14.2.0][32/32XP/64 bit] 8bit+10bit+12bit
-DENABLE_HDR10_PLUS=ON -DENABLE_LIBVMAF=ON -DENABLE_ALPHA=ON -DENABLE_MULTIVIEW=ON -DENABLE_SCC_EXT=ON

Screen Content Coding Options
===================
.. option:: --scc <integer>

Enable screen content coding support in x265. Default disabled.
This option can be enabled only when ENABLE_SCC_EXT is set during the make of x265.
SCC enables intrablockcopy in CTU analysis which can be enabled in two modes [1-2].
Mode 1- Does limited search,faster than mode 2
Mode 2- Does full and exhaustive search

Note : Enabling SCC will disable weight prediction.
Enabling SCC expects rd-level of 6.

**CLI_ONLY**

[ShortKatz]

What's going on all of a sudden? First it looked for years as if x265 had fallen asleep and now one new feature after another is being added in no time at all. Astonishing.

[ZORAX]

Hi. I've been doing some encoding tests with x265 for a very grainy movie (Saving Private Ryan) and found some odd behavior of nr-inter parameter:

It seems the nr-inter filter has zero effect on I frames, a very small effect on P frames and a HUGE effect on B frames. This makes for a very weird frame strobing effect where I frames look sharp and grainy, B frames look smooth (even if I set ipratio and pbratio to 1.0) and grain seems to be "flickering" on the image.

Has anyone else experienced this? Is this an expected behavior of the encoder?

[jpsdr]

@LIGHT
What -DENABLE_LIBVMAF=ON is for ?

Didn't see the SCC... I have to redo all the builds... :(

[LigH]

There is no T in LigH ...

VMAF (Video Multi-Method Assessment Fusion (https://en.wikipedia.org/wiki/Video_Multimethod_Assessment_Fusion)) is a video-encoding quality metric which tries to be more similar to a human's subjective impression than PSNR and SSIM.

If enabled, x265 adds VMAF scores to the output of the -r / --recon debugging feature which compares the input video with a reconstructed video (decoding a just encoded video stream).

An objectively measurable "Quality" term is always defined as any kind of difference between an original and a reconstructed video. "Best quality" only means "no measurable difference". This may not mean the same as a casual subjective "quality" term for humans.

[rwill]

Hi. I've been doing some encoding tests with x265 for a very grainy movie (Saving Private Ryan) and found some odd behavior of nr-inter parameter:

It seems the nr-inter filter has zero effect on I frames, a very small effect on P frames and a HUGE effect on B frames. This makes for a very weird frame strobing effect where I frames look sharp and grainy, B frames look smooth (even if I set ipratio and pbratio to 1.0) and grain seems to be "flickering" on the image.

Has anyone else experienced this? Is this an expected behavior of the encoder?

This is expected. nr-inter has zero effect on I frames because I frames do not have inter. Try --nr-intra instead to neuter I frames as well.

[jpsdr]

Sorry for the mispelling, i was a little to quick, and thanks for the answer.

[Jamaika]

lowpassdct.cpp: In function 'void lowPassDct8_c(const int16_t*, int16_t*, intptr_t)':
lowpassdct.cpp:61:23: warning: right shift count is negative [-Wshift-count-negative]
61 | dst[0] = totalSum >> (-1 + (X265_DEPTH - 8));
| ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~

[Jamaika]

Just building: Latest commit adds support for alpha channel, requires compile option enabled, requires YUVA420 input when alpha processing is enabled.
This project is a bit unfinished.
Why is X265_CSP_BGRA not used?
Error: Alpha encode supported only with CQP mode???
Error: chroma subsampling must be i400 (4:0:0 monochrome), i420 (4:2:0 default), i422 (4:2:0), i444 (4:4:4)???
#if X265_BUILD >= 210
if (avctx->pix_fmt == AV_PIX_FMT_BGRA) {
ctx->params->bEnableAlpha = 1;
ctx->params->internalCsp = X265_CSP_BGRA;
} else if (avctx->pix_fmt == AV_PIX_FMT_YUVA444P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA444P10LE ||
avctx->pix_fmt == AV_PIX_FMT_YUVA444P12LE) {
ctx->params->bEnableAlpha = 1;
ctx->params->internalCsp = X265_CSP_I444;
} else {
ctx->params->bEnableAlpha = 0;
ctx->params->internalCsp = X265_CSP_I444;
}
#else
ctx->params->internalCsp = X265_CSP_I444;
#endif
break;
// 4:2:0, 4:2:2
case 1:
#if X265_BUILD >= 210
if (avctx->pix_fmt == AV_PIX_FMT_YUVA420P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA420P10LE ||
//avctx->pix_fmt == AV_PIX_FMT_YUVA420P12LE ||
avctx->pix_fmt == AV_PIX_FMT_YUVA422P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA422P10LE ||
avctx->pix_fmt == AV_PIX_FMT_YUVA422P12LE) {
ctx->params->bEnableAlpha = 1;
} else {
ctx->params->bEnableAlpha = 0;
}
#endif
ctx->params->internalCsp = desc->log2_chroma_h == 1 ?
X265_CSP_I420 : X265_CSP_I422;
break;

[LigH]

This project is a bit unfinished.

Do not blame me. The developer is Anusuya Kumarasamy.

[Jamaika]

Do not blame me. The developer is Anusuya Kumarasamy.
I don't blame you. You posted info. Previously x265 creators looked here.

[Boulder]

The mailing list is probably the best place to report any issues. Too bad they don't seem to care about the issue tracker.

[LigH]

The mailing list is probably the best place to report any issues.

I can only agree here.

[benwaggoner]

This is expected. nr-inter has zero effect on I frames because I frames do not have inter. Try --nr-intra instead to neuter I frames as well.
Exactly.

-nr-inter does an adaptive deadzone like lowpass filtering of low amplitude high frequency elements in predicted blocks, and helps a lot with grain as it is entirely temporally random. --nr-intra does the same for intra-coded blocks.

It's not really a "noise reduction" filter in the classic sense, as it filters out the noise that's the hardest to compress, not that's the most visible.

As a rule, I find that --nr-intra should be around 25%-50% --nr-inter if you're trying to actually reduce visible noise, not just save some bits or reduce QPs.