x265 HEVC Encoder

[brumsky]

Originally Posted by need4speed

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]

Originally Posted by Motenai Yoda

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_E...ers_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]

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

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]

Originally Posted by Jamaika

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]

Originally Posted by Ma

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]

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

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]

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

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]

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

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.

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.

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

Yes. Soon. Some time next week.

[Boulder]

Originally Posted by x265_Project

Yes. Soon. Some time next week.

Thank you for the information, it's much appreciated

[Barough]

x265 v2.3+28-08a05ca9fd16 (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