x265 HEVC Encoder

[MeteorRain]

I have never made x265 to set its affinity as I intended so I always use my modded version of avs4x264 to do the job, which overwrites the affinity after x265 launches.

Regarding to your qpfile usage, honestly I have no similar usage of those so I don't have good suggestions for you. Usually if I want to force an IDR I'll just cut that as a new segment.

I'll take a quick look at the source code and see if I can find a way to do a seek easily. If it's easy enough to implement I'll slipstream it into my patch set.

[MeteorRain]

And -- I might be wrong, but -- I don't see any code with qpfile that takes into account seek option. That means you'll have to shift your qpfile for any seek option you applied in the command line.

[MeteorRain]

https://down.7086.in/x265-10bit-avisynth-seek-test.zip

qpfile still needs manual shifting.

[Stereodude]

Originally Posted by MeteorRain

And -- I might be wrong, but -- I don't see any code with qpfile that takes into account seek option. That means you'll have to shift your qpfile for any seek option you applied in the command line.

So if I tell it to drop an I frame at frame 6000 and I tell it to seek to frame 5000 to start the encode it doesn't subtract 5000 from 6000 and know to place it at 1000 in the encode (which is frame 6000 in the source)?

[MeteorRain]

That is correct as far as I know.

[mandarinka]

Originally Posted by Boulder

I see there are two recent commits related to hierachial motion estimation. I couldn't find anything specific as to what the use cases would be, does anyone have any insights? Or is this once again one of those things that just appear in the encoder out of the blue (probably requested by some paying client) and the devs leave it at that.

If I'm not mistaken, this method could perhaps improve the search by allowing it to find more distant motion vectors (large motion difference between frames say in anime action sequences?). I'm completely assuming, haven't tried yet.

Has anybody here tested it?

(Edit: also, is it finished/ready for testing yet, or are there more incoming patches to plumb it together?)

[tuanden0]

New commit with new aq-mode

--aq-mode <0|1|2|3|4>

Adaptive Quantization operating mode. Raise or lower per-block quantization based on complexity analysis of the source image. The more complex the block, the more quantization is used. This offsets the tendency of the encoder to spend too many bits on complex areas and not enough in flat areas.

disabled
AQ enabled
AQ enabled with auto-variance (default)

3. AQ enabled with auto-variance and bias to dark scenes. This is recommended for 8-bit encodes or low-bitrate 10-bit encodes, to prevent color banding/blocking. 4. AQ enabled with

[quietvoid]

Originally Posted by mandarinka

If I'm not mistaken, this method could perhaps improve the search by allowing it to find more distant motion vectors (large motion difference between frames say in anime action sequences?). I'm completely assuming, haven't tried yet.

Has anybody here tested it?

(Edit: also, is it finished/ready for testing yet, or are there more incoming patches to plumb it together?)

From my quick testing using --hme with --hme-search hex,star,hex is 3x slower than just --me star (subme 5) with --preset slower.
Even hex,hex,hex is still 10% slower, so not sure what the use case is when it's that slow.

[vpupkind]

Originally Posted by quietvoid

From my quick testing using --hme with --hme-search hex,star,hex is 3x slower than just --me star (subme 5) with --preset slower.
Even hex,hex,hex is still 10% slower, so not sure what the use case is when it's that slow.

The point is having a much larger search range. On high resolutions (e.g. 4K) the current search range is very small and is not great at capturing fast motion. With HME, using 3 levels with range of 32 will get you to the range of 224. The current default for star, hex, et al is less than 64.
The other point is better coherency of motion field at high resolutions.

[mandarinka]

Any reason why --HME uses hex, umh, umh as its default motion searches, but generally x265 uses --me star in its presets?
(would Star be better than UMH in HME, and generally outside of HME?)

[microchip8]

Originally Posted by mandarinka

Any reason why --HME uses hex, umh, umh as its default motion searches, but generally x265 uses --me star in its presets?
(would Star be better than UMH in HME, and generally outside of HME?)

I guess performance reasons. I use hme-search=star for all levels (L0,1,2)

[Boulder]

So basically the option has no practical use in encodes of sub-4K resolutions?

[microchip8]

Originally Posted by Boulder

So basically the option has no practical use in encodes of sub-4K resolutions?

I use it for Full HD movies. I find it looks a bit sharper compared to no hme

[LigH]

x265 3.1+8-21db162c8622 (MSYS2, MinGW32 / MinGW64 + GCC 9.1.0)

   --[no-]hme                    Enable Hierarchical Motion Estimation. Default disabled
   --hme-search <string>         Motion search-method for HME L0,L1 and L2. Default(L0,L1,L2) is 1,2,2
   --aq-mode <integer>           Mode for Adaptive Quantization - 0:none 1:uniform AQ 2:auto variance 3:auto variance with bias to dark scenes 4:auto variance with edge information. Default 2
   --[no-]aq-motion              Block level QP adaptation based on the relative motion between the block and the frame. Default disabled

[Morku]

@LigH
As silent reader I want to say thank you for the fresh, updated Encoders. Please never stop. Even when the board seems to fall asleep sometimes, we appreciate all the work. A Thank Button would be nice here. Every contribute is important

