x265 HEVC Encoder

[Barough]

*************
Release Notes
*************

Version 4.2
===========

Release date - 19th April, 2026.

New feature
-----------
1. Threaded Motion Estimation (Experimental feature)-It uses a dedicated threadpool to precompute Motion Estimation in parallel.Improves encoding speed upto 1.5x for 1080p & lower resolution on multi core machines with low frequency setting. On high frequency systems or on machines with low number of cores, the overhead of additional Motion estimation work may outweigh parallelism

Enhancements to existing features
-------------

1.Add new Levels 6.3 to 7.2 specified in ITU-T H.265 (V9) (09/2023) and above
2.Improve Slices feature with check zeroMv
3.Enable frame parallelism with MCSTF feature
4.Updated support to signal AOM FGM params
5.Improve quality with SBRC feature
6.Updated DolbyVision P5 VUI defaults

API changes
-----------
1. API Support to enable Threaded Motion Estimation(--threaded-me)

Optimizations
-------------
1. RISC V optimizations including SAD, SATD, DCT, IDCT, block copy, pixel utilities, SAO, loopfilter, transpose kernels resulting in 2x encoding speed.
2. ARM SIMD optimizations including the use of NEON and SVE instruction set extensions. The following algorithms now have optimized SIMD implementations: DST, IDCT, SSE, SSD ,intra_pred_planar, pelFilterLumaStrong, interpolation, planecopy, dequant_normal, blockcopy, pixel variance resulting in 8% faster encoding speed compared to v4.1

Bug fixes
---------
1. Fix memory leaks (no command line option, SEI buffer, analysis save/load)
2. Fix chroma qp offset for non yuv444 inputs
3. Fix max supported input resolution
4. Fix bugs with ARM SIMD optimizations
5. Fix Alpha and Multiview feature flag support in x265_config
6. Fix test harness issues, CMake errors
7. Fix inconsistent output with aq-motion
8. Fix crash with hist-scenecut on high bit-depth builds
9. Fix lookahead concurrency bug
10. Fix shared link issue (R_X86_64_PC32), yuv recon output issue, rd-refine and dynamic-refine issue, inputs for Windows named pipe,weighted prediction delta_chroma_offset, crf and vbv issue in abr-ladder, psnr and ssim reported with MCSTF feature, internally overflowed VBV variables

Known issues
------------
1. Output mismatch between analysis save & load with cutree with reuse level < 10
2. Inconsistent hash mismatch with abr-ladder feature
3. Performance regression observed with threaded-me feature on high frequency systems and for higher resolutions (4k)

[Barough]

x265 v4.2
Built on April 20, 2026, GCC 15.2.0
Win32/64 / 8bit+10bit+12bit

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


DL :
https://www.mediafire.com/file/6vsp8u110dkml3c

[benwaggoner]

Well, at least the chroma-offset fix has gone in.
Have you done a before/after comparison?

[GeoffreyA]

Have you done a before/after comparison?

I checked only the bitrate difference of 4.2; it is the same as builds with the offending 2016 commit reverted, which Z2967 discovered a while ago. Back then, there was a difference. The faulty code was causing the offset calculation not to be added to the chroma-weighting value in the non-444 case, causing a departure from x264's behaviour. Reverting the code led to the expected bitrate scaling with increasing offsets.

https://forum.doom9.org/showthread.php?p=2027365#post2027365
https://forum.doom9.org/showthread.php?p=2027456#post2027456

[LigH]

Can you link the source of that news?

