x265 HEVC Encoder

[LigH]

The announced "big fat AVX2 patch collection" is now included in x265 1.5+128-394c2f94a2dc (https://www.mediafire.com/download/khw7h4cocv4xm89/x265_1.5+128-394c2f94a2dc.7z)

[shinchiro]

The announced "big fat AVX2 patch collection" is now included in x265 1.5+128-394c2f94a2dc (https://www.mediafire.com/download/khw7h4cocv4xm89/x265_1.5+128-394c2f94a2dc.7z)
How much fps gained now when encoding on haswell :D More than ~3fps?

[LigH]

Depends on material, preset, resolution ... an absolute number of fps would be the least intelligent unit to measure.

From the mailing list announcement:

They give about a 6% gain in performance on AVX2 capable CPUs.

What's your experience, can you prove this estimation with your specific testing material?

[Ma]

I've made test with 16bpp x265: encoding 2401 frames with resolution 1920x800 (via MeGUI) on i5 3450S, Windows 7 64-bit.
x265 build 1.5+27 (chromashift x265-1.5.27-highbitdepth-msvc2012-64.7z) -- 979.92 s (2.08 fps)
x265 build 1.5+128 (chromashift x265-1.5.128-highbitdepth-msvc2012-64.7z) -- 1001.31 s (2.04 fps)

I have 2.2% lost in speed with new version (but my CPU is without AVX2).

[Ma]

I investigated why the new build 1.5+128 of 16bpp x265 is 2.2% slower than 1.5+27 and I noticed that this is the reason:
https://bitbucket.org/multicoreware/x265/commits/fa3fd0b3fe12453d3bf538a866e68ae4534330a0

If I revert changes to "hg update 9563" and build 16bpp x265 -- it is fast. If I revert to "hg update 9564" -- it is slow.

[evilr00t]

I've also seen a slowdown on my dual proc Sandy Bridge Xeon (8core/16thread per CPU) system. Before NUMA pools, I was able to saturate all CPUs in the system with pmode*, now no matter what, I'm unable to get a significant load on the second CPU.

I tried:
--pools +,+
--pools 8,8 (only the first CPU gets used consistently)
--pools 16,16 (only the first CPU gets used consistently)

Running Windows Server 2012 R2. Maybe this is Windows.

*With a 720p source:
1.4+527 - 6 frames per second on veryslow+pmode. CPU use is 80% CPU1, 95% CPU2.
1.5+128 - 3.5 frames per second on veryslow+pmode. CPU use is 100% CPU1, 10-20% CPU2.
Figures are approximate. The system is at work.

[Fantasy]

Script:

Or you can use a tool like ffmpeg (http://ffmpeg.zeranoe.com/builds/) if you don't need any AviSynth processing (no script file needed):
[code]ffmpeg.exe -i "C:\Users\...\video.mp4" -f yuv4mpegpipe - | F:\MeGUI_2418_x86\tools\x265\x64\x265.exe - --y4m --bitrate 25000 --pass 1 -o test-firstpass.hevc
ffmpeg.exe -i "C:\Users\...\video.mp4" -f yuv4mpegpipe - | F:\MeGUI_2418_x86\tools\x265\x64\x265.exe - --y4m --bitrate 25000 --pass 2 -o test.hevc

(I removed some parts of your command that are not necessary)
thank you, even a beginnner like me can use this code by copy paste. Now I can use x265 without megui.

That's because the first half is an AviSynth script, not a batch. The first two lines could not be executed on a command line prompt, so they can't in a batch file either.

Besides, DirectShowSource is always my last choice, only chosen if all other possible source plugins failed. DirectShow as such has a priority to play video fast, even if that means to reduce quality or even skip frames, except you really know your installed filters and how to tweak them. Instead, native AviSynth decoders (like FFMS2 / L-SMASH Source / DGDecNV / DGDecIM) have a priority to provide exact decoding results, even if that may take a bit more time.

Is it at all necessary to change the frame rate to "ntsc_double" (FPS preset (http://avisynth.nl/index.php/FPS))? Does your original video not already have that frame rate?

My original Video has already 60 fps and is progessiv format. Now I am using ffmpeg (some thing like FFMS2), thanks for your advice.

Now I have a question about 10 bit. My source file is 8 bit. I want 10 bit output. Do I have to convert it to 10 bit first or x265 will do it for me like x264?
I think for 10 bit I should use x265 win64 16 bit.

[sneaker_ger]

Now I have a question about 10 bit. My source file is 8 bit. I want 10 bit output. Do I have to convert it to 10 bit first or x265 will do it for me like x264?
It works like x264, i.e. just use the high bitdepth build of x265 and it will work automatically.

I think for 10 bit I should use x265 win64 16 bit.
Correct.

[Ajvar]

Hey people, just a quick noob question. If I do a first pass x265 encode (lets say 3000kbps), can I use those stats files for 2-nd pass with higher bitrate (like 4000) without disadvantages if I am not satisfied with quality? TNX!

P.S. Yes, I know about CRFactor mode.

[Asmodian]

No. ;)

[LigH]

I guess you may alter only the bitrate for the 2nd pass; but you should expect the result possibly not match this target well, and the achieved quality be not always optimal. But don't judge by the quality of the 1st pass result, this one is not optimal for sure.

[benwaggoner]

I guess you may alter only the bitrate for the 2nd pass; but you should expect the result possibly not match this target well, and the achieved quality be not always optimal. But don't judge by the quality of the 1st pass result, this one is not optimal for sure.
But it will be pretty close.

A first pass at 3000 Kbps will do pretty well encoding a 2000 or 4000 Kbps 2nd pass. x264 can even do okay when changing frame sizes some; I've not tried this with x265. It won't be the optimal perfect encode, but can make sense for quality @ speed scenarios, since the time saved from doing multiple first passes can be spent on higher quality second passes.

[Ajvar]

Thanks guys. I played the raw h265 file from temp directory of non finished 2nd pass and was not happy with the result. After all CRF 22.7 is the easiest way even if it takes 6000 kb/s for my FullHD videos.

On the side note... I guess I want to give my feedback. What IF there would be a hybrid CRF Pass mode with max limit bit rate? Like CRF 18 but not higher 6000 kbps where it would encode in CRF but would not exceed max bitrate for 1 sec/keint/P+consequent B frames to the max limit I set OR encode in CRF but would reencode it with all stats data automatically if it exceeds 6000 kbps limit. First method I like more.
For example, you want to set CRF X for all your videos (100) but they are all different of course and some may have some bitrate cost FX effects which actually are not necessarily to keep as transparent as over 6000kbps OR as expensive as it would increased overall video average bitrate.
What do you think, am I dreaming in stupidness?

[qyot27]

That's [essentially] CRF+VBV, isn't it? --crf-max and a defined --vbv-maxrate, or something. I've never bothered with any of that for either H.264 or HEVC.

[Ajvar]

That's [essentially] CRF+VBV, isn't it? --crf-max and a defined --vbv-maxrate, or something. I've never bothered with any of that for either H.264 or HEVC.

Wow! Cool. Just googled about it and found not much. Wil read x265 help page with commands.

[Ma]

I build x265 1.5+141 16bpp and try encoding via MeGUI -- it crashes.
I try 1.5+140 16bpp -- it works via MeGUI.

Log from MeGUI:
---[Information] [2015-03-04 20:12:04] avs4x265 [info]: "C:\MeGUI\tools\x265\x64\x265.exe" - --frames 2041 --fps 24000/1001 --input-res 1920x800 --input-csp i420 --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info --output F:\m\v\0001.mkv.hevc
--[Error] [2015-03-04 20:11:44] Standard error stream
---[Information] [2015-03-04 20:11:44] yuv [info]: 1920x800 fps 24000/1001 i420p8 unknown frame count
---[Information] [2015-03-04 20:11:44] x265 [info]: HEVC encoder version 1.5+141-e212eee15e98
---[Information] [2015-03-04 20:11:44] x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 16bpp
---[Information] [2015-03-04 20:11:44] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [2015-03-04 20:11:44] x265 [info]: Main 10 profile, Level-4 (Main tier)
---[Information] [2015-03-04 20:11:44] x265 [info]: Thread pool created using 4 threads
---[Information] [2015-03-04 20:11:44] x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
---[Information] [2015-03-04 20:11:44] x265 [info]: Internal bit depth : 10
---[Information] [2015-03-04 20:11:44] x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
---[Information] [2015-03-04 20:11:44] x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
---[Information] [2015-03-04 20:11:44] x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
---[Information] [2015-03-04 20:11:44] x265 [info]: Keyframe min / max / scenecut : 23 / 288 / 40
---[Information] [2015-03-04 20:11:44] x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
---[Information] [2015-03-04 20:11:44] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
---[Information] [2015-03-04 20:11:44] x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-18.5 / 1.0 / 1
---[Information] [2015-03-04 20:11:44] x265 [info]: tools: rect rd=4 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp
---[Error] [2015-03-04 20:12:04] avs [error]: Error occurred while writing frame 38
---[Information] [2015-03-04 20:12:04] (Maybe x265.exe closed)
--[Error] [2015-03-04 20:12:04] Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)

[x265_Project]

I build x265 1.5+141 16bpp and try encoding via MeGUI -- it crashes.
I try 1.5+140 16bpp -- it works via MeGUI.

Log from MeGUI:
---[Information] [2015-03-04 20:12:04] avs4x265 [info]: "C:\MeGUI\tools\x265\x64\x265.exe" - --frames 2041 --fps 24000/1001 --input-res 1920x800 --input-csp i420 --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info --output F:\m\v\0001.mkv.hevc
--[Error] [2015-03-04 20:11:44] Standard error stream
---[Information] [2015-03-04 20:11:44] yuv [info]: 1920x800 fps 24000/1001 i420p8 unknown frame count
---[Information] [2015-03-04 20:11:44] x265 [info]: HEVC encoder version 1.5+141-e212eee15e98
---[Information] [2015-03-04 20:11:44] x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 16bpp
---[Information] [2015-03-04 20:11:44] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [2015-03-04 20:11:44] x265 [info]: Main 10 profile, Level-4 (Main tier)
---[Information] [2015-03-04 20:11:44] x265 [info]: Thread pool created using 4 threads
---[Information] [2015-03-04 20:11:44] x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
---[Information] [2015-03-04 20:11:44] x265 [info]: Internal bit depth : 10
---[Information] [2015-03-04 20:11:44] x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
---[Information] [2015-03-04 20:11:44] x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
---[Information] [2015-03-04 20:11:44] x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
---[Information] [2015-03-04 20:11:44] x265 [info]: Keyframe min / max / scenecut : 23 / 288 / 40
---[Information] [2015-03-04 20:11:44] x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
---[Information] [2015-03-04 20:11:44] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
---[Information] [2015-03-04 20:11:44] x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-18.5 / 1.0 / 1
---[Information] [2015-03-04 20:11:44] x265 [info]: tools: rect rd=4 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp
---[Error] [2015-03-04 20:12:04] avs [error]: Error occurred while writing frame 38
---[Information] [2015-03-04 20:12:04] (Maybe x265.exe closed)
--[Error] [2015-03-04 20:12:04] Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)

Avoid this build... there are definite issues. We're on it.

[x265_Project]

Avoid this build... there are definite issues. We're on it.

Steve just checked in a fix that solves the slow performance I was seeing. Please give the new dev build a try, and let us know if you still see issues.

[Ma]

Steve just checked in a fix that solves the slow performance I was seeing. Please give the new dev build a try, and let us know if you still see issues.

1.5+142 16bpp works via MeGUI.
I use GCC 4.9.2 from mingw-w64 with win32threads.
Thanks for the fix.

[Ajvar]

Anybody wants to compare non-AVX2 performance of new 151 build?

[LigH]

I'll do that very briefly, just have to compile it...

[Ma]

Anybody wants to compare non-AVX2 performance of new 151 build?

16bpp with my test file:
1.5.0.0 | 975.92s | 2.09fps
1.5.0.142 | 993.40s | 2.05fps
1.5.0.151 | 998.18s | 2.04fps

[LigH]

Between v1.5+9 and v1.5+151 (also v1.5+21, v1.5+77) I see hardly any difference. Tested on AMD Phenom-II X4 (max.instruction set: SSE2)

[benwaggoner]

16bpp with my test file:
1.5.0.0 | 975.92s | 2.09fps
1.5.0.142 | 993.40s | 2.05fps
1.5.0.151 | 998.18s | 2.04fps
It would be great to see performance with AVX2 instructions turned on and off on the same AVX2 capable processor.

I expect that that speedup percentage could vary substantially between different presets, so it'd be good to provide the full command line.

[Vesdaris]

Is there any way to reduce blur at medium preset? Maybe via command line specific options?Changing to slow didn't change anything at first glance and fps was totally unacceptable.

Cheers

[jlpsvk]

I am using SLOW preset on i7-4790K....getting around 2.5fps...which is acceptable for me. :)

[Ma]

I decided to make speed test of x265 with special conditions:
- unplug network cable from router,
- turn off antivirus,
- close all other applications,
- run each test twice and take the better result.

Platform: i5 3450S, 16GB DDR3 RAM 1600MHz, Win 7 64bit.
Parametrs: --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info

Results:
16bpp
1.5.0.000 | 976.53s | 2.09fps | 100.0% | gcc492 -O2 -march=corei7-avx
1.5.0.021 | 984.82s | 2.07fps | 100.8% | LigH gcc482 -O3
1.5.0.027 | 979.67s | 2.08fps | 100.3% | msvc2012
1.5.0.041 | 973.17s | 2.10fps | 99.7% | gcc492 -O2 -march=corei7-avx
1.5.0.129 | 995.47s | 2.05fps | 101.9% | gcc492 -O2 -march=corei7-avx
1.5.0.151 | 992.89s | 2.06fps | 101.7% | gcc492 -O2 -march=corei7-avx

8bpp
1.5.0.000 | 593.88s | 3.44fps | 100.0% | gcc492 -O2 -march=corei7-avx
1.5.0.021 | 603.47s | 3.38fps | 101.6% | LigH gcc482 -O3
1.5.0.027 | 605.70s | 3.37fps | 102.0% | msvc2012
1.5.0.041 | 592.65s | 3.44fps | 99.8% | gcc492 -O2 -march=corei7-avx
1.5.0.129 | 612.45s | 3.33fps | 103.1% | gcc492 -O2 -march=corei7-avx
1.5.0.151 | 610.61s | 3.34fps | 102.8% | gcc492 -O2 -march=corei7-avx

On my system GCC 4.9.2 is faster than 4.8.2, -O2 optimize option is faster than default -O3, -march=corei7-avx is faster than generic build.

My first speed test of 1.5.0.151 was on working computer and wasn't precise.

[x265.cc]

Anybody wants to compare non-AVX2 performance of new 151 build?



x265 Build:
x265 [info]: HEVC encoder version 1.5+175-45deb0125890
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp

Hardware:
Intel® Core™ i7-4710HQ Processor
(6M Cache, up to 3.50 GHz)

Test sample:
http://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

With AVX2:

x265 --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,AVX2,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+175-45deb0125890
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / 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 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 rdoq=0 psy-rd=0.30 deblock sao signhide tmvp

x265 [info]: frame I: 4, Avg QP:29.78 kb/s: 23949.00
x265 [info]: frame P: 122, Avg QP:34.06 kb/s: 12920.50
x265 [info]: frame B: 378, Avg QP:40.38 kb/s: 472.61
x265 [info]: global : 504, Avg QP:38.77 kb/s: 3672.11
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.2% 3.2% 7.9% 61.9% 23.8%

encoded 504 frames in 18.61s (27.08 fps), 3672.11 kb/s

Without AVX2:

x265 --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+175-45deb0125890
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / 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 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 rdoq=0 psy-rd=0.30 deblock sao signhide tmvp

x265 [info]: frame I: 4, Avg QP:29.78 kb/s: 23949.00
x265 [info]: frame P: 122, Avg QP:34.06 kb/s: 12920.50
x265 [info]: frame B: 378, Avg QP:40.38 kb/s: 472.61
x265 [info]: global : 504, Avg QP:38.77 kb/s: 3672.11
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.2% 3.2% 7.9% 61.9% 23.8%

encoded 504 frames in 21.73s (23.19 fps), 3672.11 kb/s

[LigH]

New results (http://forum.gleitz.info/showthread.php?46557&p=449921#post449921) with freshly built Mac binaries at tags 1.4, 1.5 and tip (1.5+175) on a Dual Xeon X5675 @ 3.07GHz (2 sockets × 6 physical cores × 2 HT = 24 logical cores):

CPU utilization rises from v1.4 (~1200%/24) to v1.5 (~1400%/24), but drops remarkably for the current version (~900%/24). Yet the speed still rises from v1.4 (4.46 fps) over v1.5 (5.24 fps) to the current (6.60 fps).

So with about a third of the CPU capacity taken by one running encoder, it is even possible to run three encoders in parallel to utilize the CPU well (up to 2400%/24).

[benwaggoner]

x265 Build:
With AVX2: encoded 504 frames in 18.61s (27.08 fps), 3672.11 kb/s

Without AVX2:encoded 504 frames in 21.73s (23.19 fps), 3672.11 kb/s

So, 17% faster on the same hardware by just turning on an instruction set? Pretty impressive, and significantly larger than the similar post-SSE2 instruction-set gains I remember from x265.

I wonder what the comparison would look like with --preset slower or veryslow.

[FranceBB]

Compiled builds for Windows XP either, enjoy: https://mega.co.nz/#!fFUm2KZQ!FxMu8xKqzKVG2x7HnV1FyJO0htp-5-bdUp5c_g_jctI

As to the speed, I can tell that using GCC, ICC or Visual Studio there is a slight difference. With a silly encode with preset "medium", crf 20 and everything on default, GCC build run at 9.34 fps, ICC build run at 9.43 and Visual Studio build run at 9.46 on the same video with the same settings.

Anyway, I'll keep supporting xp 'cause there are still a lot of people using that OS.

[benwaggoner]

Anyway, I'll keep supporting xp 'cause there are still a lot of people using that OS.
That said, professional and prosumer encoding really should have moved to at least Windows 7/Windows Server 2008 R2 64-bit by now. XP proper is 32-bit only, which is significantly slower in general and even a 3 GiB process isn't enough memory for decent UHD encoding (and even 3 GiB assumes a large address aware build).

Also, Windows wasn't properly NUMA aware until Vista, so modern Windows versions should get at least a 10% speed boost compared to XP on the same hardware multi-socket hardware.

Now, given my backup encoding workstation is a dual-socket 12 core Sandy Bridge with 24 GiB of RAM, I might come off as a little elitist :). But Windows 7 64-bit will definitely encode significantly faster than XP on any hardware build this millennium. And given how memory and CPU hungry x265 and HEVC are, that's going to matter more than ever. x264 may be fast enough that speed doesn't count for a lot of scenarios, but last night I got 0.13 fps encodes on my 16 core Ivy Bridge (granted, high quality UHD 10-bit encoding). Even a 10% speed boost matters! And I bet it's ~20% faster than what stock XP would do running the same hardware.

As you say, there are people on XP 32-bit still and it's good to let them play with HEVC. But we should really be encouraging everyone to upgrade.

[Khanattila]

Compiled builds for Windows XP either, enjoy: https://mega.co.nz/#!fFUm2KZQ!FxMu8xKqzKVG2x7HnV1FyJO0htp-5-bdUp5c_g_jctI

As to the speed, I can tell that using GCC, ICC or Visual Studio there is a slight difference. With a silly encode with preset "medium", crf 20 and everything on default, GCC build run at 9.34 fps, ICC build run at 9.43 and Visual Studio build run at 9.46 on the same video with the same settings.

Anyway, I'll keep supporting xp 'cause there are still a lot of people using that OS.

So, GCC 100.00%, VS 100.96%, ICC, 101.28%.
Below < 2% may be normal fluctuation.

EDIT. In addition, support an operating system dead? I do not understand why.

[jkauff]

I am using SLOW preset on i7-4790K....getting around 2.5fps...which is acceptable for me. :)
I have exactly the same setup, running at 4.7. Using Slow preset and 20 crf (defaults otherwise) on an AVC source gets me into the 3+ fps range, depending on the source material. What crf are you using?

