x265 HEVC Encoder

[pingfr]

Originally Posted by aymanalz

Yes, but with his i7-6700, I think he should definitely be getting faster encodes.

@pingfr : Are you sure there is nothing bottlenecking your system? Have you checked out your CPU usage during encoding? Is it always above 90%?

Reducing the maximum CU size to 32 can give a big speed boost. For resolutions less than 1080p, the difference in quality may not be significant. Same with merange.

Edit: I noticed that you are already using CTU 32. I'm pretty sure something is off, if you are only getting the speeds you say. Is hyperthreading turned on, are you using the appropriate values for threads/pools etc?

Everything seems normal to me: http://imgur.com/a/fYSy4

Also note this is a regular non-K, non unlocked i7-6700.

According to ARK, it's base frequency is 3.4GHz with a alleged Turbo Boost to 4.00GHz but for some reason throttles to 3.7GHz while under 100% load, it can however reach 4.0GHz on a single core.

https://ark.intel.com/products/88196...up-to-4_00-GHz

[Dclose]

Originally Posted by Leo 69

I never saw that switching on rectangular and asymmetric partitions would improve visual quality. I can't tell the difference whether they're on or off on any encodes.

I have. I never turn rectangle off after doing some tests of it. Sometimes I turn asymmetric off to increase speed since asymm is a worse quality/speed ratio than rectangle, but when I'm going for better quality I turn it on since it does help tighten up the picture a little more.

I easily noticed the difference again the other day when doing some tests. I was doing quality comparisons by watching the video play from four feet away on a 40" screen. Some people may think that's too close, while some people around here do their comparisons by zooming in on screenshots and analyzing pixels.

The biggest speed boost is probably Early Skip. The quality difference is generally quite obvious to me, but the speed increase is even more obvious. I'd say the higher the resolution (and bitrate), the less Early Skip hurts quality.

The more bitrate used, the less the quality settings matter. I'm usually dropping bitrate below what most people would think is acceptable, so the different quality settings tend to show differences more, so I rarely use speed boosts like Early Skip, and things like Max Merge can have a very noticeable difference on video quality.

[pradeeprama]

Originally Posted by pingfr

Could anyone here tell me which of the parameters included in the --preset veryslow compared to the --preset slow is the "culprit" dropping encoding speeds from 4fps to 0.30fps?

The idea is to retain most of the "quality improvements" from the veryslow preset while retaining the "merely acceptable" encoding speeds yield by the slow preset. There has to be some kind of middle grounds between both presets.

Thanks.

I suspect the top culprits for why fps drops so significantly with veryslow, when compared to slow preset is because of increased rd-level, increased subme, +1 reference frames, and enabling more TU search (--tu-inter 3 --tu-intra 3 in veryslow instead of --tu-inter 1 --tu-intra 1 that slow has).

I would recommend increasing --limit-ref and --limit-modes, enabling --limit-tu 4 and trying if that helps contain the drop in fps. There is another feature called --dynamic-rd that dynamically increases rd-level to 5 when you start with 4, but this works only when VBV parameters are used and they clip the quality due to excessive bits.

[aymanalz]

@pingfr : Maybe I'm missing it, but I cannot see a value for CPU load in the CPU-Z screenshot you provided. I only see info about the CPU itself. Open task manager (Win+shift+esc) to see how much of your CPU is being used. If the x265 executable is not using more than 90% all the time, you can be sure that there is a bottleneck somewhere.

Your rd-level is 6; that is definitely a major factor in speed. Reducing it to 4 can improve speed considerably. (Will quality loss be tolerable, I cannot say - you will have to test it out.) If I'm not mistaken, limit ref depth and CU only works for rd-level below 5. Those options give significant speed boost with little quality loss, but they are automatically disabled because your rd-level is too high.

[Midzuki]

x265 2.3+8-cfaff341e350

SAO: avoid negative indexes in 'x265_lambda2_tab' table

