x265 HEVC Encoder

[LigH]

But "placebo" means "you have to believe in it to see any advantage over sensible presets". Or in other words: Rather a waste of time and energy than a visible advantage.

[sneaker_ger]

Even 57 is probably overkill for 1080p. x264 preset placebo uses 24...

[pingfr]

Even 57 is probably overkill for 1080p. x264 preset placebo uses 24...

Isn't comparing x264 and x265 values more or less equals comparing oranges to eggs? :)

[aymanalz]

Because... these values were the ones taken directly from the placebo presets? :D

There is a reason they call it placebo! :D

Placebo: Anything of no direct benefit which nevertheless makes people feel better or benefit psychologically.

[Boulder]

I did a small test concerning CTU 64 and 32. The source was a short scene from the first The Hobbit movie, mattes cropped and scaled down to 1280x544 with some sharpening to compensate and then very light denoising. This is what I mostly do to the material that I put on my media server.

With my default settings, which also means CTU 64, the bitrate was 3983.05 kbps and average speed 2.38 fps. With CTU 32, the bitrate was 4092.48 kbps and the average speed 2.76 fps.

I really didn't expect the bitrate to change that much at such a low resolution but it's there. The scene itself is fairly detailed, but there's also some sky etc. which could give the 64-pixel CTU something to work on.

[pingfr]

Latest changes:

Increased --crf 18 to --crf 21.
Lowered --ctu 64 to --ctu 32.
Lowered --bframes 8 to --bframes 4.
Lowered --merange 92 to --merange 57.
Lowered --rd 6 to --rd 4.
Lowered --subme 7 to --subme 5.

I'm getting an average of 1.16 fps, my current goal is 2.00 fps.

The remaining values that are untouched are:

--qg-size 32
--deblock -6:-6
--rc-lookahead 60
--tu-intra-depth 4
--tu-inter-depth 4
--scenecut 40
--limit-ref 0
--limit-modes
--max-merge 5

Anything else I could tweak at this point to increase crunching speed without hurting either the efficiency or the quality resulted?

[Boulder]

--tu-intra-depth 3
--tu-inter-depth 3
--limit-refs 3
--max-merge 3

You won't see a visible difference but the encoding will go faster.

[pingfr]

--tu-intra-depth 3
--tu-inter-depth 3
--limit-refs 3
--max-merge 3

You won't see a visible difference but the encoding will go faster.

Tested the suggested values, while it is true it encoded much faster at 2.48 fps and even exceeded my expectations, the water ripples from my sample clip were blocky. That's a no-go for me.

Thanks.

[aymanalz]

Tested the suggested values, while it is true it encoded much faster at 2.48 fps and even exceeded my expectations, the water ripples from my sample clip were blocky. That's a no-go for me.

Thanks.


Try just the limit refs 3.

And if blocking is the only issue you saw, increase the deblocking to -3,-3 or higher. Lowering deblocking by so much from default values, probably causes...blocking.

[pingfr]

Try just the limit refs 3.

x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -6:-6 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing %1 -o %~n1.hevc

x265 [info]: HEVC encoder version 2.3+9-820f4327ddac
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=2.00 tskip signhide tmvp
x265 [info]: tools: b-intra lslices=6 deblock(tC=-6:B=-6)
x265 [info]: frame I: 3, Avg QP:22.55 kb/s: 28882.40
x265 [info]: frame P: 141, Avg QP:23.75 kb/s: 19361.90
x265 [info]: frame B: 456, Avg QP:28.24 kb/s: 6027.66
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: 0.7% 0.0% 0.0% 80.6% 18.8%

encoded 600 frames in 276.47s (2.17 fps), 9275.48 kb/s, Avg QP:27.15

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 20s 0ms
Bit rate : 9 097 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.146
Stream size : 21.7 MiB (98%)
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-6:-6 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt
Default : Yes
Forced : No

Hard to tell.