[Ajvar]

Dear MA and x265cc, thank you very much for your benches.

Is there any way to reduce blur at medium preset? Maybe via command line specific options?Changing to slow didn't change anything at first glance and fps was totally unacceptable.

Cheers

Someone wrote this: I tried and found the deblock [-3 and below] and rdoq [+30 and above] affect the deblurring much.

[FranceBB]

@benwaggoner... indeed. I personally do my tests on Windows Server 2008 r2 on an intel i7-5960X and 16 GB of ram, anyway it was just two or three seconds in order to support xp.

Anyway, I really suggest to upgrade to win 8.1 and, of course, to a 64bit version, 'cause with x265 it should be an obligation.

@Khanattila... I see.

[x265.cc]

I wonder what the comparison would look like with --preset slower or veryslow.


x265 Build:

x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp

Hardware:

Intel® Core™ i7-4770 Processor
(8M Cache, up to 3.90 GHz)

Test sample:

http://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

SLOW with AVX2:

x265 --preset slow --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,AVX2,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / 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 : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect rd=4 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp

x265 [info]: frame I: 4, Avg QP:29.68 kb/s: 20795.60
x265 [info]: frame P: 120, Avg QP:33.87 kb/s: 13405.47
x265 [info]: frame B: 380, Avg QP:40.42 kb/s: 443.83
x265 [info]: global : 504, Avg QP:38.77 kb/s: 3691.46
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.2% 3.2% 8.1% 54.8% 30.6%

