x265 HEVC Encoder

[brumsky]

http://www.mediafire.com/file/1g95yof33vr73u7/x265-2.3_24-a0eee4b_vs2017-AVX.7z

http://www.mediafire.com/file/4nsvdbf65ipbne9/x265-2.3_24-a0eee4b_vs2017-AVX2.7z


If you don't see latest build on page www.msystem.waw.pl/x265 please refresh the page (F5 should help).


Awesome thank you both!!

[pingfr]

Awesome thank you both!!

I can only agree and applaud with both hands.

At the moment it is... "un-wise" to use a GCC built x265 binary.

VS2017 is (at least for now) the way to go.

[Barough]

Why is that pingfr?

GCC compiles mite be slow for 10bit encodes but thats not the case for 8bit.

Personally so am i not interested in 10bit due 2 that its not especially compatible with hardware.

Sent from my Samsung Galaxy S7 edge via Tapatalk

[LigH]

The differences are subtle as the preset "increases"...

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

http://www.ligh.de/pics/x265-speed.png

With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.

[benwaggoner]

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

I full agree about using percentage ratios.

Has anyone tried doing profile-driven optimizations for x265? I don't know if it would help much given all the assembler, but 5% on veryslow with a different compiler suggests there may be some juice to squeeze out there still.

[LigH]

An analytic with a lot of spare time would probably check: Which features are only enabled in slower presets, and are they still in C code? Most probably, as I would assume they are not primitive operations, thus rather hard to implement in lower level languages.

[pingfr]

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

http://www.ligh.de/pics/x265-speed.png

With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.

Thanks for making that table re-cycling the data I pasted a few days ago, glad it served a purpose.

Although it is missing the placebo preset.

I just can't be bothered waiting 45 minutes to run each placebo encodes.

Also note it is important to remind you these tests were ran using 2.3+23, it is worth mentioning the latest commit applies limit-tu to slower, veryslow presets for an up to 20% increase in FPS according to the commit, this most likely has skewed the presented data here, it has to be seen whether the delta remains and even there we're talking about 0.15 of 1 fps. :p

[LigH]

Don't be sad; I do not even have any AVX2 capable processor available.

[aymanalz]

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

http://www.ligh.de/pics/x265-speed.png

With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.


What exactly is that ratio percent in the last row? In the first comparison, one encode is faster than the other by 0.83%, which you have called as a 100.83% ratio.

So in all the comparisons, to know by how much one is faster than the other, you have to ignore the "100", and whatever remains is the percentage difference in speed.

Isn't that the relevant metric? By what percent one is faster than the other?

[aymanalz]

Thanks for making that table re-cycling the data I pasted a few days ago, glad it served a purpose.

Although it is missing the placebo preset.

I just can't be bothered waiting 45 minutes to run each placebo encodes.


You could run the placebo encodes on a very short clip, maybe trimmed from your original clip.

[nevcairiel]

Isn't that the relevant metric? By what percent one is faster than the other?

Its the same metric, just a different way to express it.
Declaring GCC to be the reference at 100%, then this gives you the numbers above for VS2017 - easy enough to read the increases out of.

[pingfr]

Its the same metric, just a different way to express it.
Declaring GCC to be the reference at 100%, then this gives you the numbers above for VS2017 - easy enough to read the increases out of.

Regardless a 5.91% speed increase is nothing to be "ashamed of".

[nakTT]

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

http://www.ligh.de/pics/x265-speed.png

With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.
I agree on this. Generally MSVC builds is consistently better. I have been comparing the performance for every new release of x265 and found this to be true.

[LigH]

I decided to keep building with GCC still, I believe that an advantage of <2% is no reason to abandon it, and furthermore, installing Visual Studio seens to be much more elaborate than using an MSYS environment, just for this small task and nothing else...

But I don't mind other people publishing MSVC builds. More choice!

[CruNcher]

Please dont freaking forget the compiler is Windows only GCC has to be Multiplatform that is a different bread to crunch entirely, in balancing and overall performance on every Posix OS and different ARCHs running on them.

[Ma]

The speed comparison of different x265 builds is not so simple.
Let's say that we want compare speed of encoding file "Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m" at preset medium to 8-bit hevc (like in pingfr test, but only for preset medium).

