x265 HEVC Encoder

[brumsky]

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]

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]

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]

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]

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]

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]

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]

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

Possibly with Elecard HEVC Analyzer :)

[pingfr]

Possibly with Elecard HEVC Analyzer :)

Got a download link for that matey? ;)

[Dclose]

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]

@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]

@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]

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]

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]

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.

[brumsky]

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!

I was just curious what CPU you were running that's all. It's not AVX2 so CTU 64 will receive a performance penalty because of that.

Give the other options a try it'll be a little faster. Don't worry about max merge, ref 6 will improve the quality and ctu 32 & qg-size 16 will speed it up.

[brumsky]

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.

Your right increased b frames won't make a huge difference but it does affect the outcome.

CTU 32 is absolutely faster than ctu 64 especially for non-AVX2 CPUs like the 3700 - hence why I asked what CPU he has.

I never said qg-size has to be ctu/2. I said that is what I like to do. it is a compression\speed trade off.

This is the first I've ever heard of ref > 4 can be over any level. The levels 4 & 4.1 are for other things like bitrates & resolutions. You're thinking of ref > 8 which the encoder generates a error and exits, unless you specify --allow-non-conformance.

Taken from the docs:
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


Read this for a quick review on Levels.

https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels

[Jamaika]

Recently one thing I am wondering. When converting yuv 422 10bit for the preset veryslow I have a darker film. For x264 10bit (selur) is fine.
Too bad, apparently the codec does so, but from the curiosity I changed the preset medium and it is correct. Interesting.

[Ma]

Recently one thing I am wondering. When converting yuv 422 10bit for the preset veryslow I have a darker film. For x264 10bit (selur) is fine.
Too bad, apparently the codec does so, but from the curiosity I changed the preset medium and it is correct. Interesting.

Could you specify your command line and sample video to reproduce?

[Jamaika]

ffmpeg.exe -loglevel error -i rgb.avi -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=pc:out_color_matrix=bt2020_nc:out_range=pc,format=yuv422p10le -strict -1 - |
x265-10b.exe --y4m --input-csp i422 --input-depth 10 --output-depth 10 --preset medium/veryslow --fps 29.970 --keyint 60 --info --no-open-gop --no-hrd --bitrate 6000
--colormatrix bt2020nc --range full --limit-tu 0 --output "output.h265" -
I mean that the colors are more dull, unnatural.
Codec:http://msystem.waw.pl/x265/x265-2.3+25-6e1edaf_gcc63.7z

[sneaker_ger]

Sample files and maybe screenshots that show the difference?

[Ma]

I mean that the colors are more dull, unnatural.

In my tests movie with --preset medium has bitrate 6005.89 kb/s, with preset veryslow 5180.42 kb/s. My movie is from 6 jpeg (each is repeated 10 times) and there is no problem with quality.

I think that your problem maybe is related with special source -- could you copy encoders outputs (my is for example)f:\speed\422>ffmpeg.exe -loglevel error -i img%02d.jpg -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=pc:o
ut_color_matrix=bt2020_nc:out_range=pc,format=yuv422p10le -strict -1 - | x265-10b.exe --y4m --input-csp i422 --fps 8 --input-d
epth 10 --output-depth 10 --preset medium --keyint 60 --info --no-open-gop --no-hrd --bitrate 6000 --colormatrix bt2020nc --rang
e full --limit-tu 0 --output "om.hevc" -
y4m [info]: 1920x1080 fps 8000/1000 i422p10 sar 9:10 unknown frame count
raw [info]: output file: om.hevc
x265 [info]: HEVC encoder version 2.3+25-6e1edafd6dc7
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 6 / 60 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-6000 kbps / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao
x265 [info]: frame I: 6, Avg QP:8.44 kb/s: 59906.54
x265 [info]: frame P: 18, Avg QP:15.30 kb/s: 28.33
x265 [info]: frame B: 36, Avg QP:18.50 kb/s: 11.23
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 45.8% 12.5% 8.3% 12.5% 20.8%

encoded 60 frames in 13.26s (4.52 fps), 6005.89 kb/s, Avg QP:16.53