encoded 504 frames in 47.97s (10.51 fps), 3691.46 kb/s

SLOW without AVX2:

x265 --preset slow --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / 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 : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect rd=4 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp

x265 [info]: frame I: 4, Avg QP:29.68 kb/s: 20795.60
x265 [info]: frame P: 120, Avg QP:33.87 kb/s: 13405.47
x265 [info]: frame B: 380, Avg QP:40.42 kb/s: 443.83
x265 [info]: global : 504, Avg QP:38.77 kb/s: 3691.46
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.2% 3.2% 8.1% 54.8% 30.6%

encoded 504 frames in 54.92s (9.18 fps), 3691.46 kb/s

VERYSLOW with AVX2:

x265 --preset veryslow --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,AVX2,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / 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 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp

x265 [info]: frame I: 4, Avg QP:29.61 kb/s: 21206.10
x265 [info]: frame P: 106, Avg QP:33.62 kb/s: 14368.77
x265 [info]: frame B: 394, Avg QP:40.44 kb/s: 477.05
x265 [info]: global : 504, Avg QP:38.92 kb/s: 3563.24
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.6% 0.0% 7.3% 51.8% 16.4% 10.0% 6.4% 1.8% 2.7%

encoded 504 frames in 268.37s (1.88 fps), 3563.24 kb/s

