lookahead-threads vs quality and

[kotuwa]

x264. What are the impacts of lookahead-threads value regarding the quality?

Is it related to to other things such as VBV, MB-Tree, rc-lookahead.. etc?

I heard that too high number of threads like more than 16 may affect the quality a little bit. right?
Is it same with lookahead-threads?
Or different...
lookahead thread count said to be like threads/6 (or threads/4 as I observed, either it is changed now or depends on other parameters)

Among below 3 examples, which would give the better quality theoretically. Is the difference too insignificant? or not? (Encoding time is irrelevant)

threads 16, lookahead-threads 4
threads 12, lookahead-threads 3
threads 8, lookahead-threads 2
threads 4, lookahead-threads 1
threads 2, lookahead-threads 1
threads 1, lookahead-threads 1

[zerowalker]

Not that into this but i think that any kind of threading is bad for quality cause you can't share the information between the threads or something.
So for highest quality you would do no threads at all.
However that's not realistic, the difference is so small (as long as it's not a ton of threads) and the speed boost is great.

I don't talk from a developers standpoint though, just from some knowhow, which might be wrong;p

[Asmodian]

Too many lookahead threads causes slower performance but not, as I understand it, worse quality. Lookahead happens before encoding so the information from all lookahead threads is available to every encode thread.

Your examples are wrong in that threads 1, lookahead-threads 1 will be the best quality but only because of threads, not lookahead-threads.

When the number of threads starts significantly affecting quality is dependent on the horizontal resolution as well. The over 16 rule of thumb is for 1080p, use less threads for lower resolutions and more for higher.

threads 8, lookahead-threads 2 will be the same quality and size as threads 8, lookahead-threads 1.

[Groucho2004]

Here is a good thread on the topic. I agree with Asmodian on the influence of lookahead threads on quality - it should be nil or at least negligible.

[F J Walter]

x264 does frame-based multithreading where a certain number of threads are used for the encode, and then there is a thread (or threads) for lookahead. Because lookahead uses such a small portion of CPU time compared to the encode you only need roughly 1/6 as many lookahead threads as encode threads.

The fact that multiple lookahead threads are enabled by default (when using a certain number of threads) is a good indication that there is no noticeable quality loss. MBtree is done in lookahead, and so that quality may be affected in the same way that motion estimation quality can be affected by multithreading in the encode, but the effect will be negligible enough to ignore - even more so than it is in the encode.

It's wrong to say there is *no* difference at all, just that the difference is ignorable. I just did a test myself: compared 1 vs 2 lookahead threads (both times with 6 encode threads) and the resulting file *is* different.

[kotuwa]

Thanks for the Replies