x265 HEVC Encoder

[brumsky]

Originally Posted by need4speed

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.

Medium defaults to ref 3 max merge 2, so start with ref 5 & max 4. The more reference frames you give the encoder the better the results. If it's to slow then drop max to 3. If you can stomach the speed try ref 6.

Try zooming in with staxrips video comparison tool, you'll see the extra noise\blocking around places like hair when higher AQ strength is used.

[brumsky]

Originally Posted by Dclose

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.

rdoq 2 basically rounds out some of the equations resulting in less high frequency noise being retained. With my testing it seems like 1 makes the noise darker and seems to stand out more compared to rdoq 2. I thought 1 was better at first - but after running encodes on several different sets of video I can more clearly see the difference. I've since gone back to rdoq 2.

My understanding of max merge is that it allows motion predictions to be more accurate by giving the encoder room to expand it's search. Someone please correct me if I misunderstand it's purpose.

ref is the number of reference frames the encoder can use. This is taken from the docs.

Max number of L0 references to be allowed. This number has a linear multiplier effect on the amount of work performed in motion search, but will generally have a beneficial affect on compression and distortion.

Note that x265 allows up to 16 L0 references but the HEVC specification only allows a maximum of 8 total reference frames. So if you have B frames enabled only 7 L0 refs are valid and if you have --b-pyramid enabled (which is enabled by default in all presets), then only 6 L0 refs are the maximum allowed by the HEVC specification. If x265 detects that the total reference count is greater than 8, it will issue a warning that the resulting stream is non-compliant and it signals the stream as profile NONE and level NONE and will abort the encode unless --allow-non-conformance it specified. Compliant HEVC decoders may refuse to decode such streams.

[need4speed]

Originally Posted by brumsky

Medium defaults to ref 3 max merge 2, so start with ref 5 & max 4. The more reference frames you give the encoder the better the results. If it's to slow then drop max to 3. If you can stomach the speed try ref 6.

Try zooming in with staxrips video comparison tool, you'll see the extra noise\blocking around places like hair when higher AQ strength is used.

Ok thanks.
First tests on 5 mins video gives approx 5fps which is still kinda acceptable.
As for video comparison tool the difference with my previous settings is noticeable but not so relevant. Again, pixel peeping is not my goal, when video is playing the difference is barely visible.
Still, there is something to consider: the input video quality. Usually I re-enable amazon webrips or bd TV shows and what I have noticed is that my 8 fps template works OK with those, but when it comes to standard webdl approximately 6000 lbs avc yes, your additional tweaks make a difference as for noise and details in dark areas.
Above all I am looking after killing any smoothing effect, I accept some blockyness but not "plastic faces".
Have also tried fast preset, somehow the impression is that overall image is sharper but detail loss is too high.

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Boulder]

As a non-technical person, I've never really understood --max-merge. What does it do in layman's terms? I've understood that it doesn't merge blocks but the resulting vectors from n blocks to predict motion.

[Dclose]

Originally Posted by brumsky

rdoq 2 basically rounds out some of the equations resulting in less high frequency noise being retained. With my testing it seems like 1 makes the noise darker and seems to stand out more compared to rdoq 2. I thought 1 was better at first - but after running encodes on several different sets of video I can more clearly see the difference. I've since gone back to rdoq 2.

My understanding of max merge is that it allows motion predictions to be more accurate by giving the encoder room to expand it's search. Someone please correct me if I misunderstand it's purpose.

ref is the number of reference frames the encoder can use. This is taken from the docs.

I did a clip from season 1 of Burn Notice, (shot intentionally grainy), and rdoq 1 looks like someone used a denoiser filter (or Max Merge 5! lol) on it compared to rdoq 2.

For an extreme MM example, do a test and output as low resolution, like 250 res and CQ 27. Do Max Merge 1 and then Max Merge5. MM1 probably looks like a mess, while MM5 probably looks way too smooth and has obvious big, thick edges on things.

More MM might be "expanding its search," but more importantly, and sometimes badly, it does what its name says: merge. In the 720p 2000kbps zone, MM5 can kill detail and make things look flat. Things will still have "chunks" and "areas" of detail, but it's not fine detail, and, frankly, can look as if you're using a lower resolution than what you are.

