x264's 1st pass always <100% CPU Usage (& --b-adapt 1 crash)

[akupenguin]

Sure, its quite possible, but would require a thousand-or-two line patch to move the lookahead ahead of the main encoding thread, add all necessary mutexes and synchronization primitives, and buffer all necessary frames.
That's moving B-adapt to a separate thread from the i/o loop, which is independent of whether to multithread it. Simple multithread doesn't need any mutexes, only `make`-style dependencies.

[kemuri-_9]

avs2yuv: ~120MB
x264 before dumprep: ~1.2GB
x264 after dumprep: ~1.7GB

definitely far from the limits, so i'm out of explanations...
except the classic one... M$ failure...
use linux and see how well it goes. (lol)

[Snowknight26]

Sorry, that's not a realistic suggestion for me so I can't.

[Dark Shikari]

That's moving B-adapt to a separate thread from the i/o loop, which is independent of whether to multithread it. Simple multithread doesn't need any mutexes, only `make`-style dependencies.Wait, isn't that what he asked for though?

Multithreading the lookahead means moving it to a separate thread from the I/O loop.

[akupenguin]

notation: each line is 1 thread, "->" is a dependency, "..." is a thread that remains running while x264_encoder_encode() returns

currently:
frame in -> lookahead loop -> spawn thread for encode ...
... encode another frame ................................
... encode another frame -> sync oldest thread -> out

option 1:
This devotes 1 whole core to lookahead, but if you have 4 cores and run B-adapt=2 on a fast 1st pass, it'll still bottleneck.
frame in -> lookahead loop .......................................
older frame -> sync older lookahead -> spawn thread for encode ...
... encode another frame .........................................
... encode another frame -> sync oldest thread -> out

option 2:
This allows multiple cores for lookahead, but leaves it in the loop, so the distribution of parallelism over time is uneven.
/-> lookahead -\
frame in -> lookahead --> spawn thread for encode ...
\-> lookahead -/
... encode another frame ............................
... encode another frame -> sync oldest thread -> out

option both:
/-> lookahead ............................................
frame in -> lookahead ............................................
\-> lookahead ............................................
older frame -> sync older lookahead -> spawn thread for encode ...
... encode another frame .........................................
... encode another frame -> sync oldest thread -> out

[Dark Shikari]

Oh, you just mean multithreading within the lookahead.

That wouldn't be too bad as long as you make sure none of the stuff you run concurrently depends on the same MVs/etc.

[Sagekilla]

There any possibility of getting a threaded b-adapt sooner than later then? :)