[darksiderg]

i m using x265 2.3+1-7e225ae stable version. during 720p encode i noticed that my cpu usage was fluctuating from 40% to 80% vice versa. but it never reached 100. i used slow preset. is it normal?

[pingfr]

Try just the limit refs 3.

And if blocking is the only issue you saw, increase the deblocking to -3,-3 or higher. Lowering deblocking by so much from default values, probably causes...blocking.

Trying now with a -3,-3. Will return in a bit with the results.

[Boulder]

Try just the limit refs 3.Or leave the settings as they are and try --rskip. I could never tell if it was better on or off, but encoding is much faster enabled. It will probably increase the bitrate though.

[pingfr]

x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -3:-3 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing %1 -o %~n1.hevc

x265 [info]: HEVC encoder version 2.3+9-820f4327ddac
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=2.00 tskip signhide tmvp
x265 [info]: tools: b-intra lslices=6 deblock(tC=-3:B=-3)
x265 [info]: frame I: 3, Avg QP:22.55 kb/s: 28882.40
x265 [info]: frame P: 141, Avg QP:23.75 kb/s: 19287.13
x265 [info]: frame B: 456, Avg QP:28.23 kb/s: 6014.92
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: 0.7% 0.0% 0.0% 80.6% 18.8%

encoded 600 frames in 264.24s (2.27 fps), 9248.22 kb/s, Avg QP:27.15

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 20s 0ms
Bit rate : 9 071 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.146
Stream size : 21.6 MiB (98%)
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt
Default : Yes
Forced : No

Gained a speed increase of 0.10 fps, resulted file 60KB smaller and saw no differences, these nasty blocks in the water are still there.

Should I try with a -1:-1 deblocking value?

[Boulder]

Try the suggestions one by one and see which one causes the issue.

[pingfr]

Try the suggestions one by one and see which one causes the issue.

It's hard to tell, these "blocks" might as well be present on the source used, but it's in .y4m format I have no software that can open these at all other than x265 itself.

Source is YachtRide from here:

http://ultravideo.cs.tut.fi/#testsequences

[Boulder]

You could encode as lossless and use that to check the frames.

[darksiderg]

i m using x265 2.3+1-7e225ae stable version. during 720p encode i noticed that my cpu usage was fluctuating from 40% to 80% vice versa. but it never reached 100. i used slow preset. is it normal?

[pingfr]

You could encode as lossless and use that to check the frames.

Lossless? is there like a --preset lossless? :)

[sneaker_ger]

--lossless

But there are players that can play .y4m, e.g. MPC-HC + LAV.

[pingfr]

@sneaker_ger: MPC-HC is a clear no-go for me.

https://drdump.com/UploadedReport.aspx?DumpID=13569359&SecondVisit=1

[divxmaster]

Lossless? is there like a --preset lossless? :)

yes, great for comparisons, I create a --lossless sample and a --crf16 sample and compare to the rip I am doing at the time.
Lol, your command line a few posts back is now virtually identical to mine. I use a slightly lower --merange for 1080p
and --aq-mode 2, but apart from that, it is the same.
Also for *some* ultra clean sources, even crf 22 suffices, and is virtually indistinguishable to the crf16 comparison, and not distinguishable at normal viewing distances (48 inch screen, 102 inch screen)

:)

Divxmaster

[aymanalz]

@sneaker_ger: MPC-HC is a clear no-go for me.

https://drdump.com/UploadedReport.aspx?DumpID=13569359&SecondVisit=1

BTW, is there a reason you are not encoding at 10 bits? That improves quality, although it might slow down the encode.

[LigH]

... my cpu usage was fluctuating from 40% to 80% vice versa. but it never reached 100. i used slow preset. is it normal?

Quite normal, yes. The HEVC algorithm as such has only a limited parallelizability. Parts of the encoding need to wait for other parts to finish first. This has been discussed many times before.

