x265 HEVC Encoder

[benwaggoner]

Yeah. CRF fundamentally maps to QP, and while AVC and HEVC have similar QP scales, HEVC can do more with higher QP than AVC can. Any QP delta between x264 and x265 is going to vary based on profile and content. That said, I think the average CRF delta for the same subjective quality would be less than 4. That said, CRF 16 IS generally very high quality with x265. 10-12 are almost always psychovisually indistinguishable from 14 except for some heavy noise edge cases.

[Boulder]

At CRF 10-14, I wouldn't be surprised if the encode sometimes ended up at a higher average bitrate than the source itself :)

[Forteen88]

At CRF 10-14, I wouldn't be surprised if the encode sometimes ended up at a higher average bitrate than the source itself :)I hear that for HDR UHD video, CRF 14 isn't very extreme.

[stax76]

A test encode I did come out like this:


Source:

HEVC, Main 10@L5.1@High, 3840x2160, 23.976 FPS, 57.5 Mbps


Settings:

x265.exe --crf 14 --preset slower --output-depth 10


Result:

HEVC, Main 10@L5@Main, 3840x2160, 23.976 FPS, 32.9 Mbps


It was a sample from the movie Snow White and the Huntsman, had some noise, not particular much.


It would also be possible to add additional items, very, super, extreme, ludicrous...


My sample with the highest bitrate is:

HEVC, Main 10@L5.1@High, 3840x2160, 23.976 FPS, 70.0 Mb/s


Some old boring movie called Crash.

[Boulder]

I hear that for HDR UHD video, CRF 14 isn't very extreme.

True, HDR requires a significantly lower CRF to achieve visual transparency.

[benwaggoner]

True, HDR requires a significantly lower CRF to achieve visual transparency.
Having a perceptually uniform EOTF helps a lot, as QPs don't need to be lowered for dark regions. In SDR it's easy to seams between Y'=16 and Y'=17.

HDR always being 10-bit also helps.

Ballpark, HDR needs ~20% fewer bits than 8-bit SDR to get to a similar subjective quality.

[Blue_MiSfit]

Worth mentioning, x265 does require special tuning for good quality HDR.

The default hdr-opt is pretty good for PQ YCbCr (HDR10), but when encoding for Dolby Vision Profile 5 using PQ IPT (quite similar to ICtCp) masquerading as YCbCr, some additional tuning is needed to mitigate banding artifacts, even at high bitrates. I've seen some proprietary patches to x265 to improve performance here. Hopefully MCW makes something like this in mainline x265 :)

[Boulder]

Having a perceptually uniform EOTF helps a lot, as QPs don't need to be lowered for dark regions. In SDR it's easy to seams between Y'=16 and Y'=17.

HDR always being 10-bit also helps.

Ballpark, HDR needs ~20% fewer bits than 8-bit SDR to get to a similar subjective quality.

But CRF needs to be adjusted quite heavily. With my SDR settings + hdr-opt + HDR metadata, an encode of a HDR source produces a proportionally much smaller file than a similar one in SDR at CRF 18. With HDR sources, I tend to use CRF 14.

[benwaggoner]

Worth mentioning, x265 does require special tuning for good quality HDR.



The default hdr-opt is pretty good for PQ YCbCr (HDR10), but when encoding for Dolby Vision Profile 5 using PQ IPT (quite similar to ICtCp) masquerading as YCbCr, some additional tuning is needed to mitigate banding artifacts, even at high bitrates. I've seen some proprietary patches to x265 to improve performance here. Hopefully MCW makes something like this in mainline x265 :)There's a whole different optimization flag for doing Profile 5, tuned for Y'CtCp instead of Y'CbCr.

Sent from my SM-T837V using Tapatalk

[Blue_MiSfit]

In mainline x265? Do tell. I've been using a patched 3.0 build for quite awhile.

[benwaggoner]

In mainline x265? Do tell. I've been using a patched 3.0 build for quite awhile.
Maybe it was in a private build or something. There was a chroma qp offset in it to leverage Y'CtCp.

There's a lot of other good stuff added between 3.0 and 3.4, though!

https://x265.readthedocs.io/en/default/releasenotes.html

[theincognito]

Here (http://www.mediafire.com/file/6920cu884gwplxk/ffmpeg-N-98036-gd538ca5175-gb6d7c4c1d4-gcc10.1.0.7z/file) :D

If it's not too much, can you build a test msvc avx2 build, with M support? x265 obviously. :)

[Patman]

If it's not too much, can you build a test msvc avx2 build, with M support? x265 obviously. :)

I did this some time ago, but there is no need to define the instruction set. My versions support all instruction sets and there is no speed increase.

[theincognito]

I did this some time ago, but there is no need to define the instruction set. My versions support all instruction sets and there is no speed increase.

Okay. Thank you. :)