I hope Zathor is fine...?

[jlpsvk]

what exctly that aq-mode 4 is doing? is it that "HEVC" aq? or? that HEVC aq was not so good... currently i am using aq-mode 2.

[Jamaika]

Originally Posted by LigH

x265 3.1+8-21db162c8622 (MSYS2, MinGW32 / MinGW64 + GCC 9.1.0)

   --[no-]hme                    Enable Hierarchical Motion Estimation. Default disabled
   --hme-search <string>         Motion search-method for HME L0,L1 and L2. Default(L0,L1,L2) is 1,2,2
   --aq-mode <integer>           Mode for Adaptive Quantization - 0:none 1:uniform AQ 2:auto variance 3:auto variance with bias to dark scenes 4:auto variance with edge information. Default 2
   --[no-]aq-motion              Block level QP adaptation based on the relative motion between the block and the frame. Default disabled

I add function qp zero, aq-mode doesn't work.
p->rc.aqMode = X265_AQ_EDGE;
p->bAQMotion = 1;
p->bEnableHME = 1;
p->hmeSearchMethod[1] = p->hmeSearchMethod[2] = X265_STAR_SEARCH;

x265 (build 178) - 3.1+8:[Windows][GCC 9.1.1][64 bit][noasm] 10bit - H.265/HEVC codec - Copyright 2013-2018 (c) Multicoreware, Inc - http://x265.org - options: cpuid=0 frame-threads=2 wpp no-pmode no-pme no-psnr no-ssim log-level=2 bitdepth=10 input-csp=2 fps=25/1 input-res=1568x1560 interlace=0 total-frames=1 level-idc=0 high-tier=1 uhd-bd=0 ref=1 no-allow-non-conformance repeat-headers annexb no-aud no-hrd info hash=0 no-temporal-layers no-open-gop min-keyint=1 keyint=1 gop-lookahead=0 bframes=0 b-adapt=0 no-b-pyramid bframe-bias=0 rc-lookahead=0 lookahead-slices=0 scenecut=0 radl=0 no-splice no-intra-refresh ctu=64 min-cu-size=8 rect amp max-tu-size=32 tu-inter-depth=4 tu-intra-depth=4 limit-tu=0 rdoq-level=2 dynamic-rd=0.00 no-ssim-rd signhide tskip nr-intra=0 nr-inter=0 no-constrained-intra strong-intra-smoothing max-merge=5 limit-refs=0 no-limit-modes me=2 subme=5 merange=92 temporal-mvp hme Level 0,1,2=1,3,3 no-weightp no-weightb no-analyze-src-pics deblock=-1:1 sao no-sao-non-deblock rd=6 no-early-skip no-rskip no-fast-intra no-tskip-fast no-cu-lossless b-intra no-splitrd-skip rdpenalty=0 psy-rd=2.00 psy-rdoq=0.00 no-rd-refine no-lossless cbqpoffs=0 crqpoffs=0 rc=cqp qp=0 aq-mode=0 aq-strength=0.00 no-cutree zone-count=0 no-strict-cbr qg-size=32 no-rc-grain qpmax=69 qpmin=0 no-const-vbv sar=0 overscan=0 videoformat=5 range=0 colorprim=2 transfer=2 colormatrix=2 chromaloc=0 display-window=0cll=0,0 min-luma=0 max-luma=1023 log2-max-poc-lsb=8 vui-timing-info vui-hrd-info slices=1 no-opt-qp-pps no-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 no-dhdr10-opt no-idr-recovery-sei analysis-reuse-level=5 scale-factor=0 refine-intra=0 refine-inter=0 refine-mv=0 refine-ctu-distortion=0 no-limit-sao ctu-info=0 no-lowpass-dct refine-analysis-type=33620483 copy-pic=1 max-ausize-factor=1.0 no-dynamic-refine no-single-sei no-hevc-aq no-svt no-field qp-adaptation-range=1.00

For what presets is it and additional functions? Can it be used for 10bit?

[_kermit]

Originally Posted by jlpsvk

what exctly that aq-mode 4 is doing? is it that "HEVC" aq? or? that HEVC aq was not so good... currently i am using aq-mode 2.

I have the same question

[Selur]

--aq-mode <integer>           Mode for Adaptive Quantization - 0:none 1:uniform AQ 2:auto variance 3:auto variance with bias to dark scenes 4:auto variance with edge information. Default 2
--[no-]hevc-aq                Mode for HEVC Adaptive Quantization. Default disabled
--aq-strength <float>         Reduces blocking and blurring in flat and textured areas (0 to 3.0). Default 1.00
--qp-adaptation-range <float> Delta QP range by QP adaptation based on a psycho-visual model (1.0 to 6.0). Default 1.00
--[no-]aq-motion              Block level QP adaptation based on the relative motion between the block and the frame. Default disabled

source: x265 --fullhelp
-> hevc-aq is still there, so aq-mode 4 should be something different

[mandarinka]

From the description, it looks both aqmode 3 and aqmode 4 are modifications of aqmode 2. Based on the descriptions, the first adds bias for darker scenes/parts and the second (#4) adds bias for detected(?) edges (to improve them?).