VERYSLOW without AVX2:

x265 --preset veryslow --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / 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 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp

x265 [info]: frame I: 4, Avg QP:29.61 kb/s: 21206.10
x265 [info]: frame P: 106, Avg QP:33.62 kb/s: 14368.77
x265 [info]: frame B: 394, Avg QP:40.44 kb/s: 477.05
x265 [info]: global : 504, Avg QP:38.92 kb/s: 3563.24
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.6% 0.0% 7.3% 51.8% 16.4% 10.0% 6.4% 1.8% 2.7%

encoded 504 frames in 299.25s (1.68 fps), 3563.24 kb/s

[mandarinka]

I thought it could be interesting comparison, so here is the same source as in the last post also with veryslow, on AMD A8-3850 (4 x 2,9 GHz K10 - no turbo - without SSE4/SSSE3). Done with builds from this post: http://forum.doom9.org/showthread.php?p=1711464#post1711464

N:\>x265 --preset veryslow 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+128-394c2f94a2dc
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / 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 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
x265 [info]: frame I: 4, Avg QP:29.61 kb/s: 21194.10
x265 [info]: frame P: 106, Avg QP:33.61 kb/s: 14371.58
x265 [info]: frame B: 394, Avg QP:40.43 kb/s: 489.85
x265 [info]: global : 504, Avg QP:38.91 kb/s: 3573.74
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.6% 0.0% 8.2% 50.0% 16.4% 11.8% 5.5% 1.8% 2.7%

