x265 HEVC Encoder

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

Originally Posted by aymanalz

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]

Originally Posted by aymanalz

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]

Originally Posted by Boulder

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]

Originally Posted by Boulder

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.as...&SecondVisit=1

[divxmaster]

Originally Posted by pingfr

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]

Originally Posted by pingfr

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

https://drdump.com/UploadedReport.as...&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]

Originally Posted by darksiderg

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

Originally Posted by divxmaster

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]

Originally Posted by aymanalz

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]

Originally Posted by pingfr

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]

Originally Posted by LigH

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]

Originally Posted by LigH

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]

Originally Posted by pingfr

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.