f:\speed\422>ffmpeg.exe -loglevel error -i img%02d.jpg -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=pc:o
ut_color_matrix=bt2020_nc:out_range=pc,format=yuv422p10le -strict -1 - | x265-10b.exe --y4m --input-csp i422 --fps 8 --input-d
epth 10 --output-depth 10 --preset veryslow --keyint 60 --info --no-open-gop --no-hrd --bitrate 6000 --colormatrix bt2020nc --ra
nge full --limit-tu 0 --output "ov.hevc" -
y4m [info]: 1920x1080 fps 8000/1000 i422p10 sar 9:10 unknown frame count
raw [info]: output file: ov.hevc
x265 [info]: HEVC encoder version 2.3+25-6e1edafd6dc7
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 6 / 60 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-6000 kbps / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: rskip signhide tmvp b-intra strong-intra-smoothing deblock
x265 [info]: tools: sao
x265 [info]: frame I: 6, Avg QP:9.72 kb/s: 51056.41
x265 [info]: frame P: 10, Avg QP:14.63 kb/s: 401.45
x265 [info]: frame B: 44, Avg QP:19.23 kb/s: 10.73
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 50.0% 0.0% 0.0% 25.0% 0.0% 0.0% 0.0% 0.0% 25.0%

encoded 60 frames in 55.98s (1.07 fps), 5180.42 kb/s, Avg QP:17.51
or even better sample source?

[raymondjpg]

2-pass or --tune grain (1-pass). Which of these two options is likely to deliver the best quality improvement over 1-pass (without --tune grain)? Using both together takes forever.

[Boulder]

--tune grain omits --rskip. Try adding that one back and see what happens both performance and quality-wise. I use it with --tune grain and have not noticed any difference in the quality of the result.

[Jamaika]

I think that your problem maybe is related with special source -- could you copy encoders outputs (my is for example)
Sorry. I have a problem with the player. I have to reinstall and install the latest lavvideo.

[raymondjpg]

--tune grain omits --rskip. Try adding that one back and see what happens both performance and quality-wise. I use it with --tune grain and have not noticed any difference in the quality of the result.
Thanks for the tip. That certainly speeds things up, but my original question remains. Say for argument, with the same bitrate set, which of the two options - 2-pass or --tune grain (1-pass) - is likely to deliver the best quality improvement over 1-pass (without --tune grain)? Put another way, does 2-pass deliver anything like the quality improvement benefit ascribed to --tune grain? If it doesn't, then I could resort to just using --tune grain with or without --rskip.

[LigH]

For 1-pass, you better don't set a bitrate, but a quality level (CRF) instead. A 1-pass encoding with constant/average bitrate will not distribute the quality optimally.

Grain tuning changes the behaviour of the encoder in several ways. It moves the focus towards elements with higher frequencies, taking available bitrate from the lower frequency parts of the image – which are usually responsible for the base quality of the whole frame. If you want to keep the bitrate in the same range as without, enabling grain tuning will probably give you more details (including noise) at the cost of more compression artifacts.

2-pass encoding is only important if you want to approach a specific size or stay below a maximum bitrate (in conjunction with VBV parameters). If you have no size or bitrate restrictions, there is no need for it. Just complying to VBV restrictions is even possible in a 1-pass encoding mode. 2-pass encoding is no alternative to grain tuning; the encoder behaves differently. A 1-pass CRF encoding and a 2-pass encoding with the same final size will have almost the same quality distribution; grain tuning will look differently to both of them.

[raymondjpg]

For 1-pass, you better don't set a bitrate, but a quality level (CRF) instead. A 1-pass encoding with constant/average bitrate will not distribute the quality optimally.

Grain tuning changes the behaviour of the encoder in several ways. It moves the focus towards elements with higher frequencies, taking available bitrate from the lower frequency parts of the image – which are usually responsible for the base quality of the whole frame. If you want to keep the bitrate in the same range as without, enabling grain tuning will probably give you more details (including noise) at the cost of more compression artifacts.

2-pass encoding is only important if you want to approach a specific size or stay below a maximum bitrate (in conjunction with VBV parameters). If you have no size or bitrate restrictions, there is no need for it. Just complying to VBV restrictions is even possible in a 1-pass encoding mode. 2-pass encoding is no alternative to grain tuning; the encoder behaves differently. A 1-pass CRF encoding and a 2-pass encoding with the same final size will have almost the same quality distribution; grain tuning will look differently to both of them.
Thanks for that explanation. I have found CRF to be preferable as far as quality is concerned, but resulting file size is variable depending on the complexity and detail of the source material. I mostly recompress for archiving so prefer to limit file size by setting an ABR.

Until recently I gave been recompressing using ABR with H264 limited to --threads 4, and my understanding is that 2-pass with H264 does not deliver any significant quality improvement over single pass.

However I have read that 2-pass encoding can give up to 18% quality improvement over a single pass with H265, so is that right?

[LigH]