It was in the x265 Developers Mailing List via email (or archived here (https://mailman.videolan.org/pipermail/x265-devel/2026-April/014533.html)).

[Z2697]

The repo is migrated to GitHub, finally!
https://github.com/Multicorewareinc/x265

Bitbucket is really harder to use... maybe it's more corporation oriented?

[GeoffreyA]

Much nicer than that bloody Bitbucket.

[Z2697]

I have an idea of limiting the x265 to basically H.264 specs, maybe to truly compare the two encoders, x264 and x265.

ffmpeg -i 00009.m2ts -f yuv4mpegpipe -v 0 - | x265 --input - --y4m -o asd.265 --no-sao --aq-mode=1 --ctu=16 --min-cu-size=16 --merange=16 --rect --tu-intra-depth=3 --tu-inter-depth=3 --max-tu-size=8 --psy-rd=1 --rdoq=1 --psy-rdoq=0 --rd=6 --rskip=0 --cbqpoffs=-2 --crqpoffs=-2 --limit-refs=0 --lookahead-slices=0 --bframes=3 --pbratio=1 --limit-intra-angle=2 --crf 23


The limit-intra-angle is a feature I specifically coded for this (after I still see "streaks" with all the previous options).
https://github.com/Mr-Z-2697/x265-experimental/tree/E-2026-05-25_limited-intra-angles
A Windows executable: https://pixeldrain.com/u/uGcAzUA2 (10bit only), if anyone is interested to try it :)

UPDATE: I've changed how the parameter work in the code, new executable: https://pixeldrain.com/u/SiMJntRG, the command above refers to previous behavior (now it's "3").

Is there something I missed?
The result is still different, x264 is blurrier but covers artifacts better.
I wonder what the change to default lambda table has to do with this.
(I mean, of course it would change RD, but is it the reason behind this?)

But yeah the "streaks" or "micro-bandings" are basically gone after the intra angles limit is put.
Which confirms x265 did nothing wrong (on paper), it's just how the spec work.
But there should be something to fix it, like SAO or CDEF... well, we know how that goes...

[rwill]

I wonder what the change to default lambda table has to do with this.
(I mean, of course it would change RD, but is it the reason behind this?)

Is there something like QPRD in x265? There is in x264 .. subme=10 IIRC.

Over a somewhat standard sequence the QP +/- for CUs should be a tiny bell curve around 0. If its not the lambda table does not fit the average compression capabilities and is sub-optimal.

[Z2697]

Is there something like QPRD in x265? There is in x264 .. subme=10 IIRC.

Over a somewhat standard sequence the QP +/- for CUs should be a tiny bell curve around 0. If its not the lambda table does not fit the average compression capabilities and is sub-optimal.

Wait, QPRD code looks very similar to x265 rd-refine, or should I say the other way around.
Why the heck is it problematic in x265... another mystery?

[GeoffreyA]

The result is still different, x264 is blurrier but covers artifacts better.


In x264, I believe pbratio varies based on mbtree, whereas in x265, it's decoupled from cutree. Can that have something to do with this?

[Z2697]

In x264, I believe pbratio varies based on mbtree, whereas in x265, it's decoupled from cutree. Can that have something to do with this?

It's forced to 1 when mbtree is on.

In ratecontrol.c:

if( h->param.rc.b_mb_tree )
{
h->param.rc.f_pb_factor = 1;
rc->qcompress = 1;
}
else
rc->qcompress = h->param.rc.f_qcompress;


Note the rc->qcompress here is "not the same qcomp"...
x265 does the same thing:

m_qCompress = (m_param->rc.cuTree && !m_param->rc.hevcAq) ? 1 : m_param->rc.qCompress;

It's because the --qcomp parameter becomes a control for mb/cutree strength, yeah, double meaning.

[GeoffreyA]

The limit-intra-angle is a feature I specifically coded for this (after I still see "streaks" with all the previous options).
https://github.com/Mr-Z-2697/x265-experimental/tree/E-2026-05-25_limited-intra-angles
A Windows executable: https://pixeldrain.com/u/uGcAzUA2 (10bit only), if anyone is interested to try it :)


I downloaded the binary and will test it when I've got a chance. If it doesn't break the standard, this might be good to submit to x265, no? Eliminating the long-standing microbanding issue is a positive.

[Z2697]

I downloaded the binary and will test it when I've got a chance. If it doesn't break the standard, this might be good to submit to x265, no? Eliminating the long-standing microbanding issue is a positive.

If one can ignore the decrease in compression ratio... like 10% on intense scenes. :o

[Z2697]

So, I tried the previous version of lambda table with all other limitations and it still more or less look more detailed but more "artifacted" than x264... (this is not necessairy bad or good, it's like a double-edged sword, maybe)
What am I missing?
I know HEVC isn't exactly a superset of AVC, but close enough, in theory we should be able to approximate it right?
Did deblocking filter actually changed? Although I don't think it's the main difference.

Can we draw some conclusion from this and say x265 isn't as worse than x264 as some folks may believe?
(Well it is, a bit worse, but not that much?)

[GeoffreyA]

I think I know what you're saying: it's a sort of "noise," which might look all right in itself, appearing more detailed, but deviates from the source. It seems more apparent in complex regions, so something to do with psy or AQ?

[Z2697]

I think I know what you're saying: it's a sort of "noise," which might look all right in itself, appearing more detailed, but deviates from the source. It seems more apparent in complex regions, so something to do with psy or AQ?

I think there's real detail too.

[Z2697]

OK a big part of the problem is when the min-cu-size is not 8, x265 is not able to use different intra modes for TU's within a CU. (could be a HEVC limitation, not confirmed)
The default value is 8, but I thought AVC macroblocks are 16x16 so I set both ctu and min-cu-size to 16 to have 16x16 CU's only.
I'm a bit confused by all those "U's" and blocks of HEVC and AVC...
When the min-cu-size=16 parameter is removed, the artifact and detail level of a "limited x265" is on par with x264. On par meaning they both have some win and lose in different area/frames...

Now I think I can confidently say that minus some minor/major "irritating points" the quality of x265 is on par with x264, at least for the subset of features, how this scales to the "new" HEVC features, maybe still a bit uncertain, but most of which should be easy to scale, just bigger blocks and more modes right?
(Please ignore SAO for a sec :))

[GeoffreyA]

I tested the limit-intra-angle=2 on my Last Night on Soho clip, and indeed, it seems to remove the microbanding, at about the same bitrate. This needs to go into mainline forthwith :)

Now I think I can confidently say that minus some minor/major "irritating points" the quality of x265 is on par with x264, at least for the subset of features, how this scales to the "new" HEVC features, maybe still a bit uncertain, but most of which should be easy to scale, just bigger blocks and more modes right?
(Please ignore SAO for a sec :))

Perhaps if x265 had been built by adding features on top of x264, it would have been easier to create an exact or close match.

[rwill]

OK a big part of the problem is when the min-cu-size is not 8, x265 is not able to use different intra modes for TU's within a CU. (could be a HEVC limitation, not confirmed)

Thats why there is a 2Nx2N and a NxN Intra mode to pick at the lowest level. Also keep in mind that 4x4 Luma Intra in HEVC uses a 'somewhat strange' transform (DST instead of DCT), which might or might not be beneficial to the residual being encoded.

[Z2697]

Also keep in mind that 4x4 Luma Intra in HEVC uses a 'somewhat strange' transform (DST instead of DCT), which might or might not be beneficial to the residual being encoded.

Now you said it, I have a feeling that I've seen it, but I can't find any information...
Can you point me in the right direction?

[Z2697]

OK... I found it myself.
In "8.6.4 Transformation process for scaled transform coefficients", search for keyword "trType".

The spec never spell "DST" or "Discrete Sine Transform" literally... (but have DCT)