x265 HEVC Encoder

[benwaggoner]

Was quite a treat to watch it again I must say. I wonder what the difference in process was, because it obviously wasn't an easy source to work with.

It's a nice encode too. I've noticed that a number of grainy UHD Blu-rays have issues from time-to-time in that regard. There are a handful of scenes in both Blade Runner and The Fog that completely fall apart. Seems inexcusable given how much space there is to play with. In the case of The Fog, the bit rate actually plummets in the affected scenes.
Grain is essentially uncompressible random noise. It's random spatially and temporally, includes chroma, and is typically very high frequency. So it can use the vast majority of bits encoding a frame, is sensitive to QP differences between I, P, B, and b frames, and is otherwise a worst-case nightmare.

While encoding 4K content might take only 2x the bitrate as 1080p, doing grain is much more linear. 80 Mbps 4K is only twice that of Blu-ray 1080p. There are cases of grain that is quite literally impossible to encode without perceptible artifacts. Heck, just encoding a flat gray slide with JUST grain on it can be very challenging.

And that grain, even in lossless, can be quite distracting to a viewer. There's certainly way more fine detail grain on the Blade Runner Blu-ray than Ridley Scott ever saw when he was working on it, due to perf screens, dimmer projectors, etcetera. And in HDR, it's also way brighter grain than would have been seen before. One risk with SMPTE 2100 HDR is that any filters that assume gamma instead of linear light will do weird high contrast things in high luma, since the code values have much bigger jumps in luma than 709 gamma had. Conversely, low luma might not get enough filtering if processed assuming 709.

[jlpsvk]

i have a strange problem backuping my Hobbs and Shaw UHD... It has HDR10+ and when i extract HDR10+ metadata (tried all version of hdr10plus_parser, extracting from raw HEVC stream) and use it for encode mediainfo is like this...

source:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 419 cd/m2

encoded mediainfo (no info about HDR10, HDR10+) weird, json metadata file us about 139MB:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2094 App 4, Version 1
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 419 cd/m2

[mini-moose]

i have a strange problem backuping my Hobbs and Shaw UHD... It has HDR10+ and when i extract HDR10+ metadata (tried all version of hdr10plus_parser, extracting from raw HEVC stream) and use it for encode

You should read and post on the hdr10+ thread:
https://forum.doom9.org/showthread.php?t=175947&page=5

I think this happens when the hdr10+ json isn't quite right.

[markiemarcus]

Grain is essentially uncompressible random noise. It's random spatially and temporally, includes chroma, and is typically very high frequency. So it can use the vast majority of bits encoding a frame, is sensitive to QP differences between I, P, B, and b frames, and is otherwise a worst-case nightmare.

While encoding 4K content might take only 2x the bitrate as 1080p, doing grain is much more linear. 80 Mbps 4K is only twice that of Blu-ray 1080p. There are cases of grain that is quite literally impossible to encode without perceptible artifacts. Heck, just encoding a flat gray slide with JUST grain on it can be very challenging.



I hadn't really considered the HDR component, that makes sense! Grain compressibility is definitely something I've run into when playing around with x265 on very grainy animation. Assuming semi-transparency as a goal, you're lucky to see a 30-40% reduction at 1080p over x264. That's still pretty good (on the otherwise flat cells the difficulties with grain retention are more obvious). I find live action easier in that regard. You can definitely get there, it just requires some care. I've started leaning towards slightly elevated Psy-rd values (in the range of 2.5 to 3.0), but greatly reduced Psy-RDOQ values (typically below 0.5). I discovered that by accident, but reading through the documentation, it seems that RDOQ by design is less accurate.

With very grainy animated sources, it's quite apparent that RDOQ exaggerates grain coarseness even at the default value of 1.0. It serves a purpose for sure (it's great at maintaining/approximating the motion), I'm just careful with it; it can make a right mess of flat scenes if the grain is intermittent. I've had really good results with CTU 64 and QG 64 in most animated content, grainy or otherwise. I can absolutely see why CTU 64 is the default; I don't find it to cause any difficulties whatsoever with grain retention. Quite the opposite.

The curious thing with The Fog is that the bit rate falls drastically in the troublesome scenes. Seems like an authoring error.

[redbtn]