encoded 504 frames in 2078.31s (0.24 fps), 3573.74 kb/s

I think I'll try with Atom Z3740, maybe.

Edit: okay, this was interesting.

D:\>x265 --preset veryslow 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+128-394c2f94a2dc
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / 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 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
x265 [info]: frame I: 4, Avg QP:29.61 kb/s: 21194.10
x265 [info]: frame P: 106, Avg QP:33.61 kb/s: 14371.58
x265 [info]: frame B: 394, Avg QP:40.43 kb/s: 489.85
x265 [info]: global : 504, Avg QP:38.91 kb/s: 3573.74
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.6% 0.0% 8.2% 50.0% 16.4% 11.8% 5.5% 1.8% 2.7%

encoded 504 frames in 2250.35s (0.22 fps), 3573.74 kb/s


This was run on 32-bit Win8.1 with Asus Transformer T100TA, while the one before was Win8.1 64 though. So actually the Atom might even be same speed if it wasn't hampered by 32bit mode (but remember that this is due to the Llano not having SSE4). I think it ran on full turbo (1.83 GHz) on all cores during the whole test. Base clock is 1.33 GHz and that would prolly not be enough.

[birdie]

I have found a video clip x265 struggles to encode efficiently.

Here it is Megascans_Jungle.mp4 (https://d85clmw03d1co.cloudfront.net/megascans/Megascans_Jungle.mp4) (pretty much lossless considering its bitrate):

Duration: 00:01:22.05, start: 0.000000, bitrate: 53106 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 52812 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)

