x265 HEVC Encoder

[Marsu42]

I hope one of you encoding wizards is nice enough to answer a simple usability question :-) ...

... I want to *limit* the threads x265 uses (default 2 physical cores w/ hyperthreading) to prevent my laptop burning a hole into my desk. Unfortunately, the docs (https://x265.readthedocs.org/en/default/threading.html) are way over my head other than the simpler x264 parameters of the olden days :-o

Question: How do I limit the threads used to (mostly) 2?. Some less cpu intensive lookahead or the like can use the other 2 cores, but I want to limit the hardcore encoding work that maxes out the cpu.

Disclaimer: I know there are other ways of doing this like affinity, but I'd like a nice command line approach I can feed to handbrake.

Thanks for any hints!

[x265_Project]

I hope one of you encoding wizards is nice enough to answer a simple usability question :-) ...

... I want to *limit* the threads x265 uses (default 2 physical cores w/ hyperthreading) to prevent my laptop burning a hole into my desk. Unfortunately, the docs (https://x265.readthedocs.org/en/default/threading.html) are way over my head other than the simpler x264 parameters of the olden days :-o

Question: How do I limit the threads used to (mostly) 2?. Some less cpu intensive lookahead or the like can use the other 2 cores, but I want to limit the hardcore encoding work that maxes out the cpu.

Disclaimer: I know there are other ways of doing this like affinity, but I'd like a nice command line approach I can feed to handbrake.

Thanks for any hints!
You can do this by adding --pools 2 to your command line. See http://x265.readthedocs.org/en/default/cli.html#cmdoption--pools

[Marsu42]

You can do this by adding --pools 2 to your command line.

Right, thanks - I've read the docs, but you did your very best to make it as generic (i.e. complicated) as possible and I didn't get the pools are equivalent to threads for a non-numa non-whatever system :-p

[Ely]

Also Nvidia has revealed that they can programm this thing partly it's not entirely fixed function :)

From what I heard, at least on the Tegra X1, the encoder uses cuda cores and most of the "intelligence" is done in software.

[CruNcher]

it would clash with the 3D rendering (D3D,OpenGL) but it doesn't in terms of latency it's always the same it is a separated engine but not as fixed as a normal DSP architecture they can split tasks they have more headrooms same for Intel (Quicksync) or AMD (VCE)

the CUDA Shader based H.264 Encoder still works and it clashes with the 3D Rendering i will look more closely @ which nodes get actually utilized for both, especialy looking what happens using both @ the same time ;)

[x265.cc]

my buildbot is back (automated GCC 5.2.0 / YASM 1.3.0 builds):


https://encoder.pw/x265/


webfrontend will be back soon too.

As always: don't trust any foreign binaries.

need something more experimental? https://encoder.pw/daala/

[Ely]

it would clash with the 3D rendering (D3D,OpenGL) but it doesn't in terms of latency it's always the same it is a separated engine but not as fixed as a normal DSP architecture they can split tasks they have more headrooms same for Intel (Quicksync) or AMD (VCE)

the CUDA Shader based H.264 Encoder still works and it clashes with the 3D Rendering i will look more closely @ which nodes get actually utilized for both, especialy looking what happens using both @ the same time ;)

You're right, my source for this info wasn't 100% trustworthy so it was probably at least half-wrong ^^ . Wouldn't surprise me that *some* cuda cores are used but there's definitely some silicium dedicated to the encoder.

[Parabola]

Yeah, I'd be interested in seeing this. x265 was able to do 2160p30 on a dual-socket Broadwell system several months ago, so we could have a quality comparison. I think Elemental has already demoed 2160p60 live as well.

Interesting - are these 8-bit or 10-bit? How far off the compression performance asymptote do you have to go to get this throughput? Preset ultra fast? BD-rate loss perhaps worse than best H.264 performance on same hardware?

Fraunhofer HHI showed proprietary real-time 2160p50 8-bit last year at IBC on standard server architecture. They admitted coding performance falling short of HM.

Nvidia / HW encoding is a very welcome addition to the ecosystem but precedent suggests it may underperform.

[benwaggoner]

Interesting - are these 8-bit or 10-bit? How far off the compression performance asymptote do you have to go to get this throughput? Preset ultra fast? BD-rate loss perhaps worse than best H.264 performance on same hardware?
I don't remember the exact specifics. MultiCoreWare should have the info. I'm sure things have gotten faster since then.
[/QUOTE]