[LigH]

New upload: x265 3.4+7-g38774073d (https://www.mediafire.com/file/musijhlvyke0wq1/x265_3.4+7-g38774073d.7z/file)

Fixed the normalization formula to ouput 0 to 1 and considered max chroma histogram SAD in histogram based scene cut detection

[charliebaby]

Thank you for 3.4+7 LigH :-)

[JoyBell]

x265 3.4+7
--analysis-reuse-level <1..10> Level of analysis reuse indicates amount of info stored/reused in save/load mode, 1:least..10:most. Now deprecated. Default 0

umm. I used these feature exclusively (since I finally got it to work about a year ago) on all my encodes. Is it coming back, is it default for all 2 pass, what is going on?

[charliebaby]

HolyWy Thank you i am test me Threadripper 2990wx 32 core

test 1080p 3min : http://prntscr.com/t7tvjc

[Greenhorn]

umm. I used these feature exclusively (since I finally got it to work about a year ago) on all my encodes. Is it coming back, is it default for all 2 pass, what is going on?

It's been split into 2 different options-- "analysis-save-reuse-level" and "analysis-load-reuse-level".
If you set them to the same values the reuse function should work like before.

[-QfG-]

HolyWy Thank you i am test me Threadripper 2990wx 32 core

test 1080p 3min : http://prntscr.com/t7tvjc

Can u tell me, what switches i must use, for creating 4 thread pools with 8 Threads?

[charliebaby]

Can u tell me, what switches i must use, for creating 4 thread pools with 8 Threads?

hello if you have an amd cpu disabled threads in the bios on the name of SMT to gain power and added ca --pools 4,4,4,4 ;)

[charliebaby]

new FFMPEG 4.3 : https://www.videohelp.com/software/ffmpeg

[quietvoid]

So x265 3.4+9, they "fixed" --hist-threshold to avoid false positives. However it seems to do much worse than before (as well as 3.4+7, where they fixed the false positives).
I'm getting less I frames with --hist-threshold 0.005 (default 0.03) than the default scenecut algorithm..

Maybe my sample clip is not colorful enough..

[LigH]

New upload: x265 3.4+9-g1fb7c7960 (https://www.mediafire.com/file/j6z95t66pzz0t9x/x265_3.4+9-g1fb7c7960.7z/file)

Improvements to hist-based scenecut algorithm.
Add support for RADL pictures at IDR scenecuts

[charliebaby]

New upload: x265 3.4+9-g1fb7c7960 (https://www.mediafire.com/file/j6z95t66pzz0t9x/x265_3.4+9-g1fb7c7960.7z/file)

Improvements to hist-based scenecut algorithm.
Add support for RADL pictures at IDR scenecuts

Thank you

[benwaggoner]

So x265 3.4+9, they "fixed" --hist-threshold to avoid false positives. However it seems to do much worse than before (as well as 3.4+7, where they fixed the false positives).
I'm getting less I frames with --hist-threshold 0.005 (default 0.03) than the default scenecut algorithm..

Maybe my sample clip is not colorful enough..
Do you mean IDR or also non-IDR I-frames?

Fewer I frames isn't problem in itself. The question is if it is not flagging edits and such as IDR. Beyond that, IDR and I should only be used when it improves compression efficiency, or as needed based on --keyint.

[quietvoid]

Do you mean IDR or also non-IDR I-frames?

Fewer I frames isn't problem in itself. The question is if it is not flagging edits and such as IDR. Beyond that, IDR and I should only be used when it improves compression efficiency, or as needed based on --keyint.

I'm not sure, whichever x265 reports as "I frame" in the final log/stats. I do use --no-open-gop, so I assume they are all IDR.
From what I understand, detected scene cuts should start with an I frame, as it is how adaptive keyframe placement works.

[Rousseau]

Does analysis-save always write such huge files at values above 1? I tried a 128MB sample file and it created a multi-gigabyte save file (writing at 60mb/s which significantly slowed down the encode).

Also, it only seems to work with ref=1 in the second pass if you are using --no-slow-firstpass , otherwise I get:

Error reading analysis data. Incompatible option : <ref>


This is with x265 3.3+5-g4a0cef17d+32 and 3.4+9-g1fb7c7960

[charliebaby]

x265 3.4.10 https://www.free-codecs.com/x265_hevc_encoder_download.htm

VS 2015
VS 2019
GCC 10.1

[Barough]

x265 v3.4+10-g7a640a2c1 (https://www.mediafire.com/file/qx7lwbur52u19lp/x265-3.4+10-g7a640a2c1_Win_GCC101.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.1.0)
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[Barough]

x265 v3.4+11-gee5a266a1 (https://www.mediafire.com/file/pzljihjsierisfp/x265-3.4+11-gee5a266a1_Win_GCC101.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.1.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

https://bitbucket.org/multicoreware/x265_git/commits/ee5a266a1055222faff6c319c7589ddcbef3f9d1

[-QfG-]

Have anyone an idea, how i can change the Info string in the sourcefiles of the Encoder? For Example, it likes so:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 26 min
Bit rate : 7 441 kb/s
Width : 3 840 pixels
Height : 1 608 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.050
Stream size : 4.50 GiB (65%)
Writing library : x265 3.2: QfG-Edition
Encoding settings : Encoded-by-QfG / CRF=16.0 / High-Quality
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 712 cd/m2
Maximum Frame-Average Light Level : 355 cd/m2

Thanks the guy, who can tell me this.

[LigH]

Compile your own x265.exe after changing its C/C++ sources accordingly.

[charliebaby]

Have anyone an idea, how i can change the Info string in the sourcefiles of the Encoder? For Example, it likes so:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 26 min
Bit rate : 7 441 kb/s
Width : 3 840 pixels
Height : 1 608 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.050
Stream size : 4.50 GiB (65%)
Writing library : x265 3.2: QfG-Edition
Encoding settings : Encoded-by-QfG / CRF=16.0 / High-Quality
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 712 cd/m2
Maximum Frame-Average Light Level : 355 cd/m2

Thanks the guy, who can tell me this.

don't put a pool and see if it works otherwise you have to try --pool 16 or 8,8

[theincognito]

Compile your own x265.exe after changing its C/C++ sources accordingly.

I use MSVC/ICC builds interchangeably on my intel cpu with avx2 and they seem to be faster for me than GCC builds.

I am planning to buy a Ryzen 7 3rd gen. Which type of build will be the best for it? Any idea? Thanks in advance :)

[theincognito]

And...

One more thing. Anyone here tried aq-mode 4 and got results? Or could explain to me the use case for it? I read the official docs, and to be honest, didn't understand it.

[charliebaby]

I use MSVC/ICC builds interchangeably on my intel cpu with avx2 and they seem to be faster for me than GCC builds.

I am planning to buy a Ryzen 7 3rd gen. Which type of build will be the best for it? Any idea? Thanks in advance :)

I have a 2990wx threadripper and the best for me is the GCC 6.30

here : http://www.mediafire.com/file/p4rf0sayt8wl7by/x265_3.4.0.2_x64.zip/file

:)

[LigH]

Since my last reply, at least two answers posted here seem to have no obvious relation to the questions they quoted... :confused:

[theincognito]

I have a 2990wx threadripper and the best for me is the GCC 6.30

here : http://www.mediafire.com/file/p4rf0sayt8wl7by/x265_3.4.0.2_x64.zip/file

:)