A funny thing about the default presets last time I checked is the slower the preset the more Max Merge is used. So you get (some) people using slower presets hoping for more detail, but then there's still SAO, intra smoothing and whatever else, but now also more Max Merge is used, which makes things even more smoothed.

For reference frames I've pretty much settled on 4 refs and 10 b-frames as the sweet spot. B-frames seems to help more than more refs. I think more refs helped but the speed/quality trade-off wasn't ideal. People will say 10 is too much and rarely gets used, but I have seen the difference, and some others have said the same, so whatever. Having said that, I don't think refs and b-frames are something to be overly concerned about.

[need4speed]

Originally Posted by brumsky

Medium defaults to ref 3 max merge 2, so start with ref 5 & max 4. The more reference frames you give the encoder the better the results. If it's to slow then drop max to 3. If you can stomach the speed try ref 6.

Try zooming in with staxrips video comparison tool, you'll see the extra noise\blocking around places like hair when higher AQ strength is used.

Updating settings and first feedback is a fps drop 9 to 5..almost 50%. Will see if woth it but comparison tool is showing (imho) no significative improvemet, but definitely there is some.
Will get back.

[brumsky]

@need4speed

I don't always zoom in when comparing, I just did it with this last because I could see something was different. After zooming in is when I noticed it.

Maybe just try to up ref but keep max merge at its default.

I checked the docs and confirmed my gut feeling. If rect is disabled amp is disabled as well.

From the docs:
This setting has no effect if rectangular partitions are disabled. Default disabled

[brumsky]

@Dclose

Yeah I'm not a fan of rdoq 1, I think 2 is better.

I'll have to test MM again, I know the last time I did it it looked better. That was at 1080p with a "healthy" bitrate.

b frames are for compression not quality. I & P frames have higher bit rates and quality.

@need4speed
what settings did you use for ref and mm?

[brumsky]

@Dclose and @Need4speed

Something to keep in mind, it's best to compare b frame to b frame from the source and your encodes. Try using something like AvsPmod. You'll need to add .ffinfo(cfrtime=false,vfrtime=false,version=false,colorspace=false,colorrange=false,cropping=false,sar=false) to your script. This will show you what type of frames you are comparing. You shouldn't compare mismatched frame types. Source I vs encode B for a worst case scenario.

[Dclose]

Originally Posted by brumsky

b frames are for compression not quality. I & P frames have higher bit rates and quality.

In a complicated scene involving jungle, fine dirt, and a dozen people, people walking left to right in the background looked better with 10 b-frames than with fewer b-frames.

I don't write the manual for this stuff. I just run test clips and look for the differences. *shrug*

[brumsky]

Originally Posted by Dclose

In a complicated scene involving jungle, fine dirt, and a dozen people, people walking left to right in the background looked better with 10 b-frames than with fewer b-frames.

I don't write the manual for this stuff. I just run test clips and look for the differences. *shrug*

How do you know you were looking at b frames and not p frames or even I frames?

[Midzuki]

Originally Posted by brumsky

How do you know you were looking at b frames and not p frames or even I frames?

Possibly with Elecard HEVC Analyzer

[pingfr]

Originally Posted by Midzuki

Possibly with Elecard HEVC Analyzer

Got a download link for that matey?

[Dclose]

Originally Posted by brumsky

How do you know you were looking at b frames and not p frames or even I frames?

If one minute of video looks different than another one minute of video, and the only thing changed is the x265 b-frame setting, I'm going to assume the difference in video has something to do with the b-frame setting.

[need4speed]

Originally Posted by brumsky

@Dclose

Yeah I'm not a fan of rdoq 1, I think 2 is better.

I'll have to test MM again, I know the last time I did it it looked better. That was at 1080p with a "healthy" bitrate.

b frames are for compression not quality. I & P frames have higher bit rates and quality.

@need4speed
what settings did you use for ref and mm?

'Morning.
Actually last encode from an Amazon webrip (approx 13k kbs avc) was made with 5 ref and 5 bframes. I have left untouched max merge. Can't really tell why but it looks a bit better, somehow clearer image and dust in the air looks better.
Good tips, thanks.
What about early skip in this context?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[brumsky]