[x265_Project]

Interesting - are these 8-bit or 10-bit? How far off the compression performance asymptote do you have to go to get this throughput? Preset ultra fast? BD-rate loss perhaps worse than best H.264 performance on same hardware?

The demo we gave at NAB used an application that we (MulticoreWare) have built called UHDkit. This application utilizes the same x265 HEVC encoder library that is available to everyone under the GPL v2, but it has additional capabilities at the application layer. The demo involved 4K, 10 bit encoding at 10 Mbps, using the ultrafast preset, on a dual Xeon E5-2699 v3 (18 cores, 36 threads) @ 2.3 GHz. To achieve higher effective utilization and overall throughput on a 36 core, 72 thread machine, UHDkit was running multiple instances of x265 in parallel. We achieved 88 FPS+, but that was with an older version of x265 (1.6+184). We can achieve higher throughput today, and we're still working hard to improve performance.

As far as the encoding efficiency of x265 vs. x264, anyone can run tests to compare subjective visual quality or rate distortion curves. Using the ultrafast preset, objective quality measurements usually show something comparable to x264's best (veryslow) encoding quality, but this varies quite a bit, depending on the content. Ultrafast is a go-fast preset which trades efficiency for speed in almost every way possible. Our goal for real-time encoding scenarios is to provide the performance required to enable customers to use higher quality settings while maintaining real-time frame rates (for example, our medium, fast or faster presets).
http://www.multicorewareinc.com/wp-content/uploads/2015/04/x265_88FPS.jpg

[708145]

The demo involved 4K, 10 bit encoding at 10 Mbps, using the ultrafast preset, on a dual Xeon E5-2699 v3 (18 cores, 36 threads) @ 2.3 GHz.[/IMG]

What frequency did the Xeon run at during the encode? I assume during heavy AVX2 work it doesn't clock much higher, but we've seen some surprises in our tests with a 2x18core Haswell: It went up to 3.6GHz during node.js tests, averaging 3.4GHz.

If your scaling is memory bandwidth limited try deactivating selected cores. The chip will use the headroom automatically and increase minimum frequency.

[LigH]

NUMA, NUMA, yeah!

[LigH]

Eventually, new builds from me, I waited a bit longer, but it was worth it: Main12 now supports some degree of assembler optimization completely (at least up to SSE2-4 and AVX1), and just recently got a new table of "lambda" values (no clue what it means, but it seems to be important for a sane bitrate control).

