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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 12th July 2009, 16:16   #1981  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
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
b-adapt 2 reduces threading improvement as you increase the number of bframes:
5 being noticeable on default settings...
with 16 nearly destroying all threading speedup...
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 12th July 2009, 19:46   #1982  |  Link
Fr4nz
Registered User
 
Join Date: Feb 2003
Posts: 448
Quote:
Originally Posted by kemuri-_9 View Post
b-adapt 2 reduces threading improvement as you increase the number of bframes:
5 being noticeable on default settings...
with 16 nearly destroying all threading speedup...
I see, thank you for the clarification! I didn't know that b-adapt is computationally so "heavy"...
Fr4nz is offline   Reply With Quote
Old 14th July 2009, 06:09   #1983  |  Link
imk
|ン、)
 
imk's Avatar
 
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
imk is offline   Reply With Quote
Old 14th July 2009, 08:55   #1984  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Quote:
Originally Posted by imk View Post
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
Thx for taking the time to build this, despite of the troubles !
G_M_C is offline   Reply With Quote
Old 14th July 2009, 09:03   #1985  |  Link
Fr4nz
Registered User
 
Join Date: Feb 2003
Posts: 448
Quote:
Originally Posted by imk View Post
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
Thank you!
Fr4nz is offline   Reply With Quote
Old 14th July 2009, 09:19   #1986  |  Link
Zachs
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.
Zachs is offline   Reply With Quote
Old 14th July 2009, 09:21   #1987  |  Link
Underground78
Registered User
 
Underground78's Avatar
 
Join Date: Oct 2004
Location: France
Posts: 567
There is a v16 : http://mailman.videolan.org/pipermai...ly/006022.html ...
Underground78 is offline   Reply With Quote
Old 14th July 2009, 09:28   #1988  |  Link
Zachs
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/
Zachs is offline   Reply With Quote
Old 14th July 2009, 09:56   #1989  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Quote:
Originally Posted by Zachs View Post
@imk

Would greatly appreciate it if you could include x264-r1179-threaded-slicetype-v16-fix.diff

found here - http://kemuri9.net/dev/x264/patches/
Hmmm, i'd prefer only using patches that are known to be stable. Hopefully DS will be able to review this patch
G_M_C is offline   Reply With Quote
Old 14th July 2009, 18:53   #1990  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by G_M_C View Post
Hmmm, i'd prefer only using patches that are known to be stable. Hopefully DS will be able to review this patch
DS has reviewed the v16 patch, and the -fix i made is the result to fix the crash he found...
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.
__________________
custom x264 builds & patches | F@H | My Specs

Last edited by kemuri-_9; 14th July 2009 at 19:00.
kemuri-_9 is offline   Reply With Quote
Old 15th July 2009, 01:45   #1991  |  Link
Zachs
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%.
Zachs is offline   Reply With Quote
Old 15th July 2009, 01:50   #1992  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
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).
Dark Shikari is offline   Reply With Quote
Old 15th July 2009, 05:24   #1993  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
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
the difference from no lookahead to automatic on this quadcore is:
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

Quote:
Originally Posted by Dark Shikari View Post
2. B-adapt 2 needs internal multithreading (I'll do this once threaded slicetype is committed).
yes, this is very much needed from what I've seen.
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 15th July 2009, 07:48   #1994  |  Link
komisar
Registered User
 
komisar's Avatar
 
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
__________________
..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::..

Last edited by komisar; 15th July 2009 at 18:40.
komisar is offline   Reply With Quote
Old 15th July 2009, 16:43   #1995  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by komisar View Post
lookahead=30: 8.95 fps (default for "auto")
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.
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 16th July 2009, 09:12   #1996  |  Link
Zachs
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.
Zachs is offline   Reply With Quote
Old 16th July 2009, 09:19   #1997  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by Zachs View Post
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.
x264 allocates all memory at initialization. The time spent in malloc and free isn't even measurable.
Dark Shikari is offline   Reply With Quote
Old 16th July 2009, 09:24   #1998  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
Yeah that's true. Even the frames in frame.c are recycled...

Would TBB help in anyway though? Like parallel loops and stuff?
Zachs is offline   Reply With Quote
Old 16th July 2009, 09:37   #1999  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by Zachs View Post
Yeah that's true. Even the frames in frame.c are recycled...

Would TBB help in anyway though? Like parallel loops and stuff?
x264 is already heavily threaded. There are no individual loops that run long enough without inter-iteration dependencies to make threading worth it.
Dark Shikari is offline   Reply With Quote
Old 16th July 2009, 17:36   #2000  |  Link
ACoolie
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.
ACoolie is offline   Reply With Quote
Reply

Tags
h.264, x264, x264 builds, x264 patches, x264 unofficial builds

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:10.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.