@Dclose

Sounds good...

@Neef4speed

Glad to hear it! try ref 6 and let me know what you think.

[need4speed]

Originally Posted by brumsky

@Dclose

Sounds good...

@Neef4speed

Glad to hear it! try ref 6 and let me know what you think.

Will try ref6 for sure, what do you thinks of early-skip? To be enabled?

[brumsky]

Originally Posted by need4speed

Will try ref6 for sure, what do you thinks of early-skip? To be enabled?

I used to us it about a year ago before I started comparing b frames.

What kind of CPU do you have again?

If you're looking to speed up encodes try adding these settings.

--ctu 32 generally provides better quality and is noticeable faster. I use it on almost every encode. My exceptions would be high CRF,14-16, encodes that I want a bit more compression.

--qg-size <CTU/2> So if your running ctu 32, then it's 16. Faster and generally better quality but less compression.

Also you may want to take another look at --deblock. I did a shit ton of tests with it and settled on --deblock -3:0. The first param is it's strength, second is how many pixels it affects. I found that negative numbers for the 2nd param, pulls the deblock to far from the edge of the block. basically defeating the purpose of using it. I tested disabling deblock and didn't like the outcome.

Try adding these settings: --ref 6 --ctu 32 --qg-size 16
It should be a bit faster and give better quality.

[need4speed]

Originally Posted by brumsky

I used to us it about a year ago before I started comparing b frames.

What kind of CPU do you have again?

If you're looking to speed up encodes try adding these settings.

--ctu 32 generally provides better quality and is noticeable faster. I use it on almost every encode. My exceptions would be high CRF,14-16, encodes that I want a bit more compression.

--qg-size <CTU/2> So if your running ctu 32, then it's 16. Faster and generally better quality but less compression.

Also you may want to take another look at --deblock. I did a shit ton of tests with it and settled on --deblock -3:0. The first param is it's strength, second is how many pixels it affects. I found that negative numbers for the 2nd param, pulls the deblock to far from the edge of the block. basically defeating the purpose of using it. I tested disabling deblock and didn't like the outcome.

Try adding these settings: --ref 6 --ctu 32 --qg-size 16
It should be a bit faster and give better quality.

I7 3700 and to be honest it still works ok since I'm not after perfection
For starters I have tried to raise maxmerge and, well, again personally speaking the difference is not worth a 8/9 to 4/5 fps speed drop.
Raising ref and bframes to 5 was a good hint, so thanks also for this.
Deblock..went through a lot of testing in the past months and, to be honest, ended up leaving disabled. Again, my own personal opinion.
Bottom line is that I try to keep things simple, with an eye on speed and not worrying much about final size (happy if files are 30% lighter). By keeping simple I must admit my ignorance, too many parameters to play around with and, also reading over and over white papers, I am all but sure what each one does in combination with others.
Basically I am alost there in terms of speed/details/quality, but at times there's still the impression to look at things through a window, so to speak. Clean glass but there's still something that doesn't match AVC final result. Would need a dehaze filter like in Lightroom
What it still amazes me is how a couple of tweaks (leaving CRF alone) can make a file the half or the double. In there past three days I have had an output of 890megs or 1,9 gigs out of the same original file!
Whatever, I will try to go back and retouch CTU and QG size and see if with latest releases the benefit is worth additional tweaking.
now will try to leave everything as is and run a second encode with early-skip enabled.
Thanks again!

[Motenai Yoda]

Originally Posted by brumsky

I used to us it about a year ago before I started comparing b frames.
--ctu 32 generally provides better quality and is noticeable faster. I use it on almost every encode.
--qg-size <CTU/2> So if your running ctu 32, then it's 16. Faster and generally better quality but less compression.

I tested a lot and imho
b-frames 3-8 don't change too much as the total number of b per gop is about the same
ctu 32 isn't better/faster than 64
qg-size don't has to be ctu/s, ctu 64 + qg-size 8 is legit
reference > 4 can be over level 4/4.1 so you lose compatibility with a lot of hw decoders.