x265 HEVC Encoder

[LigH]

The announced "big fat AVX2 patch collection" is now included in x265 1.5+128-394c2f94a2dc

[shinchiro]

Originally Posted by LigH

The announced "big fat AVX2 patch collection" is now included in x265 1.5+128-394c2f94a2dc

How much fps gained now when encoding on haswell 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:

Originally Posted by Steve Borho

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/...e68ae4534330a0

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]

Originally Posted by sneaker_ger

Script:
[code]
Or you can use a tool like ffmpeg if you don't need any AviSynth processing (no script file needed):

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.

Originally Posted by LigH

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

Originally Posted by Fantasy

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.

Originally Posted by Fantasy

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]

Originally Posted by 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.

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]

Originally Posted by 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.

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)

Originally Posted by 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)

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

Originally Posted by 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]

Originally Posted by x265_Project

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?