Thanks a lot :)

[theincognito]

Since my last reply, at least two answers posted here seem to have no obvious relation to the questions they quoted... :confused:

Can you help me with the below? :D

And...

One more thing. Anyone here tried aq-mode 4 and got results? Or could explain to me the use case for it? I read the official docs, and to be honest, didn't understand it.

[charliebaby]

Can you help me with the below? :D

AQ-Mode 1 is the Best dont not change :-)

[charliebaby]

x265-3.4+12 VS2019 + GCC 10.1

http://www.mediafire.com/file/iniffp4509rzazt/x265-3.4%252B12-geff9.zip/file

[vpupkind]

And...

One more thing. Anyone here tried aq-mode 4 and got results? Or could explain to me the use case for it? I read the official docs, and to be honest, didn't understand it.

The premise is that the human visual system is less sensitive to edges than flat areas. The approach is known to work, but needs a ton of tuning.

[benwaggoner]

The premise is that the human visual system is less sensitive to edges than flat areas. The approach is known to work, but needs a ton of tuning.
It's actually the other way around: we are much more sensitive to edges (transitions) than to flat areas without any detail. Those are better encoded as frequencies than as spatial pixel values, which is why all lossy still and video codecs use some sort of sine/cosine/wavelet transform.

For adaptive quantization, it's more that the human eye can see errors in frequencies a lot more clearly in smooth areas than textured ones, because that creates edges that weren't there before. Blocking and ringing are a lot easier to see in an area where there shouldn't be detail at all. A bunch of foliage can have slight frequency errors which get masked by all the edges and detail already there.

[Boulder]

I find that all those special edge related AQ modes generally mess any noisy flat areas of the image, causing the floating wall of noise defect I strongly dislike. I don't know if tuning the strength helps but mode 1 still works best for me. Strength 0.8-1.0, lower for noisier material, higher for clean.

[Forteen88]

I find that all those special edge related AQ modes generally mess any noisy flat areas of the image, causing the floating wall of noise defect I strongly dislike. I don't know if tuning the strength helps but mode 1 still works best for me. Strength 0.8-1.0, lower for noisier material, higher for clean.But --tune animation
which is clean (I assume that they mean clean) cartoon, sets (among other things),
--aq-strength 0.4