x265 1.7+371-24c1ee516d13 (GCC 4.8.2) (https://www.mediafire.com/download/p507695nox57zl2/x265_1.7+371-24c1ee516d13.GCC482.7z)
x265 1.7+371-24c1ee516d13 (GCC 4.9.2) (https://www.mediafire.com/download/kybwwdvv1a12r87/x265_1.7+371-24c1ee516d13.GCC492.7z)

And some results to compare:

8 bit (https://www.mediafire.com/download/dvdbaspl6cv5oqy/tos_60s_720p_main.hevc.mp4) | 10 bit (https://www.mediafire.com/download/01r7znyrcmuus42/tos_60s_720p_main10.hevc.mp4) | 12 bit (https://www.mediafire.com/download/b823w1rhu1hb8zd/tos_60s_720p_main12.hevc.mp4) (each ~6..7 MB, only default parameters except bit depth)

[shinchiro]

I'm not sure if this is bug or not but I can see "warping" effect when panning in certain scene.
For example, try encoding this clip with x265 (--crf 24 --preset medium). Pay attention to the shirt near to border when panning
http://www.solidfiles.com/d/b189f87909/

The effect more noticeable if you use aq-mode 2. I dont get this problem when encoding this clip in x264

[Ma]

For example, try encoding this clip [...]

In what sense this anime.mkv.exe is a clip? Can you explain?

[shinchiro]

In what sense this anime.mkv.exe is a clip? Can you explain?
Dont click the big button download button. Click "direct download link"

[Ma]

Dont click the big button download button. Click "direct download link"

Confirmed, now there is a clip. Thanks for explanation.

After encoding I see that all new parts of the image that appear from the bottom of the screen are in much worse quality than "old" parts of the image. For me it is a bug in x265.

[LigH]

You possibly mean the slightly noisy structure the codec is trying to keep as stable as possible? This is certainly caused by the very low details in the rather flat colored part where the codec finds no reason to prefer a linear upwards motion vector over a zero motion vector, therefore the harder contrast to the upper black line of the shoulder leaves a trail of quantization errors.

[shinchiro]

You possibly mean the slightly noisy structure the codec is trying to keep as stable as possible?
Yeah..I can't find right word for that :p

Here is another anime clip involving panning to right. Pay attention to tv logo ("BS11") in the top-upper-right
Source: http://www.solidfiles.com/d/9f18cb8565/

If you encode it with --crf 35 in x265, you can see leftover of the tv logo as it trailing the panning. Aside that, it seem harder to maintain the tv logo shape

In x264, even I encode it with --crf 35, I cant see leftover of the tv logo. It stabilize & maintain the shape well while panning

[sneaker_ger]

Don't compare at same crf, compare at same bitrate. I did encode at same bitrate (8bit x265 --crf 35 vs 8bit x264 --crf 51) and the x264 version is so bad the logo is gone for large parts of the clip! At these ultra-low bitrates x265 will eat x264 for breakfast.

https://www.sendspace.com/file/q0lfau

[foxyshadis]

Don't compare at same crf, compare at same bitrate. I did encode at same bitrate (8bit x265 --crf 35 vs 8bit x264 --crf 51) and the x264 version is so bad the logo is gone for large parts of the clip! At these ultra-low bitrates x265 will eat x264 for breakfast.

https://www.sendspace.com/file/q0lfau

Wow. I used to stress test x264 for bottom-of-the-barrel mobile encodes (that segment YIFY has made a career out of) and I'm blown away by what x265 can do there. A q51 pure-predicted encode is still quite watchable for simple scenes like this, and smaller than I thought possible.

[sneaker_ger]

I assume the large blocks do a lot of the work. Any sane person would of course downscale before encoding using x264 at these bitrates.

[Atak_Snajpera]

Eventually, new builds from me, I waited a bit longer, but it was worth it: Main12 now supports some degree of assembler optimization completely (at least up to SSE2-4 and AVX1), and just recently got a new table of "lambda" values (no clue what it means, but it seems to be important for a sane bitrate control).

x265 1.7+371-24c1ee516d13 (GCC 4.8.2) (https://www.mediafire.com/download/p507695nox57zl2/x265_1.7+371-24c1ee516d13.GCC482.7z)
x265 1.7+371-24c1ee516d13 (GCC 4.9.2) (https://www.mediafire.com/download/kybwwdvv1a12r87/x265_1.7+371-24c1ee516d13.GCC492.7z)

And some results to compare:

8 bit (https://www.mediafire.com/download/dvdbaspl6cv5oqy/tos_60s_720p_main.hevc.mp4) | 10 bit (https://www.mediafire.com/download/01r7znyrcmuus42/tos_60s_720p_main10.hevc.mp4) | 12 bit (https://www.mediafire.com/download/b823w1rhu1hb8zd/tos_60s_720p_main12.hevc.mp4) (each ~6..7 MB, only default parameters except bit depth)

Sorry to say that but your builds are still broken in 2-pass mode on CPU with many threads (stat file is messed up at the end). Could you compile with MA's patch?

[nevcairiel]

Sorry to say that but your builds are still broken in 2-pass mode on CPU with many threads (stat file is messed up at the end). Could you compile with MA's patch?

You should get the patch integrated into mainline if you think its required for proper functionality, then it'll show up in everyones build.

PS:
Also actually linking a patch when asking someone to build with it would help to find it. :D

[Atak_Snajpera]

https://bitbucket.org/multicoreware/x265/issues/147/corrupted-stat-file-on-cpu-with-many#comment-20273155

[qyot27]

That patch is for MinGW-w64 itself, not x265. To integrate it you'd have to rebuild the entire toolchain (erring on the side of caution would mean MinGW-w64 AND GCC in this case).

But there's no indication in the comments whether this issue exists in some arbitrary version of MinGW-w64 as provided by X or Y package management system (the decrepit mingw-get system/MSYS1, Cygwin, MSys2, a Linux distro's provided version), or if it's still present in the latest stable tarball or git HEAD, so even something as feasibly simple as 'apply this patch to MinGW-w64' is unclear. Because there's also no indication of which version of MinGW-w64 was used to build the failing binaries in this case. The compiler is what everyone might fixate on, but it's not like you're only restricted to the newest version of MinGW-w64 when you build newer versions of GCC.

[Atak_Snajpera]

I was thinking about this patch

*** ratecontrol-o.cpp Sat Jun 27 07:48:04 2015
--- ratecontrol.cpp Sat Jun 27 08:00:51 2015
***************
*** 2213,2219 ****
char cType = rce->sliceType == I_SLICE ? (rce->poc > 0 && m_param->bOpenGOP ? 'i' : 'I')
: rce->sliceType == P_SLICE ? 'P'
: IS_REFERENCED(curFrame) ? 'B' : 'b';
! if (fprintf(m_statFileOut,
"in:%d out:%d type:%c q:%.2f q-aq:%.2f tex:%d mv:%d misc:%d icu:%.2f pcu:%.2f scu:%.2f ;\n",
rce->poc, rce->encodeOrder,
cType, curEncData.m_avgQpRc, curEncData.m_avgQpAq,
--- 2213,2223 ----
char cType = rce->sliceType == I_SLICE ? (rce->poc > 0 && m_param->bOpenGOP ? 'i' : 'I')
: rce->sliceType == P_SLICE ? 'P'
: IS_REFERENCED(curFrame) ? 'B' : 'b';
! #if _WIN32 && __GNUC__
! static Lock lockFile;
! lockFile.acquire();
! #endif
! int fprintfRet = fprintf(m_statFileOut,
"in:%d out:%d type:%c q:%.2f q-aq:%.2f tex:%d mv:%d misc:%d icu:%.2f pcu:%.2f scu:%.2f ;\n",
rce->poc, rce->encodeOrder,
cType, curEncData.m_avgQpRc, curEncData.m_avgQpAq,
***************
*** 2222,2228 ****
curFrame->m_encData->m_frameStats.miscBits,
curFrame->m_encData->m_frameStats.percent8x8Intra * m_ncu,
curFrame->m_encData->m_frameStats.percent8x8Inter * m_ncu,
! curFrame->m_encData->m_frameStats.percent8x8Skip * m_ncu) < 0)
goto writeFailure;
/* Don't re-write the data in multi-pass mode. */
if (m_param->rc.cuTree && IS_REFERENCED(curFrame) && !m_param->rc.bStatRead)
--- 2226,2236 ----
curFrame->m_encData->m_frameStats.miscBits,
curFrame->m_encData->m_frameStats.percent8x8Intra * m_ncu,
curFrame->m_encData->m_frameStats.percent8x8Inter * m_ncu,
! curFrame->m_encData->m_frameStats.percent8x8Skip * m_ncu);
! #if _WIN32 && __GNUC__
! lockFile.release();
! #endif
! if (fprintfRet < 0)
goto writeFailure;
/* Don't re-write the data in multi-pass mode. */
if (m_param->rc.cuTree && IS_REFERENCED(curFrame) && !m_param->rc.bStatRead)

[LigH]

Unfortunately, I have only little experience, I am already glad that I can update and compile in a batch. Additionally applying a patch and reverting it before the next update ... I'd better bet on seeing this patch submitted to the x265 developers mailing list to have it commited.
__

P.S.: Steve Borho replied this patch will a) slow down all the stats writing, and b) probably not ensure the last few entries to be correct.

[Rogatti]

http://blog.streamingmedia.com/2015/07/new-patent-pool-wants-share-of-revenue-from-content-owners.html
-
Can this apply retroactively to all the content already encoded with H.265?

[x265_Project]

Wow. I used to stress test x264 for bottom-of-the-barrel mobile encodes (that segment YIFY has made a career out of) and I'm blown away by what x265 can do there. A q51 pure-predicted encode is still quite watchable for simple scenes like this, and smaller than I thought possible.
Thanks for the demo, sneaker_ger. This is a great example of motion compensated prediction in action.

[Stacey Spears]

There is a typo on the x265 documentation http://x265.readthedocs.org/en/default/cli.html?highlight=display%20master#cmdoption--master-display

Example for P65D3 1000-nits:
G(13200,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)

The P65D3 should probably be D65P3. The D and Ps are swapped.

[Ma]

But there's no indication in the comments whether this issue exists in some arbitrary version of MinGW-w64 as provided by X or Y package management system (the decrepit mingw-get system/MSYS1, Cygwin, MSys2, a Linux distro's provided version), or if it's still present in the latest stable tarball or git HEAD, so even something as feasibly simple as 'apply this patch to MinGW-w64' is unclear.

The bug is in all versions of Mingw-w64. I attached patched mingw_pformat.c file from release versions 3.3.0, 4.0.2 and from current trunk version.

Release Mingw-w64 versions are in this directory
http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/

Current trunk version you can get by
git clone git://git.code.sf.net/p/mingw-w64/mingw-w64 mingw-w64-mingw-w64

You can rebuild Mingw-w64 (after replacing mingw_pformat.c file) by the command -- for 64-bit CRT:
configure --host="x86_64-w64-mingw32" --build="x86_64-w64-mingw32" --enable-lib64 --disable-lib32 CFLAGS="-O2 -g" CXXFLAGS="-O2 -g"
make install
and for 32-bit CRT:
configure --host="i686-w64-mingw32" --build="i686-w64-mingw32" --enable-lib32 --disable-lib64 CFLAGS="-O2 -g" CXXFLAGS="-O2 -g"
make install

If you want smaller libs (without debug data) you can don't add -g option in configure step.

If you rebuild the same version as is in your GCC toolchain, you can simply take only libmingwex.a from your local/lib folder and replace your original libmingwex.a file in x86_64-w64-mingw32/lib folder in your mingw compiler (i686-w64-mingw32/lib for 32-bit version).

Mingw-w64 team rewrite this patch -- current working version is like in this message
http://sourceforge.net/p/mingw-w64/mailman/message/34308686/

[x265.cc]

The bug is in all versions of Mingw-w64.


JFYI: builds from https://encoder.pw/x265/ shouldn't be affected, at least the newer ones.

[mchartier]

JFYI: builds from https://encoder.pw/x265/ shouldn't be affected, at least the newer ones.

Too bad there are no 10bit builds though...

[LigH]

How can I check which MinGW versions my current build environments use?

[Jamaika]

JFYI: builds from https://encoder.pw/x265/ shouldn't be affected, at least the newer ones.
It is better, much better. :)
x265.exe --input-depth 10 --input-csp i420 --input-res 1920x1080 --output-depth 10 --preset slow --fps 120.000 --bitrate 4000 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 30 --min-keyint 1 /
--open-gop --ref 1 --bframes 0 --me dia --output "x265_420p10le.h265" -
X265.cc 1.7.0.380
http://i57.tinypic.com/1584fwg.png
X265.ru 1.7.0.374
http://i58.tinypic.com/4jb6on.png
Original
http://i57.tinypic.com/s46kuq.png

PS. Streaks are more visible on the screenshot of the original 1920x1080. It drives me crazy time differences when taking screenshot of FFmpeg {ss} for movies 10 depth. For movies 8bit there is no problem between RAW and H265.

Edit: How to look not only pass 2 looks better. http://www.sendspace.com/filegroup/H0igQXOxB6mIcSOBbLqUDFxPp9ZNQNyD9wKTbBZuD50 Y4M doesn't matter.

[LigH]

X265.cc 1.7.0.380
http://i57.tinypic.com/1584fwg.png
X265.ru 1.7.0.374
http://i58.tinypic.com/4jb6on.png
Original
http://i57.tinypic.com/s46kuq.png

Do not attempt to deeplink to "images" which are replaced by whole ad-packed HTML pages by the hoster.

To compare encoded with original material, you may prefer to use a reconstructed Y4M from the x265 encoder.

[Ma]

How can I check which MinGW versions my current build environments use?

You can read !components.txt file in your msys folder (section GCC version, component mingw-w64).

You can also look at the description on this page:
http://files.1f0.de/mingw/

[nevcairiel]

You can read !components.txt file in your msys folder (section GCC version, component mingw-w64).

You can also look at the description on this page:
http://files.1f0.de/mingw/

Thats assuming he uses one of my builds, or one of the packages that include one of them. There are other sources for mingw-w64 builds out there. ;)