At CRF 18 (preset=veryslow crf=18, no other options used) I get 22716 kb/s bitrate which is kinda insane.

I'm not a video expert, but CRF 18 for x265 equals approximately CRF 21 for x264 and usually x264 1080p/30fps clips with this quality have a substantially lower bitrate.

[jlpsvk]

where did you get that crf calculation between x264 and x265? I think, that's simply not true. CRF 20 with x265 at SLOW preset look like CRF17-18 with x264 PLACEBO.

[x265_Project]

I have found a video clip x265 struggles to encode efficiently.

Here it is Megascans_Jungle.mp4 (https://d85clmw03d1co.cloudfront.net/megascans/Megascans_Jungle.mp4) (pretty much lossless considering its bitrate):

Duration: 00:01:22.05, start: 0.000000, bitrate: 53106 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 52812 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)

At CRF 18 (preset=veryslow crf=18, no other options used) I get 22716 kb/s bitrate which is kinda insane.

I'm not a video expert, but CRF 18 for x265 equals approximately CRF 21 for x264 and usually x264 1080p/30fps clips with this quality have a substantially lower bitrate.
Thanks for the tip. This is a very interesting source sequence; lots of detail and a fair amount of motion. I'm not surprised that it ends up at 22.7 Mbps with CRF 18. This is a very low CRF setting, producing much higher quality than the default value of --crf 28. As with any encoder, it's easy to produce insane bit rates if you set your quality level high enough. The law of diminishing returns applies to x265. Once you reach a high enough quality level, for each incremental improvement in quality your bit rate will increase substantially (the slope of the rate distortion curve flattens out at high quality levels).

