Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
27th February 2015, 15:43 | #1801 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
The announced "big fat AVX2 patch collection" is now included in x265 1.5+128-394c2f94a2dc
|
27th February 2015, 16:44 | #1802 | Link | |
Registered User
Join Date: Feb 2012
Posts: 46
|
Quote:
|
|
27th February 2015, 21:49 | #1803 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
Depends on material, preset, resolution ... an absolute number of fps would be the least intelligent unit to measure.
From the mailing list announcement: Quote:
|
|
27th February 2015, 23:15 | #1804 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
Speed gain of 1.5+128 vs. 1.5+27 (16bpp)
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). |
28th February 2015, 17:47 | #1805 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
Where 2.2% of speed was lost (16bpp)
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. |
28th February 2015, 20:34 | #1806 | Link |
Registered User
Join Date: Mar 2004
Posts: 7
|
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. |
1st March 2015, 14:42 | #1807 | Link | ||
Registered User
Join Date: Jan 2015
Posts: 14
|
Quote:
Quote:
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. Last edited by Fantasy; 1st March 2015 at 14:58. |
||
1st March 2015, 15:00 | #1808 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
Correct. |
|
3rd March 2015, 01:35 | #1809 | Link |
Registered User
Join Date: Jul 2014
Posts: 115
|
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. |
3rd March 2015, 08:55 | #1811 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
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.
|
3rd March 2015, 18:22 | #1812 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
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. |
|
3rd March 2015, 18:29 | #1813 | Link |
Registered User
Join Date: Jul 2014
Posts: 115
|
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? Last edited by Ajvar; 3rd March 2015 at 18:44. |
4th March 2015, 21:05 | #1816 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
1.5+141 16bpp crashes
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: Code:
---[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) |
4th March 2015, 21:24 | #1817 | Link | |
Guest
Posts: n/a
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|