[Boulder]

If I'm not entirely mistaken, the whole idea of aq-strength is to adjust the amount of bits shifted from more complex blocks (like ones with edges etc.) to simple ones (like a flat background).

From an old x264 thread:

High AQ strength retains more gradients but produces ringing.
Low AQ strength preserves edges but produces banding.

My theory here is that the random noise itself is complex and could actually be harder to compress than something with clear edges and detail. Lowering the strength should not cause excessive banding as the flat areas with noise already attract bits and are not really flat in terms of the encoder. In some tests I did, lowering the strength from 1.0 to 0.8 can cause the bitrate to drop around 10% with other settings remaining the same.

With animation and cartoons, aq-mode 2 could well work because they are very different beasts compared to normal, real-life footage.

[markiemarcus]

With animation and cartoons, aq-mode 2 could well work because they are very different beasts compared to normal, real-life footage.

In my experience, Aq mode 2 is indeed more forgiving in animation and typically results in less ringing. The difference can be very pronounced with SAO disabled. You can get decent results with Aq mode 1, but finding the optimal aq strength is both a massive pain and essential IMO.

Aq mode 4 also works well, but it's also quite a bit slower.

[benwaggoner]

Netflix's Sol Levante is the first creative commons licensed 4K HDR anime-style animation I've seen yet, and makes for some very interesting aq-mode and aq-strength testing.

https://netflixtechblog.com/bringing-4k-and-hdr-to-anime-at-netflix-with-sol-levante-fa68105067cd

And don't forget --hevc-aq, aka --aq-mode 5. I suspect, but have not demonstrated, it could be quite good for line-art style animation.

While lines are blurring a lot in the computer-assisted era, the classic differential attributes of cel animation are:

No motion blur
extremely sharp lines demarcating areas of extremely flat color
Many repeat frames and areas that are identical between many frames


Just look a the --log-level 2 .csv of natural image and cel content and you'll see how different the distribution of block sizes and types is.

[Selur]

Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

I tried with:
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | "I:\Hybrid\64bit\x265.exe" --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --pass 1 --slow-firstpass --bitrate 1500 --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 bt470bg --stats "E:\Temp\test_generated.stats" --analysis-save "E:\Temp\test_generated.analysis" --analysis-reuse-level 6 --no-multi-pass-opt-analysis --output "E:\Temp\test.265"
for the 2pass 1st pass, which seems to run fine:
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\test.265
x265 [info]: HEVC encoder version 3.4+7-g38774073d
x265 [info]: build info [Windows][GCC 10.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: analysis-load-reuse-level can be set only when analysis-load is enabled. Resetting analysis-load-reuse-level to 0.
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(6 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
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]: Cb/Cr QP Offset : -2 / -2
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 / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60
x265 [info]: tools: limit-modes rd=3 ssim-rd psy-rd=2.50 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: rskip mode=1 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-write
x265 [info]: frame I: 3, Avg QP:16.35 kb/s: 3518.73
x265 [info]: frame P: 120, Avg QP:13.21 kb/s: 3109.91
x265 [info]: frame B: 306, Avg QP:17.58 kb/s: 770.49
x265 [info]: Weighted P-Frames: Y:0.8% UV:0.8%
x265 [info]: consecutive B-frames: 3.3% 0.0% 58.5% 21.1% 17.1%
encoded 429 frames in 15.97s (26.86 fps), 1444.09 kb/s, Avg QP:16.35
Not sure about the:
x265 [warning]: analysis-load-reuse-level can be set only when analysis-load is enabled. Resetting analysis-load-reuse-level to 0.

Then I started a 2pass 2nd pass with:
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | "I:\Hybrid\64bit\x265.exe" --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --pass 2 --bitrate 1500 --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 bt470bg --stats "E:\Temp\test_generated.stats" --analysis-load "E:\Temp\test_generated.analysis" --analysis-reuse-level 6 --no-multi-pass-opt-analysis --no-dynamic-refine --refine-ctu-distortion 1 --output "E:\Temp\2020-07-12@16_54_18_4110_03.265"
which starts fine:
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\2020-07-12@16_54_18_4110_03.265
x265 [info]: HEVC encoder version 3.4+7-g38774073d
x265 [info]: build info [Windows][GCC 10.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: analysis-save-reuse-level can be set only when analysis-save is enabled. Resetting analysis-save-reuse-level to 0.
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(6 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
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]: Cb/Cr QP Offset : -2 / -2
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 / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60
x265 [info]: tools: limit-modes rd=3 ssim-rd psy-rd=2.50 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: rskip mode=1 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read

but then nothing happens.
x265 is running, but seemingly not doing anything.

Also tried with HEVC "encoder version 3.4+12-geff904199" same effect.

-> Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

Cu Selur