There are many CPUs on the world, so we compare encoding speed with different '--asm' levels (from false [= --no-asm] to AVX).
gcc63s2 means GCC 6.3 build that works on SSE2 CPU (which is 'none' for Win64)
gcc70s3 means GCC 7.0 build for SSSE3 CPUs and better
gcc70s4 means GCC 7.0 build for SSE4.1 CPUs and better
vs2017a1 means VS 2017 build for AVX CPUs and better.
(There are no AVX2 builds -- my CPU is only with AVX.)

Relative encoding speed on Win7 64-bit, i5 3450S, RAM DDR3 1600:
--asm= | false .|. SSE2 .| SSSE3 .| SSE4.1 | AVX
--------|--------|----------------------------------
gcc63s2 |100.00% |100.00% |100.00% |100.00% |100.00%
gcc70s2 | +4.63% | +4.12% | +4.81% | +0.56% | +0.61%
gcc70s3 | +8.47% | +5.14% | +5.74% | +0.04% | +0.14%
gcc70s4 |+11.57% | +8.06% | +6.90% | +0.16% | -0.42%
vs2017s2|-19.66% |-21.68% |-30.75% | +1.07% | +0.87%
vs2017a1|-18.77% |-20.90% |-29.68% | +2.48% | +2.45%

Some remarks:
1) gcc70s4 build is the fastest with '--no-asm' option but is the slowest with '--asm=avx' option.

2) VS 2017 builds are very slow on CPUs <= SSSE3, the switch is on SSE4.1 level.

3) GCC 7.0 builds are a little bit faster than GCC 6.3 builds.

4) My i5 3450S is surprisingly slower than pingfr's i7 6700 -- 12.34 fps to 23.17 fps.

5) The speed difference from '--asm=sse4' to '--asm=avx' is minimal (12.30 fps to 12.34 fps; full data in attachment).

[Midzuki]

I decided to keep building with GCC still, I believe that an advantage of <2% is no reason to abandon it, and furthermore, installing Visual Studio seens to be much more elaborate than using an MSYS environment, just for this small task and nothing else...

But I don't mind other people publishing MSVC builds. More choice!

I second that. Visual Studio is a nightmare, tons of bloat in the registry and needless services. It's okay and a must-have for professional programmers, but I am not a professional programmer, I'm just a not-so-advanced ordinary user.

@Ma:
many thanks for the useful post :thanks:

That's exactly what I was thinking, but I didn't have any empirical evidence :o

[pingfr]

4) My i5 3450S is surprisingly slower than pingfr's i7 6700 -- 12.34 fps to 23.17 fps.

And why would this be "surprising" at any rates? You're comparing an i7 against an i5 and furthermore a CPU from the 6th generation against one from the 3rd generation which furthermore is an "S" CPU targeted at semi-embedded low-power users?

Unless I missed something here...

Even though, the point I was trying to make a few days ago regarding these tests was that for "some obscure" reasons --preset veryslow was giving us the biggest increase when switching from a GCC build to a VS2017 build compared to a supposedly much faster (but therefore having less optimized settings) preset such as --preset medium and that is where things needed further investigations.

[shinchiro]

@Ma thanks for the detailed test. btw the gcc is built with posix or win32 threads?

[Ma]

And why would this be "surprising" at any rates? You're comparing an i7 against an i5 and furthermore a CPU from the 6th generation against one from the 3rd generation which furthermore is an "S" CPU targeted at semi-embedded low-power users?

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

@shinchiro: win32 threads

[pingfr]

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

Okay I see.

Also some benchmarks have been somewhat leaked regarding a 3.6GHz upcoming AMD Ryzen with... 16 cores. So you might want to hold your breath a little longer before buying a newer CPU.

[CruNcher]

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

@shinchiro: win32 threads

More impressive it becomes if you look @ it Realtime doing the Decoding instead of the Encoding which is harder to grasp visually ;)

[pingfr]

More impressive it becomes if you look @ it Realtime doing the Decoding instead of the Encoding which is harder to grasp visually ;)

Me no understanderino you. :helpful: :helpful: :helpful:

[easyfab]

@Ma could you test this build https://www.sendspace.com/file/biunt6

GCC 6.3 but fprofile with my i2600k

[LigH]

@ easyfab:

Look how to avoid an unnecessary full-quote... :rolleyes:

[Ma]

@Ma could you test this build https://www.sendspace.com/file/biunt6

GCC 6.3 but fprofile with my i2600k

normal GCC 6.3 = 100%

--asm= |SSSE3 |SSE4.1 |AVX
gcc63s2 |100.00%|100.00%|100.00%
gcc70s2 | +5.00%| +0.54%| +0.83%
gcc63pr |-36.29%| +1.89%| +1.46%
vs2017s2|-30.60%| +0.99%| +0.87%