[Ma]

Thats assuming he uses one of my builds, or one of the packages that include one of them.

Yes, he uses your builds: r10 & r13.

[LigH]

Yes, an old GCC 4.8.2 package and one rather current GCC 4.9.2 package downloaded from http://xhmikosr.1f0.de/tools/msys/ (several years ago and about 1-2 months ago).

So I assume I would have to get the matching MinGW sources package and recompile to apply the patch... but I am not really so experienced, would not be sure if I did that correctly. Support is welcome...

[Ma]

My patch works, but is not perfect.

Mingw-w64 team rewrites printf family functions, but puts function for example is directly call to msvcrt.dll. So if we make the best possible lock to mingw-w64 code and we mix this code with call to msvcrt functions we will fail -- our functions are atomic against our functions, MS functions are atomic against MS functions but if we mix stdio functions -- there will be mixed output (wrong).

So the only reasonable solution is to make exactly the same lock as MS did in msvcrt.dll. Then we can mix new code with msvcrt.dll calls without problems. So I copy MS source code to mingw_pformat.c file and all work perfect.

I attached new patch (+ MS sources if someone wants to check if I exactly copy _lock_file & _unlock_file functions). I attached also test file that calls printf & puts functions from many threads -- my previous patch fail at this test.

New patch is to mingw-w64 release version 4.0.2.
Nevcairiel could you make (test) GCC toolchain with this patch?