1-pass CRF and 2-pass VBR with the same target size will have very similar results. This will be true for both x264 and x265 encoders. I am not sure if x265 will behave noticably different than x264 when comparing a 1-pass CRF result with a 2-pass VBR result of the same size (and I don't understand how you would measure a quality difference to be 18%, as quality is subjective) ... but I am quite sure that for both encoders, a 1-pass ABR encode will not have an optimal quality distribution, as it is rather focused on a less varying bitrate (e.g. useful for the constraints of a limited bandwidth and limited decoding buffer).

[raymondjpg]

1-pass CRF and 2-pass VBR with the same target size will have very similar results. This will be true for both x264 and x265 encoders. I am not sure if x265 will behave noticably different than x264 when comparing a 1-pass CRF result with a 2-pass VBR result of the same size (and I don't understand how you would measure a quality difference to be 18%, as quality is subjective) ... but I am quite sure that for both encoders, a 1-pass ABR encode will not have an optimal quality distribution, as it is rather focused on a less varying bitrate (e.g. useful for the constraints of a limited bandwidth and limited decoding buffer).
Thanks. I think I'm convinced now that a 2-pass H265 encode is likely to be preferable to a single pass ABR encode set at the same bitrate, and that is where a quality improvement however it is determined or perceived would come in.

[x265_Project]

If you're doing 2 pass encodes, I would suggest that you try our new --multi-pass-opt-distortion option. Without this option, x265 will simply normalize quality on a frame-by-frame basis. With --multi-pass-opt-distortion, x265 will also adjust quality within each frame, on a block-by-block basis, by analyzing the quality of each encoded block from the first pass compared to the source video, increasing the quality of blocks with abnormally high distortion, borrowing bits from blocks with below-average distortion (higher than average quality). So, basically, --multi-pass-opt-distortion is a finer-grained version of 2 pass, where we are leveling quality spatially as well as temporally. We look forward to your feedback.

[Boulder]

Just wondering, are there pending quality improvements in the 10-bit lambda tables? I have a longish queue of stuff to process but I'd like to hold them if there is something in the pipeline for the near future.

[x265_Project]

Just wondering, are there pending quality improvements in the 10-bit lambda tables? I have a longish queue of stuff to process but I'd like to hold them if there is something in the pipeline for the near future.
Yes. Soon. Some time next week.

[Boulder]

Yes. Soon. Some time next week.Thank you for the information, it's much appreciated :)

[Barough]

x265 v2.3+28-08a05ca9fd16 (http://www44.zippyshare.com/v/49We8PLL/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+28-08a05ca9fd16
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

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

[aegisofrime]

Yes. Soon. Some time next week.

While we are on topic, are the tables for 12-bit coming at the same time? No pressure :)

[need4speed]

Hi again, I have been playing around a lot with CRF lately so question would be: there is any way to roughly predict the average final video kbs starting from original kbs, duration and qcomp or whatever else?
All same settings and crf but:
Example 1 : 40 mins, 9000 kbs I end up with 2300kbs hevc file.
Example 2 : 40 mins, 13000 kbs I end up with 4900 kbs 2.4 gigs.
I fully understand how crf works but wondering if 9000 to 2300 kbs might mean loose too much quality.


Inviato dal mio GT-N7100 utilizzando Tapatalk

[LigH]

No panic. You understood CRF? Then you understood that it will use only as much bitrate as the video material needs to preserve "enough" quality.

40 minutes of action, motion, details: High bitrate is required.

40 minutes of stills, slack, blur: Low bitrate is sufficient.

[need4speed]

No panic. You understood CRF? Then you understood that it will use only as much bitrate as the video material needs to preserve "enough" quality.

40 minutes of action, motion, details: High bitrate is required.

40 minutes of stills, slack, blur: Low bitrate is sufficient.
Thanks as usual Ligh,
No panic at all and I must admit the perceived quality is satisfactory as expected.
Was just wondering if there was any way to somehow have a rough idea about final kbs. Out of curiosity, really.
I am about to encode the whole Heroes br set but will wait for 10bits new tables.
Any suggestion for grainy old videos? Somehow heroes videos are grainy and noisy, wondering if the tune grain might help here

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Natty]

currently using these settings for 1080p content and i am impressed with the results. getting low fps though.

--pass 1 --bitrate 3333 --output-depth 10 --rd 4 --rdoq-level 2 --aq-mode 3 --qcomp 1 --multi-pass-opt-analysis --multi-pass-opt-distortion --aq-motion --subme 5 --me star --bframes 8 --rc-lookahead 60 --lookahead-slices 5 --ref 6 --min-keyint 20 --keyint 400 --no-strong-intra-smoothing --no-constrained-intra --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --hdr --vui-timing-info --vui-hrd-info --opt-cu-delta-qp --multi-pass-opt-rps --deblock -3:0 --psy-rd 4 --psy-rdoq 8 --opt-qp-pps --opt-ref-list-length-pps

i need comments of experts on this.

:script:

[sneaker_ger]

qcomp 1?

[x265_Project]

currently using these settings for 1080p content and i am impressed with the results. getting low fps though.

--pass 1 --bitrate 3333 --output-depth 10 --rd 4 --rdoq-level 2 --aq-mode 3 --qcomp 1 --multi-pass-opt-analysis --multi-pass-opt-distortion --aq-motion --subme 5 --me star --bframes 8 --rc-lookahead 60 --lookahead-slices 5 --ref 6 --min-keyint 20 --keyint 400 --no-strong-intra-smoothing --no-constrained-intra --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --hdr --vui-timing-info --vui-hrd-info --opt-cu-delta-qp --multi-pass-opt-rps --deblock -3:0 --psy-rd 4 --psy-rdoq 8 --opt-qp-pps --opt-ref-list-length-pps

i need comments of experts on this.

:script:

Are you running 2 passes? If not you don't need --pass 1 or --multi-pass-opt-analysis. You're heavily modifying our default (--preset medium) settings. We recommend you stick with one of our presets, which represent a fairly optimal tradeoff of speed for quality.

For example, you're increasing the # of reference frames from the default setting of 3 frames to --ref 6. This is a big waste of time. You'll get diminishing returns (in terms of quality for the speed impact) with each additional reference frame, and almost no improvement above 4 ref frames. You'll get a better overall result just by moving to a higher quality preset, like --preset slow.

There is no need to use --hdr when you're not encoding high dynamic range content.

[Natty]

Are you running 2 passes? If not you don't need --pass 1 or --multi-pass-opt-analysis. You're heavily modifying our default (--preset medium) settings. We recommend you stick with one of our presets, which represent a fairly optimal tradeoff of speed for quality.

For example, you're increasing the # of reference frames from the default setting of 3 frames to --ref 6. This is a big waste of time. You'll get diminishing returns (in terms of quality for the speed impact) with each additional reference frame, and almost no improvement above 4 ref frames. You'll get a better overall result just by moving to a higher quality preset, like --preset slow.

There is no need to use --hdr when you're not encoding high dynamic range content.

yes its 2 pass. and what about the rest of the settings and qcomp 1? i observed that qccomp 1 helps in retaining grain more. maybe just my illusion.

[elahn]

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.

I've been using --tune grain and this is interesting. Would you still use --tune grain, but override the default psy-rd=4.00 psy-rdoq=10.00? By how much would you lower them? I don't really care about grain, but I do want good detail retention.

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.

Are you using ABR or 2-pass? If so, increased compression due to b-frames would free up extra bits to be used for increased quality.

While it's very useful, I question the general methodology of using ABR or 2-pass for an apples to apples comparison of all parameters. In this case, wouldn't any parameter that increases compression create surplus bits and thus increase quality?

For CRF encodes, I'd like to know which options in the slow/slower/very slow/placebo presets increase quality/detail retention, which increase compression and which can do both.

Personally, the slow preset gives me plenty of compression and most of the time I'm happy with medium preset compression-wise. I am willing to pay for increased quality with slower encoding, but I'd usually prefer to pay for it with increased bitrate (when necessary, not globally). I'm currently investigating rdLevel, references, tu-intra-depth, tu-inter-depth, amp and rc-lookahead... Any insight (in relation to CRF) would be appreciated. IIUC bframes, b-intra and weightb affect compression not quality.

Thanks @x265_Project, it's good to know that ref > 4 gives almost no improvement.

For context, I use: --crf 20 --preset slow --tune grain --profile main10 --no-strong-intra-smoothing --deblock -3:0 --rskip --ctu 32 (no AVX2, 2 core/4 threads 2.1ghz)

[Natty]

Are you running 2 passes? If not you don't need --pass 1 or --multi-pass-opt-analysis. You're heavily modifying our default (--preset medium) settings. We recommend you stick with one of our presets, which represent a fairly optimal tradeoff of speed for quality.

For example, you're increasing the # of reference frames from the default setting of 3 frames to --ref 6. This is a big waste of time. You'll get diminishing returns (in terms of quality for the speed impact) with each additional reference frame, and almost no improvement above 4 ref frames. You'll get a better overall result just by moving to a higher quality preset, like --preset slow.

There is no need to use --hdr when you're not encoding high dynamic range content.


yes its a 2 pass encode in staxrip. what about the rest of my settings like qcomp 1? observed that it helps in retaining more grain, maybe just my illusion.