x265 HEVC Encoder

[Stereodude]

AFAIK, piping can't seek either. The workaround is a giant pain. I have to make a unique .avs for every segment the outputs the right frames using trim, and then I have to make a unique .chp for every segment/x265 call that's shifted by the correct amount. :(

[alex1399]

How about multiple piping? Just pipe the avs + lossless x264 encode ultrafast before the x265 ones

[Stereodude]

How about multiple piping? Just pipe the avs + lossless x264 encode ultrafast before the x265 ones
Can you elaborate a bit more? I'm not sure I'm following you.

[alex1399]

Why hasn't direct AVIsynth input been added to the windows builds of x265 like x264 has? I'm rather sick of having to pipe video into it.
Never mind. Doesn't saw this previous post before.

[MeteorRain]

AFAIK, piping can't seek either. The workaround is a giant pain. I have to make a unique .avs for every segment the outputs the right frames using trim, and then I have to make a unique .chp for every segment/x265 call that's shifted by the correct amount. :(

Can you shed more light on what you are trying to accomplish?

Why would a chp file be affected by seeking support? Suppose it's a chapter file, and x265 does not take chapter files as input.

Talking about my experience, if I want to backup a movie, usually I want to encode it in multiple segments. I have scripts which can produce "import().trim()" type of AVS files, and I encode them in different batch, then concatenate them together, attach the chapter, and call it a day.

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

[microchip8]

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.

Here is a rather technical explanation http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/AV0405/ZAMPOGLU/Hierarchicalestimation.html

[Stereodude]

Can you shed more light on what you are trying to accomplish?

Why would a chp file be affected by seeking support? Suppose it's a chapter file, and x265 does not take chapter files as input.

Talking about my experience, if I want to backup a movie, usually I want to encode it in multiple segments. I have scripts which can produce "import().trim()" type of AVS files, and I encode them in different batch, then concatenate them together, attach the chapter, and call it a day.
I'm encoding something in multiple segments to improve quality (less threads) and speed (multiple encodes at once). I'm talking about having to shift frames around in the qpfile. Each unique .avs needs a unique qpfile.

Seek support would simply this since the same .avs and qpfile could be used and only the seek point and frame number on the command line would need to change.

This would also be more simple if affinity restrictions from the START command in Windows 10 worked with x265. It seems that somewhere in the Windows 10 feature update chain MS changed the behavior. Affinity restrictions on a .bat file that called an executable used to result in the same affinity restrictions being placed on the executable started by the .bat file. Now it doesn't. Affinity restrictions placed directly on the x265 command line don't even work. (They do work on the x264 command line.)

Ideally I would run a batch file with these four lines and be done.
START "Enc #1" /NORMAL /NODE 0 /AFFINITY F000 "C:\HDTV Tools\x265\x265.exe" -F 1 --crf 16.0 -p veryslow ...
START "Enc #2" /NORMAL /NODE 0 /AFFINITY 0F00 "C:\HDTV Tools\x265\x265.exe" -F 1 --crf 16.0 -p veryslow ...
START "Enc #3" /NORMAL /NODE 0 /AFFINITY 00F0 "C:\HDTV Tools\x265\x265.exe" -F 1 --crf 16.0 -p veryslow ...
START "Enc #4" /NORMAL /NODE 0 /AFFINITY 000F "C:\HDTV Tools\x265\x265.exe" -F 1 --crf 16.0 -p veryslow ...
Each x265 instance would see only 4 logical cores and would be locked to those 4 cores. But instead each x265 instance sees all 16 logical cores and I have to add --pools 4 to the command line and then manually modify the affinity of each x265 process in the Task Manager once they're all started.

[Boulder]

Here is a rather technical explanation http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/AV0405/ZAMPOGLU/Hierarchicalestimation.html

Thanks - yes, quite technical. To me it looks somehow similar to MRecalculate in MVTools, but maybe someone can explain it in layman's terms or simply come up with some POC they must have performed at some point. Looks interesting anyway.

[Atak_Snajpera]

Affinity restrictions placed directly on the x265 command line don't even work. (They do work on the x264 command line.)
I can confirm this behaviour. Looks like that x265 unlike x264 resets affinity at launch. I would also prefer that x265 didn't change initial affinity set by user.

[LigH]

I believe it may be possible to use the --pools parameter to control the affinity of x265 instances if it was just documented verbosely enough (https://x265.readthedocs.io/en/default/threading.html#thread-pools)...

x265 creates one or more thread pools per encoder, one pool per NUMA node (typically a CPU socket). --pools specifies the number of pools and the number of threads per pool the encoder will allocate. By default x265 allocates one thread per (hyperthreaded) CPU core on each NUMA node.

This may be not sufficient without examples. Right away you will notice that the online documentation does not even mention some parameters in the help output:

--pools <integer,...> Comma separated thread count per thread pool (pool per NUMA node)
'-' implies no threads on node, '+' implies one thread per core on node

I would guess that calls with a similar result as the above mentioned "start /AFFINITY" might look similar to:

x265 --pools 4,"+---"
x265 --pools 4,"-+--"
x265 --pools 4,"--+-"
x265 --pools 4,"---+"

I hope Ma can enlighten us.

[Stereodude]

I believe it may be possible to use the --pools parameter to control the affinity of x265 instances if it was just documented verbosely enough (https://x265.readthedocs.io/en/default/threading.html#thread-pools)...



This may be not sufficient without examples. Right away you will notice that the online documentation does not even mention some parameters in the help output:

--pools <integer,...> Comma separated thread count per thread pool (pool per NUMA node)
'-' implies no threads on node, '+' implies one thread per core on node

I would guess that calls with a similar result as the above mentioned "start /AFFINITY" might look similar to:

x265 --pools 4,"+---"
x265 --pools 4,"-+--"
x265 --pools 4,"--+-"
x265 --pools 4,"---+"

I hope Ma can enlighten us.
Your example doesn't work. And, it contradicts what's in this: https://x265.readthedocs.io/en/default/cli.html

It has these examples:
"" - default, unspecified, all numa nodes are used for thread pools
"*" - same as default
"none" - no thread pools are created, only frame parallelism possible
"-" - same as "none"
"10" - allocate one pool, using up to 10 cores on all available nodes
"-,+" - allocate one pool, using all cores on node 1
"+,-,+" - allocate one pool, using only cores on nodes 0 and 2
"+,-,+,-" - allocate one pool, using only cores on nodes 0 and 2
"-,*" - allocate one pool, using all cores on nodes 1, 2 and 3
"8,8,8,8" - allocate four pools with up to 8 threads in each pool
"8,+,+,+" - allocate two pools, the first with 8 threads on node 0, and the second with all cores on node 1,2,3
There's considerably more verbage on it too.

I see no references to core restrictions, only node restrictions in the documentation.

[LigH]

Ah, I missed these examples... I would have given a better guess if I knew them.

So it seems to be:

x265 --pools "4,4,4,4,+,-,-,-"
x265 --pools "4,4,4,4,-,+,-,-"
x265 --pools "4,4,4,4,-,-,+,-"
x265 --pools "4,4,4,4,-,-,-,+"

Or am I still wrong? ... In this case, I may misunderstand the nodes in contrast to the specific cores.

P.S.: I asked in the x265 developer mailing list.

[Stereodude]

Ah, I missed these examples... I would have given a better guess if I knew them.

So it seems to be:

x265 --pools "4,4,4,4,+,-,-,-"
x265 --pools "4,4,4,4,-,+,-,-"
x265 --pools "4,4,4,4,-,-,+,-"
x265 --pools "4,4,4,4,-,-,-,+"

Or am I still wrong? ... In this case, I may misunderstand the nodes in contrast to the specific cores.

P.S.: I asked in the x265 developer mailing list.
I didn't try any of those, but this system only has 1 numa node (8C/16HT) and those command lines would be for a system with 4 numa nodes, and they're contradicting. "0,0,0,4" would put 0 thread pools on the first 3 Numa nodes and 4 on the 4th. "4,4,4,4" would put 4 thread pools on each of the 4 Numa nodes. "+,-,-,-" would put a thread pool with an number equal to the logical cores in the first node and none on the next 3. So, you've got conflicting instructions on the command line.

By my reading and messing with them (I do have a dual Numa node system) you have control over nodes, but not over cores.

I'll be curious to see what reply you get on the mailing list.

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

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)?

:confused:

[MeteorRain]

That is correct as far as I know.

[mandarinka]

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]

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]

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]

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]

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 (https://www.mediafire.com/file/95xlvfj16xxpwrb/x265_3.1+8-21db162c8622.7z/file) (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]

x265 3.1+8-21db162c8622 (https://www.mediafire.com/file/95xlvfj16xxpwrb/x265_3.1+8-21db162c8622.7z/file) (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?:D

[_kermit]

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?).

[jlpsvk]

But how... quality and speed impact??? I've done test on the whole 4K HDR movie. Same settings, one with AQ2, one with AQ4.

AQ2:
x265 [info]: HEVC encoder version 3.1+8-21db162c8622
x265 [info]: build info [Windows][GCC 9.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 28 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(25 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 240 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 48 / 8 / 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 / 8 / 1
x265 [info]: Rate Control / qCompress : CRF-16.0 / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 160000 / 160000 / 0.900
x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: signhide tmvp lslices=4

x265 [info]: frame I: 1572, Avg QP:19.24 kb/s: 36306.92
x265 [info]: frame P: 31790, Avg QP:20.31 kb/s: 29999.39
x265 [info]: frame B: 120253, Avg QP:23.15 kb/s: 17831.23
x265 [info]: Weighted P-Frames: Y:9.7% UV:1.7%
x265 [info]: consecutive B-frames: 17.9% 9.6% 8.6% 19.1% 7.5% 10.0% 6.4% 9.3% 11.7%

encoded 153615 frames in 81511.10s (1.88 fps), 20538.46 kb/s, Avg QP:22.53

AQ4:
x265 [info]: HEVC encoder version 3.1+8-21db162c8622
x265 [info]: build info [Windows][GCC 9.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 28 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(25 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 240 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 48 / 8 / 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 : 4 / 1.0 / 8 / 1
x265 [info]: Rate Control / qCompress : CRF-16.0 / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 160000 / 160000 / 0.900
x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: signhide tmvp lslices=4

x265 [info]: frame I: 1571, Avg QP:19.38 kb/s: 35277.33
x265 [info]: frame P: 31792, Avg QP:20.46 kb/s: 29185.39
x265 [info]: frame B: 120252, Avg QP:23.29 kb/s: 17402.88
x265 [info]: Weighted P-Frames: Y:9.6% UV:1.7%
x265 [info]: consecutive B-frames: 17.9% 9.6% 8.7% 19.1% 7.6% 10.0% 6.3% 9.3% 11.7%

encoded 153615 frames in 83129.38s (1.85 fps), 20024.18 kb/s, Avg QP:22.66

[Jamaika]

I just found out that "aq-mode" parameters don't apply to frames I i.e. pictures. For qp on for frames P, aq-mode on. For qp off for frames I, aq-mode off. :D

[vpupkind]

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?).
Both hevc-aq and aq=4 try to take into account edges passing through the block.

[Jamaika]

x265&svt-3.1+8
I don't know why no one adds x265 & svt. Is this a temporary fusion? I will risk something to write.
https://www.sendspace.com/file/mt3kue
Information about color space is also interesting. For SVT, this is currently the High Dymanic Range. For 8bit is Low Dynamic Range.


x265 [info]: SVT doesn't support input-csp param; Disabling it
x265 [info]: SVT doesn't support crf param; Disabling it
x265 [info]: SVT doesn't support info param; Disabling it
x265 [info]: SVT doesn't support aq-mode param; Disabling it
x265 [info]: SVT doesn't support colormatrix param; Disabling it
x265 [info]: SVT doesn't support colorprim param; Disabling it
x265 [info]: SVT doesn't support transfer param; Disabling it
x265 [info]: SVT doesn't support limit-refs param; Disabling it
x265 [info]: SVT doesn't support range param; Disabling it

if (params->color_space == BPG_CS_YCbCr_HDR) {
p->vui.matrixCoeffs = 9;
svtHevcParam->highDynamicRangeInput = 1;
if (params->bit_depth => 10) {
p->vui.bEnableVideoFullRangeFlag = 1;
} else {
p->vui.bEnableVideoFullRangeFlag = 0;
}// for 8bit is Low Dynamic Range
}

PS change files in x265
svt.h --> #define INPUT_SIZE_8K_TH 0xB71B00 // 12 Million
param.cpp --> svtHevcParam->vbvMaxrate = 0;
param.cpp --> svtHevcParam->vbvBufsize = 0;
param.cpp --> svtHevcParam->vbvBufInit = 90;
param.cpp --> svtHevcParam->hrdFlag = 0;

[DJATOM]

Can someone explain, what's the purpose of HME? Is it for better quality/accuracy of ME or just for making things faster?

[microchip8]

Can someone explain, what's the purpose of HME? Is it for better quality/accuracy of ME or just for making things faster?

the former. it's for better quality/accuracy. Here's an article that explains it. It is also low computational but highly efficient

http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/AV0405/ZAMPOGLU/Hierarchicalestimation.html

[benwaggoner]

the former. it's for better quality/accuracy. Here's an article that explains it. It is also low computational but highly efficient

http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/AV0405/ZAMPOGLU/Hierarchicalestimation.html
So, it can make things faster at the same quality, higher quality at the same speed, or a mix of the two.

[aegisofrime]

So, it can make things faster at the same quality, higher quality at the same speed, or a mix of the two.

Could you share your settings? By simply setting --hme, I'm seeing a reduction of around 40% in speed on my encodes. Thanks!

[microchip8]

Could you share your settings? By simply setting --hme, I'm seeing a reduction of around 40% in speed on my encodes. Thanks!

I don't see such a high penalty on my i7 7700K processor. I use hme=1 and hme-search=umh,umh,umh

[DJATOM]

My friend tried star,star,umh and caught a crash on frame 50, but umh,star,umh works fine (but slower).

[microchip8]

My friend tried star,star,umh and caught a crash on frame 50, but umh,star,umh works fine (but slower).

yes, I experienced the same crash when using star for all levels (L0,1,2) hme-search=star

I use umh because I find it preserves details better but is a bit slower than star

[benwaggoner]

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?).
Speculation: aq-mode 4 is the non-experimental implementation of --hevc-aq.

[jlpsvk]

@benwaggoner

i don't think so, as hevc-aq and aq-mode 4 coexists...

[mandarinka]

My friend tried star,star,umh and caught a crash on frame 50, but umh,star,umh works fine (but slower).

I can confirm it doesn't like star on the first instance, I got crash right at start with merange 92 and 1440x1080 source.

Could you share your settings? By simply setting --hme, I'm seeing a reduction of around 40% in speed on my encodes. Thanks!

To get higher speed, lower your merange. The value given is used as the distance of the first-stage search, so it is effectively quadrupled.

[Boulder]

I'm currently using merange 32 for my 720p encodes (max CTU and TU is 32 for better CPU utilization). Would it make sense to lower the value for example to 16-20 and enable HME (with umh,umh,umh), or is the first stage range so important that it will start to affect the final result too much?

[microchip8]

I'm currently using merange 32 for my 720p encodes (max CTU and TU is 32 for better CPU utilization). Would it make sense to lower the value for example to 16-20 and enable HME (with umh,umh,umh), or is the first stage range so important that it will start to affect the final result too much?

I use as ME range a value of 26 for 1080p encodes (ctu is 32 too). ME range is calculated as follows:

ctu size - 4(luma) - 2(chroma) (- 1 if me=hex is used)

You can lower it to 26 and enable HME like I do. Here the performance penalty is very minor, also considering that HME, as explained in the article I linked to a few posts earlier, has computationally low complexity

I wonder what options the poster above uses to hit a 40% reduction in speed when HME is enabled