http://www.mediafire.com/file/0857vp...faff341e350.7z

[ShogoXT]

I think I am going to be getting one of the new 8 core Ryzen CPUs.

From the rumors ive been hearing about, its main weakness will be AVX.

Would it be worthwhile to benchmark and compare its speed on different instructions vs intel CPUs with the use of -asm using x265?

Thanks

[Midzuki]

According to commit 820f4327ddac... ,

CLI: Remove redundant cli option 'capture-csp'

OK, but now, ¿when MCW is going to finally correct the information shown below?

--bframes <integer>  Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4

[Ma]

Originally Posted by Midzuki

[...] ¿when MCW is going to finally correct the information shown below?

--bframes <integer>  Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4

This change will be OK?

diff -r 820f4327ddac source/x265cli.h
--- a/source/x265cli.h	Mon Feb 20 17:18:53 2017 +0530
+++ b/source/x265cli.h	Tue Feb 21 20:48:09 2017 +0100
@@ -391,7 +391,7 @@
     H0("   --rc-lookahead <integer>      Number of frames for frame-type lookahead (determines encoder latency) Default %d\n", param->lookaheadDepth);
     H1("   --lookahead-slices <0..16>    Number of slices to use per lookahead cost estimate. Default %d\n", param->lookaheadSlices);
     H0("   --lookahead-threads <integer> Number of threads to be dedicated to perform lookahead only. Default %d\n", param->lookaheadThreads);
-    H0("   --bframes <integer>           Maximum number of consecutive b-frames (now it only enables B GOP structure) Default %d\n", param->bframes);
+    H0("-b/--bframes <0..16>             Maximum number of consecutive b-frames. Default %d\n", param->bframes);
     H1("   --bframe-bias <integer>       Bias towards B frame decisions. Default %d\n", param->bFrameBias);
     H0("   --b-adapt <0..2>              0 - none, 1 - fast, 2 - full (trellis) adaptive B frame scheduling. Default %d\n", param->bFrameAdaptive);
     H0("   --[no-]b-pyramid              Use B-frames as references. Default %s\n", OPT(param->bBPyramid));

[Midzuki]

Originally Posted by Ma

This change will be OK?

diff -r 820f4327ddac source/x265cli.h
--- a/source/x265cli.h	Mon Feb 20 17:18:53 2017 +0530
+++ b/source/x265cli.h	Tue Feb 21 20:48:09 2017 +0100
@@ -391,7 +391,7 @@
     H0("   --rc-lookahead <integer>      Number of frames for frame-type lookahead (determines encoder latency) Default %d\n", param->lookaheadDepth);
     H1("   --lookahead-slices <0..16>    Number of slices to use per lookahead cost estimate. Default %d\n", param->lookaheadSlices);
     H0("   --lookahead-threads <integer> Number of threads to be dedicated to perform lookahead only. Default %d\n", param->lookaheadThreads);
-    H0("   --bframes <integer>           Maximum number of consecutive b-frames (now it only enables B GOP structure) Default %d\n", param->bframes);
+    H0("-b/--bframes <0..16>             Maximum number of consecutive b-frames. Default %d\n", param->bframes);
     H1("   --bframe-bias <integer>       Bias towards B frame decisions. Default %d\n", param->bFrameBias);
     H0("   --b-adapt <0..2>              0 - none, 1 - fast, 2 - full (trellis) adaptive B frame scheduling. Default %d\n", param->bFrameAdaptive);
     H0("   --[no-]b-pyramid              Use B-frames as references. Default %s\n", OPT(param->bBPyramid));

Thanks for asking.
Well, that's almost good. THIS is the right way to do it.

H0("-b/--bframes <0..16>             Maximum number of consecutive B-frames. Default %d\n", param->bframes);

H1("   --bframe-bias <integer>       Bias towards B-frame decisions. Default %d\n", param->bFrameBias);