[pingfr]

Lol, your command line a few posts back is now virtually identical to mine. I use a slightly lower --merange for 1080p and --aq-mode 2, but apart from that, it is the same.

What would be the benefits of switching to -aq 2?

:)

[pingfr]

BTW, is there a reason you are not encoding at 10 bits? That improves quality, although it might slow down the encode.

Backwards compatibility with "exotic" devices. :)

[divxmaster]

What would be the benefits of switching to -aq 2?

:)

well primarily better quality. Although I haven't tried --aq 1 in recent versions of x265.
Ah, I see you do 8 bit encodes. I only do 10 bit encodes, but I see you use decoding hw that requires 8 bit.

Also, add --no-open-gop, or you *may* have seeking issues.

Cheers,
Divxmaster

[darksiderg]

Quite normal, yes. The HEVC algorithm as such has only a limited parallelizability. Parts of the encoding need to wait for other parts to finish first. This has been discussed many times before.

thanks :)

[aymanalz]

Quite normal, yes. The HEVC algorithm as such has only a limited parallelizability. Parts of the encoding need to wait for other parts to finish first. This has been discussed many times before.

This may be true for CPUs with many cores, but four normal 2 or 4 core processors, I think x265 should saturate all the cores. Especially at the "slow" preset, which is what he is using.

IIRC, the previous discussions were about 12/16 cores, or multiple CPUs not being fully utilized.

@darksiderg : What CPU are you using?

[benwaggoner]

What would be the benefits of switching to -aq 2?

AQ 2 will decrease QP (increasing quality) in dark regions. This increases bitrate some, but helps the blocking-in-black issues, particularly on LCD displays will elevated blacks.

Note only for use with SDR gamma content. It's not appropriate for HDR PQ content, which has many more code values in dark, better matching human perception.

[pingfr]

This increases bitrate some.

--aq 1:

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 2.43 MiB
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

--aq 2:

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 4.77 MiB
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

TL;DR:

--aq 1: 2.43 MiB
--aq 2: 4.77 MiB

That's an almost 100% file size increase, what the flux? :eek:

[Barough]

