[akupenguin]

Originally Posted by mogobime

So is it correct if I say this is like a frame-buffer for vbv-lookahead/mbtree ratecontrol?

Yes.

An example: I like to raise --lookahead-threads from 2 to 3 when working with --threads=12 and rc-lookahead=60.

Is that still necessary after r2260 (2013-02-25) updated the default lookahead-threads?

Sometimes I also use opencl lookahead already.
So in this case could it be useful to raise sync-lookahead to prevent this buffer getting emptied to early?

The only factors that should affect the maximum useful value of sync-lookahead are things that change the amount of variance in how much time it takes to encode and/or lookahead one frame vs another frame. You don't need to prevent the buffer from emptying early if it does so consistently: bad-performance-preventable-by-sync-lookahead only happens if it oscillates between empty and full.

The relevant options include bframes (which are already accounted for in the default sync-lookahead); but don't include lookahead-threads, because lookahead-threads only affects the absolute speed of lookahead and not the variance. I don't know whether it includes opencl, and even if it does, I don't know whether opencl increases or decreases the required sync-lookahead.

Otoh, if you have memory to spare and aren't in a latency-sensitive usecase, then there isn't really any cost to overestimating sync-lookahead. Otth, I think the default value is already a conservatively high estimate, so you probably don't need to further increase it even if you twiddle some related options.