x265 HEVC Encoder

[benwaggoner]

I'm aware of x265's --dhdr10-opt, but I prefer to keep it the same as the source (which seems to always be for every frame).
Not sure if it would affect compatibility as well.
That's just the way the source gets generated. No need to put it on every frame for playback.

[stax76]

Somebody reported an error, encoding finishes but returns exit code 1 at the end, has that a special meaning? What could be the reason?

CPU : AMD Ryzen 9 3900X 12-Core Processor

---------- Video encoding using x265 3.1+11-de920e0 Wolfberry ----------

"C:\Program Files (x86)\VapourSynth\core\vspipe.exe" K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb.vpy - --y4m | C:\Users\Renor\Desktop\StaxRip\Apps\Encoders\x265\x265.exe --crf 20 --output-depth 12 --aq-mode 1 --frames 132 --y4m --output K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb_out.hevc -

The system cannot find the path specified.
y4m [info]: 1280x720 fps 25/1 i420p8 frames 0 - 131 of 132
raw [info]: output file: K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb_out.hevc
x265 [info]: HEVC encoder version 3.1+11-de920e0a3183
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 12 profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 24 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(12 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 : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
Output 132 frames in 1.92 seconds (68.61 fps)
x265 [info]: frame I: 1, Avg QP:20.28 kb/s: 21838.80
x265 [info]: frame P: 31, Avg QP:20.75 kb/s: 4661.11
x265 [info]: frame B: 100, Avg QP:27.32 kb/s: 311.44
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.1% 9.4% 3.1% 40.6% 43.8%
encoded 132 frames in 2.28s (57.92 fps), 1496.04 kb/s, Avg QP:25.73

------- Error Video encoding using x265 3.1+11-de920e0 Wolfberry -------

Video encoding using x265 3.1+11-de920e0 Wolfberry failed with exit code: 1 (0x1)

The exit code might be a system error code: STATUS_WAIT_1

The exit code might be a system error code: Incorrect function.

[stax76]

The issue was solved:

https://forum.doom9.org/showthread.php?p=1883020#post1883020

[markiemarcus]

Regarding RDOQ, am I the only one who really doesn't like the look of it? Though it's effective at maintaining grain motion, it seems to make it awfully boxy. I realise that this is subjective, but I find the results from disabling RDOQ entirely (--rdoq-level 0 --psy-rdoq 0) and increasing Psy-rd (to anywhere between 2.5 to 3.5) to be consistently more pleasing, assuming the same bitrate. Especially in grainy animation. The only explanation I can come up with for this comes from the documentation: that underlying flat colours reveal the shortcomings of RDOQ "biasing towards energy in general" as opposed to "energy in the source". On live action it seems okay, but I've found a number of instances in animation where anything other than tiny amounts can be quite ugly and make a right mess of fine grain or dither, regardless of the bitrate.

My apologies if that sounds overly negative; I realise that there are folks here who know a lot more than I do. Perhaps I'm missing something? Outside of a few difficulties with deep reds, this is really the only head-scratcher I've run into with x265. The only thing I long for is a way to control the strength of SAO. I like it, but sometimes I think half as much or even less would do.

[Barough]

x265 v3.1+14-f08461fdae33 (https://www.mediafire.com/file/fotm20z6d2kouyh/x265-3.1+14-f08461fdae33_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[filler56789]

Regarding v3.1+14-f08461fdae33...

sadly the compiler warnings are back — for example,

D:/KOMPILES/MCW/x265/source/encoder/analysis.cpp:2498:54: warning: this statement may fall through [-Wimplicit-fallthrough=]
2498 | case 3: mvpSelect[2] = mode.amvpCand[list][ref][!(mode.cu.m_mvpIdx[list][pu.puAbsPartIdx])];
| ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/analysis.cpp:2499:33: note: here
2499 | case 2: mvpSelect[1] = mvp;
| ^~~~
[ 77%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.obj
D:/KOMPILES/MCW/x265/source/encoder/search.cpp: In member function 'void x265_12bit::Search::predInterSearch(x265_12bit::Mode&, const x265_12bit::CUGeom&, bool, uint32_t*)':
D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2276:42: warning: this statement may fall through [-Wimplicit-fallthrough=]
2276 | mvpIdxSel[2] = !mvpIdx;
| ~~~~~~~~~~~~~^~~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2277:21: note: here
2277 | case 2: mvpSel[1] = interMode.amvpCand[list][ref][mvpIdx];
| ^~~~
D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2278:42: warning: this statement may fall through [-Wimplicit-fallthrough=]
2278 | mvpIdxSel[1] = mvpIdx;
| ~~~~~~~~~~~~~^~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2279:21: note: here
2279 | case 1: mvpSel[0] = interDataCTU->mv[list][cuIdx + puIdx].word;
| ^~~~

And last but not least (since I-don't-know-when, really):

-- cmake version 3.15.2
CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy):
The OLD behavior for policy CMP0025 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:16 (cmake_policy):
The OLD behavior for policy CMP0054 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.

[Boulder]

I'd expect there's be a lot of convergence at high bitrates. I'm most interested in how the different modes do when they don't have enough bits to do it right.

I'm also replicating the procedure from my encoding challenge, for apples-to-apples

https://forum.doom9.org/showthread.php?t=175776

Do you have any results from this aq-mode comparison? It would be interesting to know if mode 4 has any useful real-world applications. Of course, HDR encodes are a different story then.

[LigH]

@filler56789 - I do not remember anymore when I mentioned "deprecated CMake policies" to the developer mailing list ... could be more than a year ago already. They are still supported, and I can only hope that abandoning them won't break it for long.

[benwaggoner]

Do you have any results from this aq-mode comparison? It would be interesting to know if mode 4 has any useful real-world applications. Of course, HDR encodes are a different story then.
I encoded them and then went on vacation and forgot to look at them :)!

I'll try to mux and upload before I head to IBC.

[LigH]

Just a side note:

Recently I found archives of images stored in BPG format (Better Portable Graphics), a variant of HEIF. Trying to view them, I found that some famous Windows image viewers don't support it well, partially due to license doubts (IrfanView). For XnView I found a plugin which substitutes the partial support (bpgdec) by basic support via an encoder using x265, but it is not easily configurable (only via configuration file, globally). Web browsers can display BPG images via a JavaScript decoder for the HTML5 Canvas, written by the format author Fabrice Bellard.

The decoders I found so far are not very optimized, especially not multithreaded. Decoding a 150 MPx image takes several seconds. (You will probably guess well if you ask yourself who owns one of such 50K$ cameras...)

[benwaggoner]

Just a side note:

Recently I found archives of images stored in BPG format (Better Portable Graphics), a variant of HEIF. Trying to view them, I found that some famous Windows image viewers don't support it well, partially due to license doubts (IrfanView). For XnView I found a plugin which substitutes the partial support (bpgdec) by basic support via an encoder using x265, but it is not easily configurable (only via configuration file, globally). Web browsers can display BPG images via a JavaScript decoder for the HTML5 Canvas, written by the format author Fabrice Bellard.

The decoders I found so far are not very optimized, especially not multithreaded. Decoding a 150 MPx image takes several seconds. (You will probably guess well if you ask yourself who owns one of such 50K$ cameras...)
It should be straightforward to write a version that would hand off the frame to system-level decoders from Edge and Safari. That'd be HW in most cases, but a well optimized assembly decoder is going to be faster than JS by a lot too.

Chrome and Firefox have been hard-coded to explicitly not pass through HEVC streams to the system decoders, although they do so for H.264. It'd be a trivial tweak to Chromium to re-enable that.

[LigH]

I also mean the decoding speed in separate image viewers. Especially sad for IrfanView, which used to be among the fastest for several formats, but is afraid of license trouble when implementing a HEIF decoder. (Or is it the encoder part, to implement the support only wholesome or not at all?)

Has libavcodec a multi-threaded HEVC decoder? I believe so...

[suarsg]

x265-3.1+11-de920e0-win64-static-multilib (https://drive.google.com/open?id=1NwszYdl291EZgbP2Fo51Tq7La6iXIWaO)

x265 [info]: HEVC encoder version 3.1+11-de920e0a3183
x265 [info]: build info [Windows][GCC 9.2.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec 58.55.101)
x265 [info]: (libavformat 58.31.104)
x265 [info]: (libavutil 56.33.100)
x265 [info]: (lsmash 2.16.1)

Added a new option --lavf to force the use of lavf demuxer regardless of file extension, but this option has no effect on Y4M files.

x265-3.1+11-de920e0-win64-static-multilib+svt (https://drive.google.com/open?id=1kltkuJM_NginwiC67ADNX0RSOyXD-9Cj) (linked with SVT-HEVC, bigger file size)

Hello Wolfberry,

Did you change the order of the printed parameters in x265_param2string()? The "Encoding settings"-field in the produced metadata header from your binary is in a completely different order than what is the default on x265. It's really weird to see that when you're used to certain parameters being in a particular place. Can't say I'm a fan of this "customization".

[Atak_Snajpera]

Hello Wolfberry,

Did you change the order of the printed parameters in x265_param2string()? The "Encoding settings"-field in the produced metadata header from your binary is in a completely different order than what is the default on x265. It's really weird to see that when you're used to certain parameters being in a particular place. Can't say I'm a fan of this "customization".

Yes he did. Use builds from user barough

[Barough]

x265 v3.1+19-c4b098f973e6 (http://www.mediafire.com/file/d04tkl6pg74edkk/x265-3.1%252B19-c4b098f973e6_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[redbtn]

What about new option --selective-sao? Anybody knows should i disable it, like --no-sao earlier?
https://bitbucket.org/multicoreware/x265/commits/5ac4c74c54188f968f53397f9b9cb15bec46df47?at=default

[quietvoid]

What about new option --selective-sao? Anybody knows should i disable it, like --no-sao earlier?
https://bitbucket.org/multicoreware/x265/commits/5ac4c74c54188f968f53397f9b9cb15bec46df47?at=default

Yes, --selective-sao 4 (default) enables --sao even if you have --no-sao.
You can disable it all with --selective-sao 0 --no-sao

[Selur]

The confusing part is that
a. just using '--no-sao' doesn't disable SAO, you get
[warning]: SAO turned ON when selective-sao is ON
so to turn sao off you need to use '--selective-sao 0 --no-sao' ,'--no-sao' or '--selective-sao' on it's own isn't enough.
b. With 'selective-sao' is described as 'Disable SAO for all slices', what is SAO used on if you use '--selective-sao 0 --sao' ?

looking at the code:
if (!!m_param->selectiveSAO)

{

Slice* slice = frameEnc->m_encData->m_slice;

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 1;

switch (m_param->selectiveSAO)

{

case 3: if (!IS_REFERENCED(frameEnc))

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0;

break;

case 2: if (!!m_param->bframes && slice->m_sliceType == B_SLICE)

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0;

break;

case 1: if (slice->m_sliceType != I_SLICE)

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0;

break;

}

}

else

{

Slice* slice = frameEnc->m_encData->m_slice;

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0;

}
here are a few conclusions:

'--selective-sao 0 --sao' and '--selective-sao 4 --sao' and '--selective-sao 4 --no-sao' all do the same thing, they do the same as the old '--sao' (should be no surprise this causes confusion)
only '--selective-sao 0 --no-sao' disabled SAO
'--selective-sao X' with X > 0
man, that is a fugly coding style


Cu Selur

[Boulder]

--no-sao should definitely mean switching SAO off completely. It's ridiculous to add some other parameter affecting the choice.

[redbtn]

Another issue with selective-sao is no space between rd and selective-sao
MediaInfo shows rd=4selective-sao=0
I don't know how propertly create issue on bitbucket.
Hex Editor:

[LigH]

Possibly best choice to report a bug: x265 developer mailing list.

I forwarded your report, redbtn.

[Boulder]

Using the latest VS2019 AVX build (3.1+19-c4b098f) from here: http://msystem.waw.pl/x265/ crashes the encoder in the beginning. Does anyone else have the same issue? I'm using a Ryzen 1800X with AVX2 disabled in the x265 command line.

[benwaggoner]

What about new option --selective-sao? Anybody knows should i disable it, like --no-sao earlier?
https://bitbucket.org/multicoreware/x265/commits/5ac4c74c54188f968f53397f9b9cb15bec46df47?at=default
The broader question is what are the psychovisual and compression efficiency impact of the different modes. The documentation is tragically light on the "why" of this feature. SAO is fast enough that I don't see any direct perf advantage of this, although perhaps it might help parallelization in some esoteric way to only do SAO on non-predicted frames or something.

But if SAO detail loss varies somewhat by frame type, only using it on intra stuff might enhance detail with less of a compression efficiency hit than turning it off outright.

[LigH]

The media-autobuild suite now introduced experimental support for ccache.

About at the same time, I have issues building a multilib x265 encoder with the manually fiddled build script which usually worked for years already. But building in MABS passes without error.

I am not sure if I have too many linking flags which may interfere with either ccache or with the current development state of x265. It fails linking the DLL:

[ 84%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x2c): undefined reference to `x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x39): undefined reference to `x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x4f): undefined reference to `x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'
collect2.exe: error: ld returned 1 exit status

For a Win32 build, it fails only for the 8 bit precision library where assembler is used at all. For the Win64 build, it fails for all precisions as they all use assembler code.

[aymanalz]

Is it normal that x265 is about 20% slower on a Zen+ CPU than a Haswell, even though the Zen+ has a higher clock speed? I remember comments here about the AVX2 in AMD being only half as fast (?) as that in Intel, or something to that effect. Could that be the reason? Or could it be that the x265 developers haven't optimized the code for AMD as much as they have for Intel? It is a bit surprising, because this Zen+ architecture is from late 2018, a good few years later than Haswell.

[nevcairiel]

Is it normal that x265 is about 20% slower on a Zen+ CPU than a Haswell, even though the Zen+ has a higher clock speed? I remember comments here about the AVX2 in AMD being only half as fast (?) as that in Intel, or something to that effect. Could that be the reason?

Yes, the lack of full speed AVX2 is definitely a big factor, x265 uses a lot of it. Zen2 of course "solved" that shortcoming.

[NikosD]

Is it normal that x265 is about 20% slower on a Zen+ CPU than a Haswell, even though the Zen+ has a higher clock speed? I remember comments here about the AVX2 in AMD being only half as fast (?) as that in Intel, or something to that effect. Could that be the reason? Or could it be that the x265 developers haven't optimized the code for AMD as much as they have for Intel? Right on both.
Zen+ has a slower implementation of AVX2 than Haswell onwards, but x265 is also optimized for Intel and favors Intel vs AMD.
Actually, Intel published a paper along with x265 developers working together for AVX-512 optimizations (Intel-only) but they didn't manage to succeed in this, AVX-512 is so ineffective for x265 that most of the times you have to disable it according to Intel, not me.
x265 is an Intel-friendly project but Zen 2 architecture and Ryzen 3000 series managed to be a lot faster in x265 and beat Intel in its own favorite H.265 encoder.

[filler56789]

x265.exe 3.2_RC1+1-00d8df1b3bc6
(x64, multilib, GCC 9.2.0, upxed)

http://www.mediafire.com/file/k72pa2akgzo82m6/x265_3.2_RC1%252B1-00d8df1b3bc6.rar/file

[LigH]

I borrowed the toolchain files from the CMake call in MABS, now it builds again.

[mini-moose]

Zen2 of course "solved" that shortcoming.

The quotes on solved means they didn't solve it at all?

[Natty]

no changelog for 3.2?

[MeteorRain]

The quotes on solved means they didn't solve it at all?

Means it wasn't really an issue. So usually you say they improved the performance.

[Stereodude]

The quotes on solved means they didn't solve it at all?
They made a huge improvement in performance. I don't know why he used the quotes.

[Atak_Snajpera]

Improvements in Zen2 architecture are huge!
https://i.imgsafe.org/63/63a2e61a55.png

[FranceBB]

Very interesting chart indeed.
Is there another one which includes AVX512 as well?

[RanmaCanada]

Very interesting chart indeed.
Is there another one which includes AVX512 as well?

AVX512 is currently Intel only, and is "completely useless" for x265 as it produces way too much heat for the results.

https://forum.doom9.org/showthread.php?t=175476

https://www.reddit.com/r/programming/comments/8dhp7q/by_how_much_does_avx512_slow_down_your_cpu_a/

[Boulder]

I tested HME some more, and got quite interesting results.

Source 1080p filtered with my standard methods and downsized to 720p, merange 26 and my standard settings in x265. 1000 frames.

umh,umh,umh 2.05 fps / 5313,76 kbps
umh,umh,star 2.24 fps / 5314,31 kbps
umh,star,star 2.00 fps / 5327,91 kbps
star,star,star 2.01 fps / 5316,15 kbps
hex,umh,umh 2.03 fps / 5299,69 kbps

no HME, umh 2.64 fps / 5323,86 kbps
no HME, star 2.79 fps / 5325,69 kbps

I've now upgraded to 3700X and ran a similar test with that. The order of the results is still the same.

Can any of the devs (or anyone else, of course) explain why the combination "umh, umh, star" is clearly the fastest one? Without HME, the star method is clearly faster so I would expect "star, star, star" to be the fastest one with HME.

[mini-moose]

Can any of the devs (or anyone else, of course) explain why the combination "umh, umh, star" is clearly the fastest one? Without HME, the star method is clearly faster so I would expect "star, star, star" to be the fastest one with HME.

How is me=3 (star) faster than me=2 (umh)? thought the higher --me is, the slower it's supposed to be, maybe I'm wrong, I'm not expert.

Also, HME, is that a good feature to use?

[aymanalz]

How is me=3 (star) faster than me=2 (uhm)? thought the higher --me is, the slower it's supposed to be, maybe I'm wrong, I'm not expert.

Also, HME, is that a good feature to use?

Based on all user reports I have read, star gives comparable or better quality to umh but is equally fast. I'd like to know the truth of this as well - could any knowledgeable person please tell me if this is right?

Is Star a better method than umh in terms of:

1) Quality
2) Speed
3) Quality and speed

I's also like to take this opportunity to point out that there is a dearth of easily understandable documentation for x265. By that, I mean something for dummies like me. There are so many elementary questions that I cannot find answers to, despite all my googling.

[Boulder]

There's something broken in the latest versions, I've now tried two different builds but both have the same problem.

y4m [info]: 1920x1080 fps 24000/1001 i420p16 sar 1:1 unknown frame count
raw [info]: output file: f:\temp\captures\testclip.hevc
Error: fwrite() call failed when writing frame: 4, plane: 0, errno: 32
Output 22 frames in 1.66 seconds (13.23 fps)

This is just by loading the source in a Vapoursynth script and feeding it to x265 with vspipe. Many other clips work just fine.

The clip that causes this one can be found here:
https://drive.google.com/open?id=1AUVkTVe0FKTY9paTjdFwqqFfOZLgNr4M

x265-3.1+14 works fine.

[Boulder]

And my question that I posted to the x265 mailing list still has not been approved so I don't know if any dev saw the question regarding the motion search methods.

[Selur]

did a quick test trying to reproduce this here (did no filtering, just decoded with ffmpeg and piped to x265), for me too uhm was slower than star, but the speeds were similar.

--me star:
"I:\Hybrid\64bit\x265.exe" --preset medium --input - --output-depth 10 --y4m --profile main10 --me star --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --lookahead-slices 0 --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --output "E:\Temp\19_56_10_6810_02.265"
-> "encoded 2868 frames in 325.41s (8.81 fps), 4606.13 kb/s, Avg QP:23.78"
--me uhm:
"I:\Hybrid\64bit\x265.exe" --preset medium --input - --output-depth 10 --y4m --profile main10 --me umh --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --lookahead-slices 0 --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --output "E:\Temp\20_03_51_9010_02.265"
-> "encoded 2868 frames in 326.89s (8.77 fps), 4605.07 kb/s, Avg QP:23.78"
I used:
x265 [info]: HEVC encoder version 3.1+20-913823aa15cd
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
on a Ryzen 7 1800X

Ran the calls a second time this time I got:
--me star: "encoded 2868 frames in 320.13s (8.96 fps), 4606.13 kb/s, Avg QP:23.78"
--me umh: "encoded 2868 frames in 322.27s (8.90 fps), 4605.07 kb/s, Avg QP:23.78"

-> So here too, uhm is slower, but not a lot, so this might still be source depended.

[Boulder]

-> So here too, uhm is slower, but not a lot, so this might still be source depended.

There are some early exits in star which probably don't exist in umh, so that source dependency would make sense. The method is some kind of an adaptation of what's in HM encoder.

https://xevc.wordpress.com/2014/01/23/motion-estimation-of-hm-encoder/

[markiemarcus]

I've seen some gains from using umh instead of star on animated sources. Admittedly slight at 1080p, but definitely visible at 720p and below. On live action I really can't spot the difference.

[Barough]

x265 v3.2+3-fdd69a766881 (https://www.mediafire.com/file/qatcw0oquayw838/x265-3.2+3-fdd69a766881_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[Natty]

release notes for v3.2

https://bitbucket.org/multicoreware/x265/raw/353572437201d551381002aebf20d244bd49ef17/doc/reST/releasenotes.rst

[LigH]

The speed of "far" motion search algorithms depends on the average amount of motion. Some of them can terminate early if the optimum is found close to an intermediate step. Disclaimer: If I understood these algorithms correctly...

[Ma]

The clip that causes this one can be found here:
https://drive.google.com/open?id=1AUVkTVe0FKTY9paTjdFwqqFfOZLgNr4M

x265-3.1+14 works fine.

Could you specify your x265 options to reproduce the problem?

[Boulder]

Could you specify your x265 options to reproduce the problem?

This is what I've used for that one:
--input - --y4m --input-depth 16 --dither --sar 1:1 --profile main10
--rc-lookahead 120 --min-keyint 5 --keyint 480 --splitrd-skip --colorprim "bt709" --transfer "bt709" --colormatrix "bt709"
--preset slower --rd-refine --subme 4 --ctu 32 --qg-size 16 --limit-refs 1 --limit-tu 3 --bframes 16 --deblock -2:-1 --no-sao
--cbqpoffs -3 --crqpoffs -3 --hme --hme-search umh,umh,star --merange 26 --qcomp 0.7 --max-merge 2 --aq-mode 3 --aq-strength 0.6 --crf 18.5

[Selur]

does anyone have a current x265 build with stv ?