I've started leaning towards slightly elevated Psy-rd values (in the range of 2.5 to 3.0), but greatly reduced Psy-RDOQ values (typically below 0.5).
What about turning psy-rdoq off? It gives worse results than 0.5? And what values you use for grainy movies? I use psy-rd 2.0 psy-rdoq 1.2 for movies, but I'm still not sure about that, still looking for optimal values.

[markiemarcus]

What about turning psy-rdoq off? It gives worse results than 0.5? And what values you use for grainy movies? I use psy-rd 2.0 psy-rdoq 1.2 for movies, but I'm still not sure about that, still looking for optimal values.

You can reduce it to zero, yes, but you can also change RDOQ Level to 0 which produces different results again IIRC. You may not be able to capture all the grain and detail though. It depends; a lot of the time you can get away with it. This is with --no-sao --selective-sao 0 by the way. It looks nice and the grain is certainly uniform, but it doesn't have the same presence as with some RDOQ. Like I said, it serves a purpose. If the content is super grainy, you can probably get away with reducing Aq-strength quite a bit also.

You'll have to experiment; most of my testing was done on grainy animation so I don't know how that plays out on live action. On the grainiest of animated content, my values are around Psy-rd 4.0, Psy-rdoq 0.20, AQ-strength 0.7, Deblocking -4:-1, Aq mode 1, CRF 19.5. You'll also need to get your deblocking strength down to around -4 (though -3 is often sufficient). The other values are somewhere in between the slow and slower preset but with rect disabled.

Edit: If the source has extremely fine grain, more like dither, I've seen better results from disabling RDOQ entirely (Level 0) and pushing Psy-rd as high as 4.50. RDOQ just seems to make a mess; I don't know why.
Edit 2: --selective-sao 1 is generally speaking safe enough for grain retention.

[Ajvar]

Grain is essentially uncompressible random noise. It's random spatially and temporally, includes chroma, and is typically very high frequency. So it can use the vast majority of bits encoding a frame, is sensitive to QP differences between I, P, B, and b frames, and is otherwise a worst-case nightmare.

While encoding 4K content might take only 2x the bitrate as 1080p, doing grain is much more linear. 80 Mbps 4K is only twice that of Blu-ray 1080p. There are cases of grain that is quite literally impossible to encode without perceptible artifacts. Heck, just encoding a flat gray slide with JUST grain on it can be very challenging.

And that grain, even in lossless, can be quite distracting to a viewer. There's certainly way more fine detail grain on the Blade Runner Blu-ray than Ridley Scott ever saw when he was working on it, due to perf screens, dimmer projectors, etcetera.

I remember years ago when x265 was at stage of v1.6 - 1.7 people complained about default denoising of HEVC. I remember a grey wall all in terrible grain and HEVC encode then made grain disappear like it never existed and without any artificial look. People complained at x265 encoder exactly for this. Just saying.

[Selur]

What is going on here.
Using 2pass encoding:

1st pass:
i:\Hybrid\64bit\ffmpeg.exe -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf scale=out_range=pc -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | i:\Hybrid\64bit\x265.exe --preset slow --log-level 2 --input - --output-depth 10 --y4m --profile main10 --ctu 32 --no-hme --merange 26 --no-rect --max-merge 2 --tskip --no-open-gop --opt-ref-list-length-pps --bframes 5 --rc-lookahead 40 --pass 1 --slow-firstpass --bitrate 4000 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --fast-intra --psy-rd 2.20 --psy-rdoq 1.20 --splitrd-skip --deblock=-2:-2 --selective-sao 2 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --stats "E:\Temp\result_new.stats" --output "E:\Temp\result_new.265"
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\result_new.265
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(11 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 26 / 3 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
x265 [info]: Lookahead / bframes / badapt : 40 / 5 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 4 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-4000 kbps / 0.60
x265 [info]: tools: limit-modes rd=4 psy-rd=2.20 rdoq=2 psy-rdoq=1.20 rskip
x265 [info]: tools: splitrd-skip tskip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock(tC=-2:B=-2) sao
x265 [info]: tools: selective-sao stats-write
x265 [info]: frame I: 3, Avg QP:6.61 kb/s: 6660.13
x265 [info]: frame P: 82, Avg QP:4.37 kb/s: 9294.05
x265 [info]: frame B: 344, Avg QP:8.83 kb/s: 2552.47
x265 [info]: Weighted P-Frames: Y:2.4% UV:1.2%
x265 [info]: consecutive B-frames: 4.7% 0.0% 18.8% 7.1% 1.2% 68.2%

encoded 429 frames in 11.25s (38.14 fps), 3869.80 kb/s, Avg QP:7.96
and then the second pass fails:
i:\Hybrid\64bit\ffmpeg.exe -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf scale=out_range=pc -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | i:\Hybrid\64bit\x265.exe --preset slow --log-level 2 --input - --output-depth 10 --y4m --profile main10 --ctu 32 --no-hme --merange 26 --no-rect --max-merge 2 --tskip --no-open-gop --opt-ref-list-length-pps --bframes 5 --rc-lookahead 40 --pass 2 --bitrate 4000 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --fast-intra --psy-rd 2.20 --psy-rdoq 1.20 --splitrd-skip --deblock=-2:-2 --selective-sao 2 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --stats "E:\Temp\result_new.stats" --no-dynamic-refine --refine-ctu-distortion 0 --output "E:\Output\result_new.265"
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Output\result_new.265
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(11 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [error]: different scenecut setting than first pass (40 vs 40)
x265 [error]: failed to open encoder[/code]

x265 [error]: different scenecut setting than first pass (40 vs 40)
40 isn't 40 ?!?

When using a FullHD samples the line with the warning disappears, but the error remains.

Tried multiple sample, with different characteristics, error stays the same, so this does not seem to be source related.

=> Does anyone see that I did wrong, or is this a bug?

Cu Selur

[Selur]

Seems like 2pass is broken or I'm really overlooking something.
Even using a simple settings I end up with the 'different scenecut setting than first pass (40 vs 40)'-error.
I:\Hybrid\64bit>ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | x265 --preset medium --input - --output-depth 10 --y4m --profile main10 --pass 1 --slow-firstpass --bitrate 1500 --range limited --colormatrix bt470bg --stats "E:\Temp\test_19_40_50_2910_01.stats" --output "E:\Temp\test.265"
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\test.265
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(6 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
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 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao stats-write
x265 [info]: frame I: 3, Avg QP:13.44 kb/s: 3999.20
x265 [info]: frame P: 119, Avg QP:10.20 kb/s: 3036.26
x265 [info]: frame B: 307, Avg QP:14.84 kb/s: 782.98
x265 [info]: Weighted P-Frames: Y:0.8% UV:0.8%
x265 [info]: consecutive B-frames: 2.5% 0.0% 58.2% 22.1% 17.2%

encoded 429 frames in 10.47s (40.97 fps), 1430.51 kb/s, Avg QP:13.54

I:\Hybrid\64bit>ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | x265 --preset medium --input - --output-depth 10 --y4m --profile main10 --pass 2 --bitrate 1500 --range limited --colormatrix bt470bg --stats "E:\Temp\test_19_40_50_2910_01.stats" --output "E:\Temp\19_40_50_2910_03.265"
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\19_40_50_2910_03.265
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(6 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [error]: different scenecut setting than first pass (40 vs 40)
x265 [error]: failed to open encoder

[redbtn]

Seems like 2pass is broken or I'm really overlooking something.
Even using a simple settings I end up with the 'different scenecut setting than first pass (40 vs 40)'-error.
http://forum.doom9.org/showthread.php?p=1890848
Possible the same issue.

[filler56789]

x265.exe 3.2+17-4a29e0c5bfaf

Download: http://www.mediafire.com/file/ieswxun22o58sga/x265_3.2%252B17-4a29e0c5bfaf.rar/file

FWIW...

In file included from D:/KOMPILES/MCW/x265/source/encoder/encoder.cpp:27:
D:/KOMPILES/MCW/x265/source/encoder/encoder.cpp: In member function 'void x265::Encoder::destroy()':
D:/KOMPILES/MCW/x265/source/common/common.h:222:37: warning: macro expands to multiple statements [-Wmultistatement-macros]
222 | #define X265_FREE_ZERO(ptr) x265_free(ptr); (ptr) = NULL
| ^~~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/encoder.cpp:882:12: note: in expansion of macro 'X265_FREE_ZERO'
882 | X265_FREE_ZERO(m_edgePic);
| ^~~~~~~~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/encoder.cpp:881:9: note: some parts of macro expansion are not guarded by this 'if' clause
881 | if(m_edgePic != NULL)
| ^~

:confused:

[Selur]

found an issue about 2pass crashing (https://bitbucket.org/multicoreware/x265/issues/524/2-pass-encoding-failure-with-32-15)
->
scenecut-aware-qp=0 (default) fails
scenecut-aware-qp=1 works

hopefully they will fix this soon,....

[LigH]

@filler56789: Known and about to be fixed (it's really just a question of C source formatting).

[Selur]

'scenecut-aware-qp'-bug is fixed :)

[filler56789]

x265.exe 3.2+18-f0fe46ce379d

(64-bit, multilib, GCC 9.2.0)

http://www.mediafire.com/file/bqmxz9qczu7c8sm/x265_3.2%252B18-f0fe46ce379d.rar/file

[Boulder]

Some new stuff there I see, has anyone made any tests? Once again there are no use cases available from the devs.

[filler56789]

Pooja Venkatesan committed a4e060a

2019-09-11

Add option hme-range to modify search range for HME levels L0, L1 and L2.

https://bitbucket.org/multicoreware/x265/commits/a4e060a4483913e28df2ce8b8549f3ba8b63ac5a

Download the .EXE from: http://msystem.waw.pl/x265/

[_kermit]

those are my current parameters for 1080p encoding and I'll use between CRF 18 to 22, depending on the source material

--preset slow --vbv-maxrate 20000 --deblock=-6:-6 --no-strong-intra-smoothing --amp --aq-strength 1.25 --qcomp 0.7 --no-deblock --no-sao --rskip --output-depth 10

in general I get good results but once in a while there are artifacts, particular in dark areas, looking like this:
(in this case it was CRF 22)

17045

two questions:

any suggestions on improving my parameters in general?

Is there a parameter which would improve in particular on that (besides a lower CRF value of course)?

cheers, roland

[Boulder]

--aq-mode 3 is meant to battle issues with dark areas of the frame. You may want to tune the strength down though, the bitrate will most likely shoot through the roof :)

[markiemarcus]

those are my current parameters for 1080p encoding and I'll use between CRF 18 to 22, depending on the source material

--preset slow --vbv-maxrate 20000 --deblock=-6:-6 --no-strong-intra-smoothing --amp --aq-strength 1.25 --qcomp 0.7 --no-deblock --no-sao --rskip --output-depth 10

in general I get good results but once in a while there are artifacts, particular in dark areas, looking like this:
(in this case it was CRF 22)

17045

two questions:

any suggestions on improving my parameters in general?

Is there a parameter which would improve in particular on that (besides a lower CRF value of course)?

cheers, roland

As mentioned above, I'd also look at Aq mode 3 with the default AQ strength. You may even be able to get better results (at the same file size) with around 0.85, even lower if the source is very grainy.

Additionally, I have yet to see any real detail benefit to no-strong-intra-smoothing. I'd also avoid disabling deblocking and, if grain retention is still a priority, use some light deblocking instead. I've had good results with -4: -1 and -3: -3, with the former being slightly better IMO.

--selective-sao 1 also seems to work well from my testing, subjectively better than disabling it entirely IMO.

[_kermit]

As mentioned above, I'd also look at Aq mode 3 with the default AQ strength. You may even be able to get better results (at the same file size) with around 0.85, even lower if the source is very grainy.

Additionally, I have yet to see any real detail benefit to no-strong-intra-smoothing. I'd also avoid disabling deblocking and, if grain retention is still a priority, use some light deblocking instead. I've had good results with -4: -1 and -3: -3, with the former being slightly better IMO.

--selective-sao 1 also seems to work well from my testing, subjectively better than disabling it entirely IMO.

thanks both.

I've gathered those parameters from many sources, and honestly have mostly no clue about the impact.

Something like this?

--preset slow --vbv-maxrate 20000 --deblock=-4:-1 --amp --aq-strength 0.85 --qcomp 0.7 --selective-sao 1 --rskip --output-depth 10 --Aq-mode 3

I don't care about grain. Grain is IMO just noise.
And while I understand that old material just has to have grain I don't understand why there is grain in newer material.

If grain can be reduced without having other negative effects on a movie, that would also be fine.
I don't analyze still pics, I don't see a point there. I'm not watching still pics.

would the above be a good compromise, sufficient, or is there more to fine tune?

-roland

[markiemarcus]

thanks both.

I've gathered those parameters from many sources, and honestly have mostly no clue about the impact.

Something like this?

--preset slow --vbv-maxrate 20000 --deblock=-4:-1 --amp --aq-strength 0.85 --qcomp 0.7 --selective-sao 1 --rskip --output-depth 10 --Aq-mode 3

I don't care about grain. Grain is IMO just noise.
And while I understand that old material just has to have grain I don't understand why there is grain in newer material.

If grain can be reduced without having other negative effects on a movie, that would also be fine.
I don't analyze still pics, I don't see a point there. I'm not watching still pics.

would the above be a good compromise, sufficient, or is there more to fine tune?

-roland

It's very difficult to compare without 2-pass, but I'd also ditch qcomp 0.7 . Between that and the Aq strength changes, bitrate at CRF 22 is going to drop quite a lot, so I'd maybe look at using a lower CRF. Maybe start around CRF 20.5 and see how you get on?

Perhaps keep AQ strength at the default of 1.0 for the time being. You really need 2-pass and short scene tests to find the optimal value.

[Boulder]

Losing grain means also losing details, but --selective-sao 1 probably helps with that. SAO used to be one option to disable (I still disable it completely myself), because it just smoothed everything. Otherwise, your settings should be a good basis. I don't know much about the inner workings of the deblocking feature, but I use --deblock -2:-2 myself.

[markiemarcus]

Losing grain means also losing details, but --selective-sao 1 probably helps with that. SAO used to be one option to disable (I still disable it completely myself), because it just smoothed everything. Otherwise, your settings should be a good basis. I don't know much about the inner workings of the deblocking feature, but I use --deblock -2:-2 myself.

Deblock -2:-2 usually looks nice from my testing also. I'd definitely give --selective-sao 1 a try. Helps with a few rough edges. You can really see the grain smearing start to kick in with --selective-sao 2 though.

[_kermit]

Deblock -2:-2 usually looks nice from my testing also. I'd definitely give --selective-sao 1 a try. Helps with a few rough edges. You can really see the grain smearing start to kick in with --selective-sao 2 though.

I've tried this on a 1 min. clip:

--vbv-maxrate 15000 --deblock=-2:-2 --amp --aq-strength 0.85 --selective-sao 1 --rskip --output-depth 10 --aq-mode 3

with CRF 18-22 in 1.0 steps.

CRF 18 results in 5.1Mbit/s (the original has 37Mbit), but all still have the same issue.

Anything else that can help?
Obviously otherwise only using very high bitrate might solve this or not re-encoing at all or accepting that this might happen.

[markiemarcus]

I've tried this on a 1 min. clip:

--vbv-maxrate 15000 --deblock=-2:-2 --amp --aq-strength 0.85 --selective-sao 1 --rskip --output-depth 10 --aq-mode 3

with CRF 18-22 in 1.0 steps.

CRF 18 results in 5.1Mbit/s (the original has 37Mbit), but all still have the same issue.

Anything else that can help?
Obviously otherwise only using very high bitrate might solve this or not re-encoing at all or accepting that this might happen.

Perhaps stick with the default Aq strength for the time being. CRF 18 with Aq mode 3 really should look good.

I take it you're running the latest build?

In the interest of narrowing the problem down, maybe try the "slower" preset. I'd also see if --qg-size 64 can help and there's always good old Aq-mode 1.

Is the source very grainy?

[Boulder]

Have you checked the original closely so that it doesn't have the same issue there? Re-encoding could easily amplify it.
It could be worth a try applying an anti-banding filter just to see if it changes the situation.

[_kermit]

Perhaps stick with the default Aq strength for the time being. CRF 18 with Aq mode 3 really should look good.

I take it you're running the latest build?

In the interest of narrowing the problem down, maybe try the "slower" preset. I'd also see if --qg-size 64 can help and there's always good old Aq-mode 1.

Is the source very grainy?

Tried now:

--vbv-maxrate 15000 --deblock=-2:-2 --amp --selective-sao 1 --rskip --output-depth 10 --aq-mode 3 --qg-size 64 --preset slower --crf 20

and

--vbv-maxrate 15000 --deblock=-2:-2 --amp --selective-sao 1 --rskip --output-depth 10 --aq-mode 1 --qg-size 64 --preset slower --crf 18

yes, 3.2.0.18

still shows. It may be less, but still obvious

Interesting part is that it only is that obvious on that region with black/purple texture

it is grainy, but there is worse.

does it help uploading the original and encoded clip?
Onedrive working?

[_kermit]

Have you checked the original closely so that it doesn't have the same issue there? Re-encoding could easily amplify it.
It could be worth a try applying an anti-banding filter just to see if it changes the situation.

the original doesn't have that.

I have no idea how to apply such a filter :)

[Boulder]

A source clip can always be useful. Easier to see what's really happening.

[_kermit]

A source clip can always be useful. Easier to see what's really happening.

see if you can access that (uploading):

https://1drv.ms/u/s!AuVhsELqus7qlI9EOnijrFpkHGSG-g?e=GuXnag

cheers, roland

[Boulder]

see if you can access that (uploading):

https://1drv.ms/u/s!AuVhsELqus7qlI9EOnijrFpkHGSG-g?e=GuXnag

cheers, roland

What frame is the one that shows the issue best? I'm not seeing anything specific in my encode at CRF 18, preset slower and slight tweaks.

[_kermit]

What frame is the one that shows the issue best? I'm not seeing anything specific in my encode at CRF 18, preset slower and slight tweaks.

at 24 seconds, the woman in the middle.

But I've just changed the monitor I play the video on and the other isn't doing it, at least I can't see it.
When using another preset on the first display, I also don't see it anymore.
Can just the preset of a monitor cause that?
(I don't watch them on those, they are just for checking)

[Boulder]

Yes, it's very much possible. Different calibrations or settings can change the image a lot, so you're always on the safe side if you can check it on the display where you will be watching the final video. Of course, for most of us it's not very convenient.

[_kermit]

Yes, it's very much possible. Different calibrations or settings can change the image a lot, so you're always on the safe side if you can check it on the display where you will be watching the final video. Of course, for most of us it's not very convenient.

so, I guess all the fuss for nothing. Sorry for that.

[markiemarcus]

at 24 seconds, the woman in the middle.

But I've just changed the monitor I play the video on and the other isn't doing it, at least I can't see it.
When using another preset on the first display, I also don't see it anymore.
Can just the preset of a monitor cause that?
(I don't watch them on those, they are just for checking)

It's quite a difficult scene, especially leading up to that point. It's prone to grain freezing in the exterior shots and the level is low enough that RDOQ makes it appear more coarse and boxy than it actually is. I've run into this on animated sources that make heavy use of dither. The establishing shot of the bar @ 9 seconds in the red/brown sky is great example. RDOQ level 2 makes a mess of it, even at the default value. If you increase either (Psy-rd or Psy-RDOQ), the situation gets even worse. I'm getting more pleasing and accurate results from RDOQ Level 0, maxing out Psy-rd, and using a lower CRF to arrive at the same file size. Is RDOQ really supposed to behave like this? Because it also blows up the filesize so I can't see how it can be efficiency related.

Default RDOQ and Psy settings:
https://i.ibb.co/vBbXhkh/Psy2-RDOQ1.png

RDOQ Level 0, Psy-rd 5:
https://i.ibb.co/cFK5JhV/RDOQLevel0-Psy5.png

Aq mode 1 is coming out ahead for me. Default AQ strength seems fine.

Grain motion in the exterior shots is definitely helped with --rd 6.

[markiemarcus]

so, I guess all the fuss for nothing. Sorry for that.

I read somewhere on here a while back that 10-bit playback on 8-bit displays can be a little unpredictable.

[_kermit]

I read somewhere on here a while back that 10-bit playback on 8-bit displays can be a little unpredictable.

that does make sense :)

[microchip8]

@_kermit

I can't see anything in your picture you posted (haven't checked the sample yet). Maybe it's a monitor calibration issue?

[_kermit]

@_kermit

I can't see anything in your picture you posted (haven't checked the sample yet). Maybe it's a monitor calibration issue?

it seems what I saw was related to the display used.

[benwaggoner]

I read somewhere on here a while back that 10-bit playback on 8-bit displays can be a little unpredictable.Yeah. If a display controller truncates instead of dithers, you might get more banding than if the conversion to 8-bit was done pre-encode.

Sent from my SM-T837V using Tapatalk

[benwaggoner]

Tried now:



--vbv-maxrate 15000 --deblock=-2:-2 --amp --selective-sao 1 --rskip --output-depth 10 --aq-mode 3 --qg-size 64 --preset slower --crf 20



and



--vbv-maxrate 15000 --deblock=-2:-2 --amp --selective-sao 1 --rskip --output-depth 10 --aq-mode 1 --qg-size 64 --preset slower --crf 18



yes, 3.2.0.18



still shows. It may be less, but still obvious



Interesting part is that it only is that obvious on that region with black/purple texture



it is grainy, but there is worse.



does it help uploading the original and encoded clip?

Onedrive working?If it is in black/purple, try --aq-mode 3. It doesn't take much blocking in the very low luma range to show up as an artifact with 8-bit SDR.

Sent from my SM-T837V using Tapatalk

[alexantr]

...I'm getting more pleasing and accurate results from RDOQ Level 0, maxing out Psy-rd, and using a lower CRF to arrive at the same file size...

rdoq-level=1 can help to retain small noise looking like dither noise. Keep original psy-rd value and try to tune psy-rdoq from 0.5 to 1.0.

[markiemarcus]

rdoq-level=1 can help to retain small noise looking like dither noise. Keep original psy-rd value and try to tune psy-rdoq from 0.5 to 1.0.

Oh definitely, Level 1 I've had better experience with in the past, particularly at lower values of around 0.5. I'm just scratching my head as to why the default is Level 2; I'm struggling to see any positives. It's also slower IIRC.

However, even with Level 1, RDOQ at 1.0 and Psy-rd at 2.0, I'm able to get better grain motion and more consistent results at the same filesize with Level 0 and massively elevated Psy-rd values instead.

It just doesn't seem right. Surely I'm not the only one who's finding this?

[RainyDog]

Oh definitely, Level 1 I've had better experience with in the past, particularly at lower values of around 0.5. I'm just scratching my head as to why the default is Level 2; I'm struggling to see any positives. It's also slower IIRC.

However, even with Level 1, RDOQ at 1.0 and Psy-rd at 2.0, I'm able to get better grain motion and more consistent results at the same filesize with Level 0 and massively elevated Psy-rd values instead.

It just doesn't seem right. Surely I'm not the only one who's finding this?

Frustratingly there's just no perfect PSY/RDOQ setting with x265 unfortunately :(

But hours (probably amounting to days...) of testing has led me to conclude that the most balanced for most sources at mid-high bitrates is usually psy-rd 1.0, psy-rdoq 1.0 and rdoq-level 2.

I know what you mean with rdoq-level 0 though... In motion, it can look the most consistent and easiest on the eye. But if you compare encode frames to source frames you'll never get transparency with level 0. There seems to be some high-pass filter that sort of dulls grain and high-frequency detail even with psy-rd turned up to 5.0.

With rdoq-level 2 and psy-rd 1.0 plus psy-rdoq 1.0, you can usually see that it at least tries to replicate the source even if that can lead to ugly and sometimes weird artifacts if your bitrate isn't sufficient enough to support it.

As for rdoq-level 1, I find this to just be a rougher, less refined or accurate level 2.

If you can get your hands on any internal 'haich dee bits' x265 encodes for, ahem, research purposes then you'll find that they all use rdoq-level 2 with psy-rd 1.0 and psy-rdoq 1.0. Give or take anyway... I've seen psy-rd 1.2 + psy-rdoq 1.1 and psy-rd 1.4 + psy-rd 1.0 but always within those boundries.

They always consistently use no-cutree and usually qg-size 8 too. AQ mode 1 or 3 and often lots of zones as well. EDIT: and always CTU 32 and no-rskip.

[markiemarcus]

Frustratingly there's just no perfect PSY/RDOQ setting with x265 unfortunately :(

But hours (probably amounting to days...) of testing has led me to conclude that the most balanced for most sources at mid-high bitrates is usually psy-rd 1.0, psy-rdoq 1.0 and rdoq-level 2.

I know what you mean with rdoq-level 0 though... In motion, it can look the most consistent and easiest on the eye. But if you compare encode frames to source frames you'll never get transparency with level 0. There seems to be some high-pass filter that sort of dulls grain and high-frequency detail even with psy-rd turned up to 5.0.

With rdoq-level 2 and psy-rd 1.0 plus psy-rdoq 1.0, you can usually see that it at least tries to replicate the source even if that can lead to ugly and sometimes weird artifacts if your bitrate isn't sufficient enough to support it.

As for rdoq-level 1, I find this to just be a rougher, less refined or accurate level 2.

If you can get your hands on any internal 'haich dee bits' x265 encodes for, ahem, research purposes then you'll find that they all use rdoq-level 2 with psy-rd 1.0 and psy-rdoq 1.0. Give or take anyway... I've seen psy-rd 1.2 + psy-rdoq 1.1 and psy-rd 1.4 + psy-rd 1.0 but always within those boundries.

They always consistently use no-cutree and usually qg-size 8 too. AQ mode 1 or 3 and often lots of zones as well. EDIT: and always CTU 32 and no-rskip.

There is definitely some sort of lpf noticeable with level 0 and I totally agree that achieving transparency is pretty much impossible that way. But I still think that subjectively it often looks better, almost always so if you're trying to preserve dither. I don't mind the slight dulling of grain assuming what is there is uniform, the pitch fine and the resulting encode looks nice. It's so impressive to see the bitrate reduction you can achieve, even on grainy content, at bitrates where x264 completely falls apart.

I'm just seeing a lot of instances where RDOQ looks pretty nasty, regardless of the bit rate or values used.

Will definitely check out your suggestions though. Appreciate it.

[Yanak]

Hello,

is anyone having issues trying to build with Intel compiler 2019 integrated in Visual studio 2019 ?

Building the multilib with VS 2019 works,
building the multilib with LLVM Clang integrated inside Visual Studio 2019 works too, ( either the clang 9.0.0.0 version from the VS2019 installer or the last 10.0.0 version of LLVM installed separately and integrated in VS2019 with the LLVM2019 extension from the VS Marketplace. )

But trying to use the Intel compiler brings loads of errors and the build fails, tried also to make the single 10Bits build and it fails too.

Was able to use ICC 2019 inside VS2017 some months ago and it was building correctly so I'm not sure if it's a problem on my side only or more general issue on the code, but after dozen of tries i can't find out what is wrong with Intel compiler so i ask here in case anyone have an idea.

Thank you .

[_kermit]

Frustratingly there's just no perfect PSY/RDOQ setting with x265 unfortunately :(

But hours (probably amounting to days...) of testing has led me to conclude that the most balanced for most sources at mid-high bitrates is usually psy-rd 1.0, psy-rdoq 1.0 and rdoq-level 2.

I know what you mean with rdoq-level 0 though... In motion, it can look the most consistent and easiest on the eye. But if you compare encode frames to source frames you'll never get transparency with level 0. There seems to be some high-pass filter that sort of dulls grain and high-frequency detail even with psy-rd turned up to 5.0.

With rdoq-level 2 and psy-rd 1.0 plus psy-rdoq 1.0, you can usually see that it at least tries to replicate the source even if that can lead to ugly and sometimes weird artifacts if your bitrate isn't sufficient enough to support it.

As for rdoq-level 1, I find this to just be a rougher, less refined or accurate level 2.

If you can get your hands on any internal 'haich dee bits' x265 encodes for, ahem, research purposes then you'll find that they all use rdoq-level 2 with psy-rd 1.0 and psy-rdoq 1.0. Give or take anyway... I've seen psy-rd 1.2 + psy-rdoq 1.1 and psy-rd 1.4 + psy-rd 1.0 but always within those boundries.

They always consistently use no-cutree and usually qg-size 8 too. AQ mode 1 or 3 and often lots of zones as well. EDIT: and always CTU 32 and no-rskip.

can you provide the complete command line you prefer?

[RainyDog]

can you provide the complete command line you prefer?

Sure, the below is always my starting point then I tweak from there if necessary with a dial or two down on --aq-strength and/or a notch or two up on --psy-rd. This is for a broad range of film sources at 1080p resolution.

--preset slow --output-depth 10 --rd 3 --ctu 32 --limit-refs 1 --limit-tu 4 --tu-intra-depth 4 --tu-inter-depth 4 --no-rect --b-intra --aq-mode 1 --aq-strength 0.9 --ipratio 1.3 --pbratio 1.2 --no-cutree --subme 4 --merange 40 --max-merge 4 --weightb --bframes 10 --rc-lookahead 60 --lookahead-slices 0 --deblock -3:-3 --selective-sao 0 --no-sao --psy-rd 1.0

[redbtn]

They always consistently use no-cutree and usually qg-size 8 too. AQ mode 1 or 3 and often lots of zones as well. EDIT: and always CTU 32 and no-rskip.
I often see this also. But I don't understand why they use it. I did tests and noticed that CTU 32 and qg-size 8 is not better than CTU 64 qg-size 32 (and sometimes even worse). And also it seems to me that aq-mode 2 is better than 1. I'm not a professional, it's only my humble opinion.
Ps: I looked at your settings, do you sure that ctu 32 merange 40 is better for 1080p than ctu 64 merange 57?