You can either try raising your CRF value, or use 2 pass ABR to target your desired bit rate. You could also use "capped VBR" encoding (CRF with VBV to cap the max bitrate).

[VelleX]

I'm not a video expert, but CRF 18 for x265 equals approximately CRF 21 for x264 and usually x264 1080p/30fps clips with this quality have a substantially lower bitrate.

@ApTeM

With x265 and crf18 i got about 23,1mbps and with x264 and crf22 i got about the same, 22,6mbps.

As x265_Project wrote, this clip has much detail and some motion, so its not comparable to maybe a movie clip or something similar.

I Also tested this 4K Clip, resized to 1080p
https://media.xiph.org/video/derf/y4m/crowd_run_2160p50.y4m

With x265 and crf18 i got about 35mbps because of much motion in this sports clip. Also with crf20 its still above 20mbps.

[Ma]

I decided to compare today updated stable branch (1.5+9) with default branch (1.5+197).

2401 frames with resolution 1920x800, parameters: --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info

16bpp
1.5.0.009 | 977.33s | 2.09fps | 100.0% | stable branch, Win64, -march=corei7-avx
1.5.0.197 | 994.44s | 2.05fps | 101.8% | default branch, Win64, -march=corei7-avx
1.5.0.009 | 1189.8s | 1.72fps | 121.7% | stable branch, Win32
1.5.0.197 | 6748.3s | 0.30fps | 690.5% | default branch, Win32

I've heard that Win32 applications are slower than Win64 and build without assembly is much slower than build with assembly, but the numbers are more convincing.

[Ajvar]

I decided to compare today updated stable branch (1.5+9) with default branch (1.5+197).

2401 frames with resolution 1920x800, parameters: --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info

16bpp
1.5.0.009 | 977.33s | 2.09fps | 100.0% | stable branch, Win64, -march=corei7-avx
1.5.0.197 | 994.44s | 2.05fps | 101.8% | default branch, Win64, -march=corei7-avx
1.5.0.009 | 1189.8s | 1.72fps | 121.7% | stable branch, Win32
1.5.0.197 | 6748.3s | 0.30fps | 690.5% | default branch, Win32

I've heard that Win32 applications are slower than Win64 and build without assembly is much slower than build with assembly, but the numbers are more convincing.