At SSSE3 level your profiled version is very slow but it is OK -- when you profile the functions that are not executed are compiled for minimize size.

At SSE4.1 level you speed-up +1.89% to normal GCC 6.3 build -- it is better than VS 2017 build (but a bit slower than VS 2017 AVX build). So it is the fastest version that you can execute.

[easyfab]

@Ma Thanks for the report

I will try with GCC 7 to see if it better.

[Boulder]

Does x265 have framerate-aware ratecontrol like x264 does?

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c583687fab832ba7eaf8626048f05ad1f861a855

I was just wondering if I should run into material that needs to be encoded at double framerate. Many concerts are encoded as interlaced and I use QTGMC on them to get high quality progressive output at double framerate.

[sneaker_ger]

Yes. (But I don't think you can supply timecodes to the CLI for VFR.)

[Romario]

Is there any news for Ryzen optimizations?

Gesendet von meinem GT-I9295 mit Tapatalk

[Ma]

I decided to try with profiled VS 2017 version -- www.msystem.waw.pl/x265/vs2017pgo.7z
Speed gain at 8-bit --profile medium:
SSE4.1: 12.10 -> 12.53 (+3.55%)
AVX: 12.14 -> 12.56 (+3.46%)

[Boulder]

Yes. (But I don't think you can supply timecodes to the CLI for VFR.)That's good, I rarely need VFR and I can use x264 for those anyway :)

[pingfr]

I decided to try with profiled VS 2017 version -- www.msystem.waw.pl/x265/vs2017pgo.7z
Speed gain at 8-bit --profile medium:
SSE4.1: 12.10 -> 12.53 (+3.55%)
AVX: 12.14 -> 12.56 (+3.46%)

Uh? would you be kind enough to supply us with a such "optimized" binary?

[easyfab]

I decided to try with profiled VS 2017 version -- www.msystem.waw.pl/x265/vs2017pgo.7z
Speed gain at 8-bit --profile medium:
SSE4.1: 12.10 -> 12.53 (+3.55%)
AVX: 12.14 -> 12.56 (+3.46%)

nice, better boost than mine with profiled GCC version.

I'm curious to see what a profiled version can give for ryzen ?

[Ma]

Uh? would you be kind enough to supply us with a such "optimized" binary?

Probably yes if I write batch file to automate all strange things that I do manually.
-------------------------------
8- and 10-bit for SSE4.1 and AVX CPUs optimized mainly for my encoding options (-p veryslow --crf 18 -I480 --deblock -1):
www.msystem.waw.pl/x265/x265-2.3+24-a0eee4b_vs2017-PGO.7z

[Sagittaire]

nice, better boost than mine with profiled GCC version.

I'm curious to see what a profiled version can give for ryzen ?

There are certainely higher optimisation in x265 code itself. actualy x265 encoding with AVX2 off is better than with AVX2 on.

http://rigaya34589.blog135.fc2.com/blog-entry-909.html

[Dclose]

720p should be around 2800kbits whereas 1080p should be around 6500kbits if you want "acceptable" quality, depends on the fps and the crop.

Those rates are 2-3 times higher for what I consider acceptable quality. These terms are subjective, but 6500kbits 1080p I would expect to look pretty darn great.

I turn on practically every quality option though.


Can I use denoise filter, make that any sense? To have better quality encodes, of course.
In general, I consider denoisers a waste of time unless the source is very bad quality. Even then, denoiser will usually hurt detail, so you're giving up detail for a cleaner but less original picture. Also, x265 inherently denoises and smooths, and lots of people have spent a lot of time trying to figure out how to get it to not do that. :)

[Dclose]

at this point in time, x265 is not on-par with x264's detail retention, and no amount of knobs tweaking will change that. Sorry to say it, but you'll have to accept this for the moment.
I disagree. Though I say that knowing more about and having tested x265 settings than about x264 settings. I've used x264 Very Slow for years, and would use Placebo now. (yes, I do notice a difference.)

Stock x265 presets I think turn a lot of new people off. It's like every preset is still geared to smoothing and lower bitrate. It really could use some presets more geared to quality to better show what it can do.

There's been talk about x265 Grain setting lately, and that can help, but it also can overdo it. Lower the two Psy amounts to get more of a Film setting than a Grain setting.

Here's a detail setting I think a lot of people miss in x265, probably since tooltips and the manual recommend not to touch it:
Adaptive Quantization Strength
Default is 1.00.
Details that you could never get sharp enough no matter how much bitrate or CQ you threw at it? Change it to 2.00 and see.

2.00 is a lot, though. 1.1 to 1.5 is more balanced. 2.00 can bring ringing and halos and mosquito noise, etc.

Bitrate will go up, but I'd generally rather watch video of CQ22 and 1.5 AQS than the same size (or even bigger) file at CQ21 and 1.0.

As with most settings, it's a balancing act based on what result you're trying to achieve.

[Motenai Yoda]

I just noticed there isn't any userdata or cli output to check if ssim-rd is enabled or not.

[need4speed]

Here's a detail setting I think a lot of people miss in x265, probably since tooltips and the manual recommend not to touch it:
Adaptive Quantization Strength
Default is 1.00.
Details that you could never get sharp enough no matter how much bitrate or CQ you threw at it? Change it to 2.00 and see.

As with most settings, it's a balancing act based on what result you're trying to achieve.

This is pretty interesting and something worth a try.
My standard settings for quality/speed 1080p are:
C:\Portable\StaxRip-x64-1.4.1.1-test\Apps\x265\x265.exe --crf 20 --amp --aq-strength 1.25 --qcomp 0.7 --aq-motion --me star --no-strong-intra-smoothing --no-deblock --no-sao --frames 60745 --y4m --output "D:\DA CONVERTIRE

This is giving me good results, assumed that perceived quality is something personal and all relative.
Question would be: AQS raised to 1,5 will allow to lower CRF?
Besides, not sure if aq-motion will turn off or disable aq-mode? Meaning that using aq-motion will make aq-mode choice irrelevant?
Thanks!

[LigH]

additional compiler flags

I found a (hopefully) comprehensive overview (https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options). Might be useful for enthusiastic optimizers to have this bookmarked.

[Dclose]

This is pretty interesting and something worth a try.
My standard settings for quality/speed 1080p are:
C:\Portable\StaxRip-x64-1.4.1.1-test\Apps\x265\x265.exe --crf 20 --amp --aq-strength 1.25 --qcomp 0.7 --aq-motion --me star --no-strong-intra-smoothing --no-deblock --no-sao --frames 60745 --y4m --output "D:\DA CONVERTIRE

This is giving me good results, assumed that perceived quality is something personal and all relative.
Question would be: AQS raised to 1,5 will allow to lower CRF?
Besides, not sure if aq-motion will turn off or disable aq-mode? Meaning that using aq-motion will make aq-mode choice irrelevant?
Thanks!
1.25 is from what I can tell a nice compromise setting that gives details extra punch without adversely affecting much else. I generally prefer a sharper picture with some potential artifacts over dull and smeared, so at the moment 1.50 is generally more my preference. As I said, generally, I'd rather watch cq22 and 1.5AQS than CQ21 and 1.00, and the file should be smaller.

I'd like to use 2.00 all the time. But it can add a lot of bitrate. It can make complicated things like faces talking in close-ups look great (instead of looking like smeared plastic like they often do). But at other times it will look hyper-detailed like a sharpness filter set too high, and do things like a scene of three people on the screen but, strangely, only one of the three is surrounded by mosquito noise -- possibly due to the background making the scene complicated, like people standing outside with some in front of trees and gravel while others that are in front of water in that same scene have mosquito noise.

From the handful of tests I've done on Motion Based AQ, I didn't like it and turn it off. I forget why. Maybe I wrote it down on a note somewhere. Two probable reasons are it either added smoothness (blur) like so many x265 settings do and which so many of us turn off :D or it added too much bitrate vs. video quality improvement.

[need4speed]

1.25 is from what I can tell a nice compromise setting that gives details extra punch without adversely affecting much else. I generally prefer a sharper picture with some potential artifacts over dull and smeared, so at the moment 1.50 is generally more my preference. As I said, generally, I'd rather watch cq22 and 1.5AQS than CQ21 and 1.00, and the file should be smaller.

From the handful of tests I've done on Motion Based AQ, I didn't like it and turn it off. I forget why. Maybe I wrote it down on a note somewhere. Two probable reasons are it either added smoothness (blur) like so many x265 settings do and which so many of us turn off :D or it added too much bitrate vs. video quality improvement.

Basically my above command line was with your AQS tweaking while encoding, so I've checked output and it does make a difference in terms of details.
On the other hand keeping same CRF increases file size, so I'll try with CRF 21 and 22 together with AQS 1,5. I assume AQ mode is set to 1, correct?
As for aq-motion I have noticed some differences as well, so will disable and see what happens playing around with CRF and AQS only.
I am not a pixel peeper and have spent last year trying to find best compromise between encoding time, quality and detail retention. 1080p TV series mainly, the goal is to save between 40 and 50% in terms of space (vs AVC) and, finally, looks like we're almost there.
Every bit of help counts here, my I7 3770 Ivy Bridge is finally giving me 8/9 fps with my settings, which is totally acceptable.
Thanks for your tips! Much appreciated since I have tried a lot of different stuff and most of times couldn't tell the difference in the output video, in spite of a massime encoding fps drop.

[Dclose]

I assume AQ mode is set to 1, correct?

Every bit of help counts here, my I7 3770 Ivy Bridge is finally giving me 8/9 fps with my settings, which is totally acceptable.

AQ1 seems more visually consistent than AQ2.

I assume I turn on more quality settings than you since my 3770k at 4.1ghz does more like 1-2 fps with 1080.
So what's the story with rdoq-level 1 vs 2? I've been toying around with it and it seems that 1 is "sharper" but it might not be as true to the source compared with 2.

I also noticed rdoq-level 2 is used in the higher presets.
I'm wondering about that too. From my tests so far, 2 seems sharper, though. 1 cleans up the video to perhaps make detail easier to see, but it removes detail mixed in with grain. I'm trying to think of a better way to explain it.

Using a pretty grainy test clip, 1 removed a lot of grain. 2 kept more of the grain and looks more like the source. 1 is 10+% bigger filesize.

Currently trying to find negatives of using 2 instead of 1.

[need4speed]

AQ1 seems more visually consistent than AQ2.

I assume I turn on more quality settings than you since my 3770k at 4.1ghz does more like 1-2 fps with 1080.

AQ1,Aq2 and AQ3 with my seetings look almost the same, can't spot a difference. Maybe aq3 was keeping a bit more detail in dark areas (if memmory serves well) but, again, cant tell the difference.

Well, my settings are more speed-oriented, trying to retain as much detail as possible. I have tried a lot of tweaking, messed around with every and each switch trying to find a balance between speed and quality (perceived, this is all personal).
The idea of 2/4 fps to me is not acceptable, hence the speed I get I assume. This is since most of additional tweaking gave back no significant added value, in spite of looong encoding times.
A good step forward was made with latest lambda table and encoder releases. This was brilliant and, always imho, has given me the result I want.
I still encode in 8bit, 8bit pseed is almost the double of 10bit and I cannot see a significative difference between the two final files. This as general quality, have spotted differences in single frames and yes, there are some, but to me not worth 4fps vs 8/9 fps speed.
I have come to my "final" settings, still about to decide among
option 1: --crf 20 --amp --aq-strength 1.25 --qcomp 0.7 --aq-motion --me star --no-strong-intra-smoothing --no-deblock --no-sao

option 2: x265.exe --crf 21 --amp --aq-strength 1.5 --qcomp 0.7 --me star --no-strong-intra-smoothing --no-deblock --no-sao --frames 60755 --y4m --output "D

The difference will be made by final size more than quality whch presumably will be more or less the same.

For the record my most significative test to judge quality is grabbing some frames with writings, signs, plates or whatever similar and check original vs encoded video. Maybe not a significative test but gives a good idea about detail retention.

[Dclose]

AQ1,Aq2 and AQ3 with my seetings look almost the same, can't spot a difference. Maybe aq3 was keeping a bit more detail in dark areas (if memmory serves well) but, again, cant tell the difference.

Well, my settings are more speed-oriented, trying to retain as much detail as possible.

I still encode in 8bit, 8bit pseed is almost the double of 10bit and I cannot see a significative difference between the two final files.
AQ3 increased my filesizes a lot and seemed to have a mind of its own. It's also apparently geared for dark areas, and that's a main area I generally will accept a quality loss in first since it's harder to see details in dark areas anyway and x265 is good at avoiding big macroblocks unless using Max Merge 1.

I only use 10-bit on animation. It can be a big help on that especially at low bitrate.

If you're not already using it, Early Skip is probably the biggest speed/quality setting in x265. It obviously gives imperfections and artifacts at very low resolution and bitrate, (at that level, the video needs all the help it can get and encodes pretty fast anyway without it), while at higher res and bitrate its quality negatives are less noticeable and boost speed often around 30+%.

[brumsky]

@Dclose

Yeah I've seen the same thing. 1 seems to make the "detail" pop more or look darker in an attempt to stand out more. 2 does seem more like the source but requires a slightly higher psy value to get the same level of detail - at least to my eye.

@need4speed

I've done some testing with higher aq strength 1.1 - 1.5 and I don't like the outcome... The sharpness of hair, for example, looks worse the higher the aq strength. It ends up fussy and blocky\noisy around objects in the foreground.

The two settings that seem to improve the quality the best for me on a quality\speed trade off. Is ref 6 and max merge 5. Those two together provide a relatively small hit in speed but a big gain in quality, at least to my eye.

[brumsky]

option 1: --crf 20 --amp --aq-strength 1.25 --qcomp 0.7 --aq-motion --me star --no-strong-intra-smoothing --no-deblock --no-sao

option 2: x265.exe --crf 21 --amp --aq-strength 1.5 --qcomp 0.7 --me star --no-strong-intra-smoothing --no-deblock --no-sao --frames 60755 --y4m --output "D


What preset are you using? I'm asking because amp requires rect if memory serves me right.

Try adding ref 5 or 6 & max merge 4 or 5 depending on the preset you use and drop aq-strength to 1. 6 & 5 respectively should give the best results.

[need4speed]

What preset are you using? I'm asking because amp requires rect if memory serves me right.

Try adding ref 5 or 6 & max merge 4 or 5 depending on the preset you use and drop aq-strength to 1. 6 & 5 respectively should give the best results.

Preset is medium; if I'm not mistaken (I use staxrip) the log shows some warning if any setting is not enabled due to something wrong, but I might be wrong here.
Will try your tweaks and see how it goes, leaving AQS set to 1. Btw, medium preset requires ref and maxmerge set as?
Usually I end up with 4000/6000 Kbs and haven't noticed any problem with sharpness or blockyness around the objects. But will look at more deeply.
Thanks!
@DClose early-skip seems to be enabled by default as I see, at least with latest builds I use.

[Dclose]

Yeah I've seen the same thing. 1 seems to make the "detail" pop more or look darker in an attempt to stand out more. 2 does seem more like the source but requires a slightly higher psy value to get the same level of detail - at least to my eye.

The two settings that seem to improve the quality the best for me on a quality\speed trade off. Is ref 6 and max merge 5. Those two together provide a relatively small hit in speed but a big gain in quality, at least to my eye.
I would say the opposite on psy level for 1 and 2, based on my small number of tests so far. 2 is inherently more grainy and so needs less psy -- which also means if I'm trying to preserve grain then a lower psy setting means an even smaller file than 2 already does.

The size difference at the same settings has my curiosity. I'm trying to figure out where 1 is putting that extra bitrate. Would expect 2 to be bigger but it's not.

What I'm still trying to eye is the difference 1 and 2 do on complicated areas. It can be hard to compare since 1 looks like it "holds together" better and makes a more "precise" picture, but maybe that's only because 2 has more grain over it. More testing and eyeballing is needed.

Max Merge can be a complicated setting, and I'm surprised that in this entire thread I think only a couple of us have brought it up. At higher bitrate and resolution, a merge of 5 probably doesn't kick in all that much anyway except when really useful. At very low res and bitrate, 5 can be a necessity to keep the video watchable. And at like 720p and 2000 kbps, lots of things can happen, such as 5 making objects and "big detail/edges" more solid, but while also destroying grain and fine detail and making things flat and smooth. At that res/bitrate, 1 can make the video look great in well-lit scenes, but the blocking and similar ugliness in dark areas basically necessitates the use of at least 2. And 1 at that res/bitrate can make objects seem "thin/ghostly."

It's interesting which path to choose: more Max Merge to stop blocking and similar, or less Max Merge but use more deblocking filter.

Ironically, (ok, maybe not ironically), AQS of 2.00 seems it might do best with Max Merge 5. Like MM 5 is merging (too much) detail together, but AQS 2.00 is trying to jam in more (too much) detail. So it kind of works out.

But, AQS 2.00 is unfortunately too much overall, at least at the mild bitrates I've tested at, and Max Merge 5 is too much overall, at least at mild bitrates. I can understand people liking MM 5 at mild bitrate, but it smooths and smears and makes things like cheeks on a face close-up look flat, sort of like if setting the deblock filter too high.

I don't know what setting you mean by "ref 6" unless you mean RDO 6.