x265 HEVC Encoder

[aegisofrime]

Originally Posted by froggy1

I use as ME range a value of 26 for 1080p encodes (ctu is 32 too). ME range is calculated as follows:

ctu size - 4(luma) - 2(chroma) (- 1 if me=hex is used)

You can lower it to 26 and enable HME like I do. Here the performance penalty is very minor, also considering that HME, as explained in the article I linked to a few posts earlier, has computationally low complexity

I wonder what options the poster above uses to hit a 40% reduction in speed when HME is enabled

I was using the default ME range of 57. I guess it needs to be dropped once HME is enabled.

I can't wait to get a 3900X or a 16 core Threadripper!

[froggy1]

Originally Posted by Boulder

Biggest differences seem to be ref=5, me star, rd=6, rd-refine, strong-intra-smoothing, max-merge=4 and amp in my settings. I don't think those should affect the search for motion though. I really need to test to get some rough values.

you're maxing out a few things. rd=6 (combined with rd-refine) is IMHO overkill if you want to compromize between speed and quality

Motion Estimation is where the encoder spends most of its time and takes the biggest penalty the higher you get. rd=6 is very expensive. I'm fine with rd=4 (which is really rd=3 as 4 maps to it)

This is the best I can do on my i7 7700K when turning on HME. I don't want to wait days for an encode to finish and I won't see the difference when watching from afar on the TV

With my settings above and HME turned on, I can shave ~100 MiB of an encode. Encoded Blade Runner once with and once without HME. The result was 100 MiB in size reduction with better subjective quality when HME is on

[Boulder]

Here are my results with my Black Sails testclip, 2748 frames @ CRF 18:

rd 6, no hme - 4333,39 kbps - 2.91 fps
rd 6, hme umh - 4323,63 kbps - 2.16 fps
rd 4, no hme - 4149,59 kbps - 3.95 fps
rd 4, hme umh - 4154,60 kbps - 2.66 fps

So the difference with rd=4 is even bigger than with rd=6 + rd-refine. I'm using a Ryzen 1800X @ 3.8 GHz.

[froggy1]

Originally Posted by Boulder

Here are my results with my Black Sails testclip, 2748 frames @ CRF 18:

rd 6, no hme - 4333,39 kbps - 2.91 fps
rd 6, hme umh - 4323,63 kbps - 2.16 fps
rd 4, no hme - 4149,59 kbps - 3.95 fps
rd 4, hme umh - 4154,60 kbps - 2.66 fps

So the difference with rd=4 is even bigger than with rd=6 + rd-refine. I'm using a Ryzen 1800X @ 3.8 GHz.

I have the opposite experience. rd=6 is too costly here. But, the tests I did were a long time ago so I'll retest again soon

[Boulder]

Of course, it could be AVX2 which is making the difference here. On a first generation Zen CPU, it's more useful to disable it (as I've done). I'd expect an Intel CPU to benefit from AVX2.

[froggy1]

I've reported the segfault when using star for hme-search Level 0 to the x265 devs. One of them came with a patch which I tested and seems to work. Patch is not committed yet but you can find it at https://mailman.videolan.org/piperma...ly/012601.html

[DJATOM]

Sweet, thanks.

[Natty]

using --dither and happy that it dithers properly. amazing results. but I want to know which dithering method it uses? and what does it use when this flag isn't enabled?

thanks.

[Barough]

x265 v3.1+10-459d3822c608 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

There was a comment in the sources in previous versions. From a former issue report:

The dithering algorithm is based on Sierra-2-4A error diffusion.

Without dither, it will probably just strip off less significant bits (but not sure).

[Natty]

Originally Posted by LigH

There was a comment in the sources in previous versions. From a former issue report:


Without dither, it will probably just strip off less significant bits (but not sure).

nice its same as x264 then. i read about this. its similar to floyd. clears my confusion why grain particles were looking finer than ordered, but not as fine as floyd.

[Barough]

x265 v3.1.2+1-76650bab70f9 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

https://bitbucket.org/multicoreware/x265/commits/

[LigH]

Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.

[filler56789]

Originally Posted by LigH

Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.

Yeah, it's becoming a mess :-/

[HolyWu]

Originally Posted by LigH

Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.

Apparently the new commits after tag 3.1 in Release_3.1 branch are not meant to add new functionality, but only meant to fix bug which causes x265 to crash or malfunction.

[LigH]

So, at the moment, users have to decide between either branch until a merge may happen...

[nevcairiel]

Originally Posted by LigH

So, at the moment, users have to decide between either branch until a merge may happen...

From your screenshot of the history, I don't see any commit that is only on the 3.1 branch thats not also on the default branch. After the earlier fixes there was a merge back to default (through stable), and the later fixes are simply on both branches.
Of course you still have to decide which branch you want, thats why branches exist. If all were identical, what would be their point? The full development "default" branch, or the possibly more stable 3.1 release branch?

[Boulder]

I tested HME some more, and got quite interesting results.

Source 1080p filtered with my standard methods and downsized to 720p, merange 26 and my standard settings in x265. 1000 frames.

umh,umh,umh 2.05 fps / 5313,76 kbps
umh,umh,star 2.24 fps / 5314,31 kbps
umh,star,star 2.00 fps / 5327,91 kbps
star,star,star 2.01 fps / 5316,15 kbps
hex,umh,umh 2.03 fps / 5299,69 kbps

no HME, umh 2.64 fps / 5323,86 kbps
no HME, star 2.79 fps / 5325,69 kbps

I'll make the same tests with some different clip to see if the difference simply occurs because of the source.

[MeteorRain]

Originally Posted by LigH

So, at the moment, users have to decide between either branch until a merge may happen...

It's dev & stable branches strategy, except that instead of constantly merge stable to dev, they cherry pick (or duplicate) bug fixes onto dev branch.

It's literally the same thing as before, just in a different way.

[LigH]

Okay, I may have missed that some patches were applied to both branches.

The only problem here for casual builders using automated build suites: How shall the suite know which branch the user prefers? It cannot rely on "tip" pointing to either. May the author of such a suite have to add a choice in its configuration?