H0("   --b-adapt <0..2>              0 - none, 1 - fast, 2 - full (trellis) adaptive B-frame scheduling. Default %d\n", param->bFrameAdaptive);

H0("   --[no-]b-pyramid              Use B-frames as references. Default %s\n", OPT(param->bBPyramid));

Because consistency matters.

[youli]

Options test: --aq-motion and --dynamic-rd.
Bitrate decrease about 3,5%.
Encoded 178944 frames in 107297.17s (1.67 fps), 18252.68 kb/s, Avg QP:24.23

MediaInfo:
Writing library : x265 2.2+36-9b975fec584a:[Windows][GCC 6.2.0][64 bit] 10bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x2160 / interlace=0 / total-frames=178944 / level-idc=50 / high-tier=1 / uhd-bd=0 / ref=1 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=2 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=16 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=4.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes / me=3 / subme=7 / merange=25 / temporal-mvp / weightp / weightb / no-analyze-src-pics / no-deblock / no-sao / no-sao-non-deblock / rd=3 / early-skip / no-rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=3.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=24.0 / qcomp=0.80 / qpstep=1 / stats-write=0 / stats-read=0 / vbv-maxrate=100000 / vbv-bufsize=100000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.10 / pbratio=1.10 / aq-mode=3 / aq-strength=0.60 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=16 / no-rc-grain / qpmax=51 / qpmin=0 / sar=16 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / 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 / aq-motion / no-hdr

Bitrate distribution:


Screenshots comparison:
Source BD3D (left eye) and Blu-Ray Rip Top-Bottom (left eye first) at 4914 second with bitrate 76592 kbps (maximum for this video).

[NikosD]

I was told by an Intel fanboy and RyZen 7 reviewer that you need a Core i7 7700K@4.8GHz to catch the performance of RyZen 7@4.0GHz at x265 2nd pass or you could see the same thing reversed.

Will see...

[pingfr]

Originally Posted by NikosD

I was told by an Intel fanboy and RyZen 7 reviewer that you need a Core i7 7700K@4.8GHz to catch the performance of RyZen 7@4.0GHz at x265 2nd pass or you could see the same thing reversed.

Will see...

Would love to see some substantial evidences.

[Atak_Snajpera]

Originally Posted by NikosD

I was told by an Intel fanboy and RyZen 7 reviewer that you need a Core i7 7700K@4.8GHz to catch the performance of RyZen 7@4.0GHz at x265 2nd pass or you could see the same thing reversed.

Will see...

Sound reasonable. AVX2 is about ~1.6x faster than AVX. Thanks to 2xAVX256+FMA Intel can still compete against 8c/16t CPU.

[pingfr]

@Atak_Snajpera: You've got the screenshots I've sent you earlier this week in PM?

[NikosD]

Originally Posted by Atak_Snajpera

Sound reasonable. AVX2 is about ~1.6x faster than AVX. Thanks to 2xAVX256+FMA Intel can still compete against 8c/16t CPU.

FMA has nothing to do with x265, because AFAIK x265 uses integers and FMA is for floating point numbers.

Integer AVX2 makes the difference, will see how much.

[Atak_Snajpera]

x264 and x265 use FMA3. See encoder's output 'using cpu capabilities'

[NikosD]

It doesn't matter if it lists CPU capabilities.

It really matters what exactly instructions x265 can use.

It would be a huge surprise if it could use FMA3 in a large extent or at all.

[pingfr]

Originally Posted by NikosD

It doesn't matter if it lists CPU capabilities.

It really matters what exactly instructions x265 can use.

It would be a huge surprise if it could use FMA3 in a large extent or at all.

See encoder's output 'using cpu capabilities'

Using:

verb (used with object), used, using.
1.
to employ for some purpose; put into service; make use of:
to use a knife.

Source: http://www.dictionary.com/browse/using?s=t

[NikosD]

Age ? 15 ?

[pingfr]

Originally Posted by NikosD

Age ? 15 ?

*shrug*