x265 v2.3+17-6e348252e902 (http://ge.tt/4bua44j2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+17-6e348252e902
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

[LigH]

x265 2.3+17-6e348252e902 (https://www.mediafire.com/file/hipmkgfb61m7y0c/x265_2.3%2B17-6e348252e902.7z)

Now even finer!

--refine-level <1..10> Level of analyis refinement indicates amount of info stored/reused in save/load mode, 1:least....10:most. Default 5

^typo (analy»s«is) already reported...

Not available anymore:

--capture-csp <string> Specify color primaries from bt709, p3d65, bt2020 for the capture device. Default bt709

[benwaggoner]

TL;DR:

--aq 1: 2.43 MiB
--aq 2: 4.77 MiB

That's an almost 100% file size increase, what the flux? :eek:
Sorry, I was talking about aq-mode 2 versus 3.

CRF values aren't going to be particularly consistent across aq-modes, and you can (with a bucket full of caveats) generally raise CRF with more advanced AQ at similar subjective quality.

[Dclose]

Speaking of quality or should we rather call it "detail retention", I see everyone coming up with different custom deblocking values.

Some are like -1:-1 where as others recommend as far as -6:-6, is there a "best" and a "safe" value? or when is actually too much deblocking... well... "too much"?
There definitely can be too much deblocking. Set both to +6 and it can be like putting vaseline on the picture.

That's at low bitrate though. At high bitrate it probably doesn't use it much so it probably doesn't matter much.

Messing with different settings comes into play more with CQs in the mid-20s and higher. When people use CQ of like 18 or less, that has a lot bigger margin of error.

There is a reason they call it placebo! :D

Placebo: Anything of no direct benefit which nevertheless makes people feel better or benefit psychologically.
Placebo on x264 is noticeable to me. I'm guessing the main reason is the sub-pixel precision goes to 11.

I haven't tested Placebo on x265 since the other presets didn't seem overly tuned anyway, (as numerous people have criticized in the past).

CRF values aren't going to be particularly consistent across aq-modes, and you can (with a bucket full of caveats) generally raise CRF with more advanced AQ at similar subjective quality.
I was doing some tests on that recently, and AQ1 at CQ 21 was very close in size to CQ 22.5 AQ2 on those files. AQ3 adds so much bitrate it seems to have a mind of its own so I stopped trying.

I've been doing A LOT of grain tests with psyrdo and things, and AQ1 seems just plain more consistent. (As expected, I guess.) It's harder to get consistent texture/grain/quality on people's faces etc with AQ2. On a face close-up when someone's talking, the mouth and cheeks have a lot of different color and depth and detail going on, and it's easy to make them look all sorts of wrong.

[brumsky]

Is it possible to correct the color change between the screen shots below? The first is the source from bluray and the second is using x265 v 2.3+6. I've updated to v2.3+17 with no change...

http://screenshotcomparison.com/comparison/202364

My settings are below which I pulled from MediaInfo.

cpuid=1173503 / frame-threads=6 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=1470 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=5 / rc-lookahead=40 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=3 / rdoq-level=2 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=2 / limit-modes / me=3 / subme=3 / merange=26 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=5 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=2.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.65 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=16 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion / no-hdr / no-hdr-opt / Capture-colorprim=3

A side from the coloring I've tried to improve pic quality without just throwing more bits at it. I've tried dozens of tweaks rd, max merge, ref, rect, amp, aq mode, limit-tu, et cetera.

Even when I increase the CRF from 21 -> 20 or even 19, it doesn't improve much...

Thanks in advance!

[pingfr]

Is it possible to correct the color change between the screen shots below? The first is the source from bluray and the second is using x265 v 2.3+6. I've updated to v2.3+17 with no change...

http://screenshotcomparison.com/comparison/202364



While I must admit I don't have a solution to your color issue... I must say the loss of details specially on his shoulders is astoundingly awfully bad.

x265 really needs to massively improve in details retention in that specific area if it wants to be "taken seriously" compared to other HEVC encoders.

The loss of details is so ugly, it makes XviD (aka a 15 years old obsolete codec) look better in those regards. :eek:

[brumsky]

The only proper way to retain detail is to use --tune grain. That's just the way it is :)

I'll give it a try! :)

[LoRd_MuldeR]

Discussion about Ryzen has been split into a separate thread:
https://forum.doom9.org/showthread.php?t=174383

[Jawed]

Is it possible to correct the color change between the screen shots below? The first is the source from bluray and the second is using x265 v 2.3+6. I've updated to v2.3+17 with no change...
I remember when I looked at the encodes/screenies from:

https://forum.doom9.org/showpost.php?p=1781745&postcount=4275

The Y, U and V planes all showed very small "errors" (typically "1"). The error varies from frame to frame, too.

I did some experiments of my own and also compared with x264. I discovered that these errors are "normal". x264 does the same. You have to use very high quality settings (CRF 16 or better, if I remember right) to eliminate these shifts.

I can't remember, but I think B frames also contribute.

I decided: "life's too short".

[amayra]

i have notified my encoding speed decrease for no apparent reason with same some settings after i updated to 2.3.17
Is there any reason for that ?

[brumsky]

I remember when I looked at the encodes/screenies from:

https://forum.doom9.org/showpost.php?p=1781745&postcount=4275

The Y, U and V planes all showed very small "errors" (typically "1"). The error varies from frame to frame, too.

I did some experiments of my own and also compared with x264. I discovered that these errors are "normal". x264 does the same. You have to use very high quality settings (CRF 16 or better, if I remember right) to eliminate these shifts.

I can't remember, but I think B frames also contribute.

I decided: "life's too short".

Ok thanks good to know. I agree, life's too short. ;)

[WhatZit]

x265 really needs to massively improve in details retention in that specific area if it wants to be "taken seriously" compared to other HEVC encoders.

The loss of details is so ugly, it makes XviD (aka a 15 years old obsolete codec) look better in those regards. :eek:

Already done as of 13th July 2016!: http://x265.readthedocs.io/en/default/releasenotes.html#version-2-0 and http://x265.readthedocs.io/en/default/presets.html#tunings

Maybe if MulticoreWare renamed "--tune grain" to "--tune quality", and dumbed-down the manual's explanation of its unique (as in, if you don't use it, you don't get it) rate control and frequency biasing algorithms, more people striving for quality would stop second-guessing the developers over preset construction and start building useful command lines around "--tune quality".

So far, the only other person I've seen here who "gets it", is Boulder, and kudos to him for that!

[pingfr]

Already done as of 13th July 2016!: http://x265.readthedocs.io/en/default/releasenotes.html#version-2-0 and http://x265.readthedocs.io/en/default/presets.html#tunings

Maybe if MulticoreWare renamed "--tune grain" to "--tune quality", and dumbed-down the manual's explanation of its unique (as in, if you don't use it, you don't get it) rate control and frequency biasing algorithms, more people striving for quality would stop second-guessing the developers over preset construction and start building useful command lines around "--tune quality".

So far, the only other person I've seen here who "gets it", is Boulder, and kudos to him for that!

Really? Like... really??? Okay, I'll bite the bullet.

Let's see what we have here:

x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -1:-1 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 2.43 MiB
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

File-size: 2.44MB.

Now let's try the same command line but let's add the --tune grain switch shall we?

x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -3:-3 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing --tune grain

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 10.7 MiB
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=1.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=1.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5

File-size: 10.7MB.

So what do we have here? A 2.44MB file for only 300 encoded frames vs. a ~11MB file encode with the --tune grain? :eek:

I guess I'll stick to not using --tune grain for now and look for optimized cookie-cutter settings until the resulted file size can be shaved off by a good 50% margin with --tune grain.

My 2 cents.

Edit: For what it's worth, the only differences here are 2.3+9 with -1:-1 deblocking values vs. 2.3+17 with -3:-3 deblocking but if you insist I can run the same encodes again with the same revision and the same deblocking values.

[WhatZit]

Now let's try the same command line but let's add the --tune grain switch shall we?

You don't "add" --tune grain to an existing command line.

You replace your entire command line with --tune grain (preset/crf/sharpening tweaks aside). That's because --tune grain does NOT operate with the default algorithms (it's in the manual link I posted)!

And remember, --tune grain is so good at retaining detail that you can drop both CRF & preset back from whatever your reworked preset parameters required previously.

Ultimately, you're going to have to decide what's MOST important to you: speed, size or quality. So far, you're meandering between all of them.

You never even mentioned the quality of the output, only size. Besides, none of us can tell what you think "quality" is, anyway. They're your eyes.

You want a compromise between all three? Grain can do that too, using nothing more than preset & crf.

The very first thing I did when I read "massive improvements to --tune grain" from the press release last year was to encode scenes from 1080p Samsara with:

--preset superfast --crf 28 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing

SUPERFAST 28! What do you think that looked like? You'd be WRONG!

I realised that if --tune grain could help make output that "good" ("not awful" is more accurate) at settings that SHOULD have produced genuinely awful results, then the only way was up.

EDIT: A picture (or two) is worth a thousand words. Go here: http://screenshotcomparison.com/comparison/202693

Yes, that's the 4k Yacht Ride sample from http://ultravideo.cs.tut.fi/#testsequences

I used my exact "low quality" command line from above.

Comparison #1 is the Raw YUV against x265 Superfast CRF28 --tune grain

Comparison #2 is the Raw YUV against x265 Superfast CRF28 without --tune grain (the only change)

If that doesn't demonstrate not only everything I've been saying, but everything the manual has been saying for the past 9 months, then I don't know what else to say, except...

There are effectively TWO x265's: the default one that biases Compression-Over-Quality, and the --tune grain one that biases Quality-Over-Compression. Like it or not, that's the way it is, and the "quality" problem you're complaining about was solved 9 months ago.

[Khun_Doug]

So is it the case, then, that using --tune grain invokes internal code that is not otherwise accessible by using sane and personalized options based on the specific content?

For example: I have a lot SD discs and sets that are not available in HD, and some of those have film from the 70's. In my experiments I have found that I was looking at options such deblock -3:-3, no-sao, and AQ 3. I have no trouble choosing slow or slower, and a CRF of 18. So would it then be the case that by choosing --tune grain I probably wouldn't need to toy with these options, or any of the other myriad of options that are available, because --tune grain uses different routines, not just a different baseline of settings?

[WhatZit]

So is it the case, then, that using --tune grain invokes internal code that is not otherwise accessible by using sane and personalized options based on the specific content?

Yep: http://x265.readthedocs.io/en/default/presets.html#tunings

Basically, grain265 (need a shorthand way of saying it) "thinks" differently than the default regime.

Whether --rc-grain can actually be used outside of the tuning is something I've never experimented with. The developers "highly recommend" against it.

Sure, you can still fiddle with traditional options, but, as a starting point for producing quality encodes, you simply can't go past grain.

[pingfr]

There are effectively TWO x265's: the default one that biases Compression-Over-Quality, and the --tune grain one that biases Quality-Over-Compression. Like it or not, that's the way it is, and the "quality" problem you're complaining about was solved 9 months ago.

x265 --preset superfast --crf 21 --tune grain --deblock=-1:-1 --no-strong-intra-smoothing Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o grainsuperfast.hevc
y4m [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw [info]: output file: grainsuperfast.hevc
x265 [info]: HEVC encoder version 2.3+17-6e348252e902
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling aq,cu-tree
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
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 : hex / 57 / 1 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=4.00 early-skip signhide tmvp fast-intra
x265 [info]: tools: lslices=6 deblock(tC=-1:B=-1)
x265 [info]: frame I: 3, Avg QP:21.33 kb/s: 28086.08
x265 [info]: frame P: 149, Avg QP:23.05 kb/s: 10469.61
x265 [info]: frame B: 448, Avg QP:23.05 kb/s: 3873.64
x265 [info]: consecutive B-frames: 0.7% 1.3% 0.7% 97.4%

encoded 600 frames in 26.86s (22.33 fps), 5632.71 kb/s, Avg QP:23.04

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 13.4 MiB
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=1 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=10 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes / me=1 / subme=1 / merange=57 / temporal-mvp / no-weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=2 / early-skip / no-rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=1 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=10 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes / me=1 / subme=1 / merange=57 / temporal-mvp / no-weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=2 / early-skip / no-rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5

13.4MB... no thanks! :eek:

[Khun_Doug]

Then I am inclined to agree that it would have been better named --tune quality, and definitely more emphasis indicating that internal controls for quality are invoked. So now on to a new set of test encodes! :)

[WhatZit]

x265 --preset superfast --crf 21 --tune grain --deblock=-1:-1 --no-strong-intra-smoothing Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o grainsuperfast.hevc

13.4MB... no thanks! :eek:

So, it's SIZE you care about, not quality.

Try CRF28.

EDIT: I made a CRF21 version of the YachtRide sample, only changing my "low quality" command line above from --crf 28 to --crf 21:

CRF21 = 26.7Mb
CRF28 = 10.7Mb

The CRF21 version is subjectively 5-10% better quality than the CRF28 version, which is not worth the 250% file size. Or, is it...?

So, yes, you need to rethink how presets & CRF work under grain265.