Quote:
Originally Posted by mogobime
So is it correct if I say this is like a frame-buffer for vbv-lookahead/mbtree ratecontrol?
|
Yes.
Quote:
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?
Quote:
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.