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. |
|
|
Thread Tools | Search this Thread | Display Modes |
12th July 2009, 16:16 | #1981 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Code:
$ ./x264 -o NUL test.y4m --frames 1000 -b16 yuv4mpeg: 640x480@30/1fps, 0:0 x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT x264 [info]: profile High, level 3.0 x264 [info]: slice I:6 Avg QP:13.84 size: 9284 x264 [info]: slice P:570 Avg QP:21.80 size: 7107 x264 [info]: slice B:424 Avg QP:24.58 size: 1312 x264 [info]: consecutive B-frames: 37.5% 22.5% 4.5% 7.6% 15.6% 11.5% 0.7% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% encoded 1000 frames, 92.89 fps, 1119.34 kb/s ~92% CPU across 4 cores $ ./x264 -o NUL test.y4m --frames 1000 -b5 --b-adapt 2 x264 [info]: slice I:6 Avg QP:13.97 size: 8909 x264 [info]: slice P:507 Avg QP:21.69 size: 6518 x264 [info]: slice B:487 Avg QP:24.01 size: 1869 x264 [info]: consecutive B-frames: 22.2% 23.3% 47.4% 1.2% 1.0% 4.8% encoded 1000 frames, 54.47 fps, 1024.58 kb/s ~70% CPU across 4 cores $ ./x264 -o NUL test.y4m --frames 1000 -b16 --b-adapt 2 x264 [info]: slice I:6 Avg QP:13.97 size: 8906 x264 [info]: slice P:500 Avg QP:21.71 size: 6543 x264 [info]: slice B:494 Avg QP:23.96 size: 1853 x264 [info]: consecutive B-frames: 21.6% 23.3% 47.1% 1.2% 1.0% 1.8% 2.1% 0.8% 0.0% 1.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% encoded 1000 frames, 13.72 fps, 1017.91 kb/s ~37% CPU across 4 cores 5 being noticeable on default settings... with 16 nearly destroying all threading speedup... |
14th July 2009, 06:09 | #1983 | Link |
|ン、)
Join Date: Feb 2008
Posts: 77
|
Dead video card is still dead. Using an old 1MB ATI All-in-Wonder PCI card for the time being. 1024x768 VGA mode is great.
Anyway... x264-r1181M-imk-win.7z win_build_info.txt |
14th July 2009, 08:55 | #1984 | Link | |
Registered User
Join Date: Feb 2006
Posts: 1,076
|
Quote:
|
|
14th July 2009, 09:03 | #1985 | Link | |
Registered User
Join Date: Feb 2003
Posts: 448
|
Quote:
|
|
14th July 2009, 09:19 | #1986 | Link |
Suptitle, MediaPlayer.NET
Join Date: Nov 2001
Posts: 1,721
|
Is the threaded slicetype patch stable enough to be included yet? specifically v15: http://mailman.videolan.org/pipermai...ly/005988.html
Thanks. |
14th July 2009, 09:21 | #1987 | Link |
Registered User
Join Date: Oct 2004
Location: France
Posts: 567
|
There is a v16 : http://mailman.videolan.org/pipermai...ly/006022.html ...
|
14th July 2009, 09:28 | #1988 | Link |
Suptitle, MediaPlayer.NET
Join Date: Nov 2001
Posts: 1,721
|
@imk
Would greatly appreciate it if you could include x264-r1179-threaded-slicetype-v16-fix.diff found here - http://kemuri9.net/dev/x264/patches/ |
14th July 2009, 09:56 | #1989 | Link | |
Registered User
Join Date: Feb 2006
Posts: 1,076
|
Quote:
|
|
14th July 2009, 18:53 | #1990 | Link | |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Quote:
other things that need fixing are non-critical... 1. removing changes to osdep.h 2. possibly removing/altering the section that sets the lookahead thread's priority (as it breaks BeOS compilation and from discussion from pengvado, negative values for priority should only work on linux and as root) not to mention it's not official yet as i'm not the patch maintainer... He's been busy with his job and hasn't yet come back to irc discuss the slight change i made from v16 but I've been using the patch as it's progressed along and have had no issues using it. Last edited by kemuri-_9; 14th July 2009 at 19:00. |
|
15th July 2009, 01:45 | #1991 | Link |
Suptitle, MediaPlayer.NET
Join Date: Nov 2001
Posts: 1,721
|
Hmm. I gave kemuri-9's build a spin but didn't notice any difference at all using --rc-lookahead auto vs without. I would've thought that patch is to enable x264 to utilize multicores in first pass more effectively when --b-adapt 2 is used? With or without --rc-lookahead, my dual core 2.13GHz CPU stays at around 75%.
|
15th July 2009, 01:50 | #1992 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Yes, I'm not sure what's up with that; it seems to give far less benefit than I expected.
Either: 1. There is some major inefficiency in the patch (quite possible). 2. B-adapt 2 needs internal multithreading (I'll do this once threaded slicetype is committed). |
15th July 2009, 05:24 | #1993 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Code:
$ ./x264-o NUL test.y4m --frames 1000 -b5 --b-adapt 2 --rc-lookahead auto encoded 1000 frames, 57.30 fps, 1024.59 kb/s $ ./x264 -o NUL test.y4m --frames 1000 -b16 --b-adapt 2 --rc-lookahead auto encoded 1000 frames, 14.18 fps, 1017.92 kb/s 5 bframes: 54.47 fps -> 57.30 fps 16 bframes: 13.72 fps -> 14.18 fps the speedup is there, it's just not very much from the level of how much b-adapt 2 can destroy threading performance currently. my builds are also set to "-march=AMD", since that's what all 4 of my pcs+laptop are. so if you're on an intel chip, you probably will get slightly lower speeds with my build compared to everyone else's "-march=intel" builds yes, this is very much needed from what I've seen. |
15th July 2009, 07:48 | #1994 | Link |
Registered User
Join Date: Aug 2008
Location: Minsk, Belarus
Posts: 235
|
threaded-slicetype speed result for Intel core i7 with settings "--preset placebo --tune touhou"
lookahead=0: 8.42 fps lookahead=30: 8.95 fps lookahead=60: 9.20 fps lookahead=90: 9.26 fps lookahead=120: 9.15 fps lookahead=150: 9.19 fps lookahead=180: 9.28 fps lookahead=210: 9.10 fps lookahead=240: 9.22 fps Edit -> kemuri-_9, sure this is my inattention Last edited by komisar; 15th July 2009 at 18:40. |
15th July 2009, 16:43 | #1995 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
that seems incorrect, auto sets the value to (bframes + threads) * 2
placebo has 16 bframes, so even without the thread value the automatic lookahead size is already > 30. iirc, the i7 has 4 real and 4 ht cores, so auto threads should set it to 12, so (12 + 16) * 2 = 56 is what lookahead auto should be setting the lookahead size to. |
16th July 2009, 09:12 | #1996 | Link |
Suptitle, MediaPlayer.NET
Join Date: Nov 2001
Posts: 1,721
|
An idea for a patch:
The Intel TBB (Threading Building Blocks) Allocator patch, using cache_aligned_allocator etc instead of x264_malloc. From my own experience using it in other projects, the tbb allocator is about 15% faster than HeapAlloc (called by malloc) and even faster when there's 2 or more threads are allocating / freeing at the same time, especially across different cores. This should be fairly straight forward considering x264_malloc() / x264_free() already centralizes all allocations / free ops. If I have some time to setup the build environment with all the tools to merge diffs and stuff, I'd probably make one myself using MSVC2005. |
16th July 2009, 09:19 | #1997 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
|
|
16th July 2009, 17:36 | #2000 | Link |
Registered User
Join Date: Mar 2008
Posts: 30
|
If we're free to post ideas here, I tried working on it but don't really have the experience to get it done. An option --encoder-fps would tune your options every so many frames to try to match fps to --encoder-fps value. Bframes would be lowered or raised, refs decreased or increased, etc. It would be very useful if performing faster than a certain speed is crucial. The only issues I'd foresee is that certain options (like bframes) probably can't be changed very easily in the middle of encoding.
|
Tags |
h.264, x264, x264 builds, x264 patches, x264 unofficial builds |
Thread Tools | Search this Thread |
Display Modes | |
|
|