x265 HEVC Encoder

[microchip8]

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.

[microchip8]

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.

[microchip8]

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 :-/

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

[nevcairiel]

The concept of "tip" in mercurial is flawed anyway, would never rely on it. Someone pushed an experimental half-broken branch, and suddenly thats the tip? Clearly not what everyone wants to build off of. The "most recent change" seems like a particular worthless point of reference to use.
You should always be aware of what branch you build from.

[mandarinka]

Originally Posted by 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.

I tested HME (with umh/umh/umh, merange 92, against umh with same merange) on some cel anime bluray footage with motion (both full camera motion and objects in scene only motion).

I got notably decreased SSIM score with HME, so be careful, at these low resolutions it looks like it is possible that HME doesn't help but harms.
Why? The first ME pass with merange 92 is done on 4X downscale. So if you have 1080p resolution, you are down on 240p. It is likely that small objects won't get tracked properly at this stage. After that, the second (480p) and last (1080p) ME stage only only lower merange (search distance), I assume? So if the large downscaling fools the first pass, the second and third stage might not be able to correct it.

My footage was 1440x1080 and you would have even worse situation at 720p. Basically this factor may cause HME to be counter productive unless you use it on 4K for which ts was intended (IIRC).

"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16 
--pass 2 --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me star --subme 7 --merange 92 --amp --rect --ref 6 
--weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 --qcomp 0.7 
--no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree --cu-lossless 
--lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 5108.02s (0.17 fps), 10064.24 kb/s, Avg QP:19.49, SSIM Mean Y: 0.9820175 (17.451 dB)


"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16 
--pass 2 --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me umh --subme 7 --merange 92 --amp --rect --ref 6 
--weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 --qcomp 0.7 
--no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree --cu-lossless 
--lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 11135.11s (0.08 fps), 10064.75 kb/s, Avg QP:19.49, SSIM Mean Y: 0.9820200 (17.452 dB)

"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16 
--pass 2 --hme --hme-search umh,umh,umh --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me umh --subme 7 
--merange 92 --amp --rect --ref 6 --weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 
--qcomp 0.7 --no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree 
--cu-lossless --lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 7319.99s (0.12 fps), 10051.98 kb/s, Avg QP:19.52, SSIM Mean Y: 0.9819607 (17.438 dB)

p.s. Ignore the fps values, they are not indicative of the speed due to background cpu usage, system sleeping for a time and so on.

BTW, it would be interesting to determine what is the speed hit of a particular HME setting and then determine how much do you need to increase merange for the normal search mode to get at the same FPS - and then comapre the quality/SSIM. Because obvioously the added computation time could be used to improve quality by just increasing merange too, so that is your reference point for comparisons.

Edit: one other thing. Doing two-pass testing smaples, I found that just switching ME method between star and umh changes content of each frame and block quite a bit due to various indeterministic things going on. Individual frames would look worse and better based on how the rate control stars aligned.
So don't compare the results just by bitrate they give you!
It is quite possible the two files are not the exactly same quality, which would skew your judgement completely.