Wow. If this is true and not compiler's problem then you clearly found a bug in 1.5+196 build's behavior on x86 OS which x265 devs should look at. I assume you use Snowfag's builds from http://builds.x265.eu/
Nice job anyways. Thanks.

[LigH]

This is no bug, this is either unavoidable (32 bit code is slower than 64 bit code already due to less and shorter registers) or intentional (no more assembler optimization for 32 bit code and 16 bit depth, because it's just a waste of time: Assembly with less than SSE4 is pointless for 16 bit depth, SSE4+/AVX+ capable CPUs also support 64 bit code, therefore should be used with 64 bit OS).

At least I believe that was the intention of the developers, if I interpreted the initial patch remark correctly.
__

P.S.:

After some compiling issues due to removing assembler optimization from 32 bit code with 16 bit depth, I finished another package today: x265 1.5+200-726fe4088f31 (https://www.mediafire.com/download/z22jj82m45y18na/x265_1.5+200-726fe4088f31.7z)

There is a rather new option --rdoq-level (http://x265.readthedocs.org/en/default/cli.html#cmdoption--rdoq-level) (maybe just recently published to the CLI). It uses more elaborate RD cost calculations in two steps. The second causes less impact of Psy-RDOQ on the final quantization.

The presets (http://x265.readthedocs.org/en/default/presets.html) use value 2 from "slow" on, else 0.

[Ma]

Wow. If this is true and not compiler's problem then you clearly found a bug in 1.5+196 build's behavior on x86 OS which x265 devs should look at. I assume you use Snowfag's builds from http://builds.x265.eu/
Nice job anyways. Thanks.

I use my own builds.

Now in default branch if you want to build Win32 16bpp version you must turn off assembly. I was curious how this affect encoding speed on my system. Of course this is not real comparison because I can encode with Win64 builds. If you can't use Win64 builds your CPU is probably old and can't use all assembly optimizations so the difference should be smaller.

[Motenai Yoda]

There is a rather new option --rdoq-level (http://x265.readthedocs.org/en/default/cli.html#cmdoption--rdoq-level) (maybe just recently published to the CLI). It uses more elaborate RD cost calculations in two steps. The second causes less impact of Psy-RDOQ on the final quantization.

The presets (http://x265.readthedocs.org/en/default/presets.html) use value 2 from "slow" on, else 0.
It's me or now --rdoq-level (or rdoq) 1+ is mandatory to enable psy-rdoq? rather than rd4

If I'm not wrong with --rdoq-level 1 psy-rdoq works as ever (maybe slight better), with --rdoq-level 2 it will be effective only when even the entire 4x4 coding group, and not the single block, need it, discarding so ie flat areas and so extremely less bitrate-hungry than --rdoq-level 1 (a sort of rdoq masking).

But seems enabling rdoq will now slow down more than old one (22/15fps v1.5 vs 14/13fps v1.4) maybe coz now rd3=rd4.

[LigH]

In coming versions, RD levels will be reduced to 0..4 (because 3=4 and 5=6); furthermore, ultrafast and superfast presets will be tweaked.

[stax76]

There is a rather new option --rdoq-level (maybe just recently published to the CLI). It uses more elaborate RD cost calculations in two steps. The second causes less impact of Psy-RDOQ on the final quantization.

The presets use value 2 from "slow" on, else 0.


Thanks for keeping us up to date with options and defaults, very helpful!

[x265_Project]

In coming versions, RD levels will be reduced to 0..4 (because 3=4 and 5=6)
True, but unless you manually set rdlevel (not recommended), this is mainly an internal change.
ultrafast and superfast presets will be tweaked.
The more important commit (https://bitbucket.org/multicoreware/x265/commits/c1a8eef8be143a40981ae6909c6c8c3a6b85901c) to notice is the change in the ultrafast preset. We found that restricting --merange to a value below 57 did not improve speed, but slightly reduced efficiency. We also found that --bframes 3 gave slightly higher performance than --bframes 4. We are now restricting --min-cu-size to 16 in ultrafast. This change will significantly improve encoding speed (~ 28% faster), as x265 doesn't bother to evaluate 8x8 CUs. There is a moderate impact on efficiency (depends on the content, but overall for a set of different 20 clips, this change reduced SSIM from 12.21 dB to 12.01 dB... we got back to 12.10 by changing merange and bframes). So now you'll see a bigger difference in speed between the superfast preset and ultrafast.