[Ma]

Support is welcome...

I compiled libmingwex.a for nevcairiel GCC 4.9.2 and 5.2 with latest patch. I think that nevcairiel uses some -march/-mtune options especially for 32-bit GCC 4.9.2 -- I use only -O2 option. You can replace original libmingwex.a with new from this archive:
www.msystem.waw.pl/x265/gcc-492-520-lib.7z

[LigH]

Alright - time to abandon GCC 4.8.2 now.
__

BTW, please excuse a little off-topic: How do I set up a different codepage in the MSYS console? Localized tools, e.g. hg, detect German language, but Umlauts are displayed incorrectly.

$ hg clone https://bitbucket.org/multicoreware/x265
Zielverzeichnis: x265
Fordere alle ─nderungen an
F³ge ─nderungssõtze hinzu
F³ge Manifeste hinzu
F³ge Dateiõnderungen hinzu
F³gte 10860 ─nderungssõtze mit 25234 ─nderungen an 715 Dateien hinzu
Aktualisiere auf Zweig default
238 Dateien aktualisiert, 0 Dateien zusammengef³hrt, 0 Dateien entfernt, 0 Dateien ungel÷st

[nevcairiel]

I compiled libmingwex.a for nevcairiel GCC 4.9.2 and 5.2 with latest patch. I think that nevcairiel uses some -march/-mtune options especially for 32-bit GCC 4.9.2 -- I use only -O2 option. You can replace original libmingwex.a with new from this archive:
www.msystem.waw.pl/x265/gcc-492-520-lib.7z

I don't specify any special CFLAGS, just use whatever the configure script sets as default.

[LigH]

New builds with MinGW-w64 patch for multi-threaded stats file output:

x265 1.7+382-7c83f7755422 (GCC 4.9.2) (https://www.mediafire.com/download/wojl2gb8iholy6e/x265_1.7+382-7c83f7755422.GCC492.7z)
x265 1.7+382-7c83f7755422 (GCC 5.2.0) (https://www.mediafire.com/download/qae6d64dn30vukr/x265_1.7+382-7c83f7755422.GCC520.7z)

[x265.cc]

New patch is to mingw-w64 release version 4.0.2.

my buildbot is now using your patch (v2). :thanks:

[ARRYMatie]

Man x265 still too crap compared to x264.

I tried play around with multiple settings but seems like there's always inconsistent color blotches in certain areas and banding in other areas.

Both of which would look smooth and uniform if encode in x264.

[LigH]

And who shall take this "complaint" serious without a proof, including all required details to recreate it?

[foxyshadis]

Man x265 still too crap compared to x264.

I tried play around with multiple settings but seems like there's always inconsistent color blotches in certain areas and banding in other areas.

Both of which would look smooth and uniform if encode in x264.

You're doing it wrong if you get banding with x265. Either switch up to 10-bit or add some grain, but I just don't believe you that x264 would look uniform where x265 doesn't at the same bitrate and bit depth.