rc- lookahead values

[pilgrim365]

Hi I'm using MeGUI 2050 and after about a month of reading guides and trial and error I've finally nailed and understood (to a reasonable degree) what all of the various settings relate to and what values are appropriate. However there is just one that I'm failing to grasp completely.

The rc- lookahead value is set at default to 40. I've been encoding at 100 as it states that higher values improve quality. However I have noticed that many people do not tend to go above 60. Is there no real benefit to using such high values? Why isn't everyone using 250? Do it work better on different types of content, I can't really seem to find a definitive conclusion on this.

Any responses would be greatly appreciated, cheers!

[LoRd_MuldeR]

The fact alone that even the "placebo" preset of x264 doesn't go above 60 is a good indication that you probably don't want to go any higher

Also: Why isn't everybody cranking up every setting to the absolute maximum? Well, first of all, not all settings fall into the "more is better" category (the Psy settings are a good example!). Moreover, even for those "speed -vs- quality" settings, there is a point where using an even higher (slower) value only gives a very minor additional improvement, if at all, for a significant additional speed cost...

(Last but not least, in the case of "rc-lookahaead", the memory consumption increases a lot when cranking up the value. So you may easily run into "out of memory" problems with unusual high values!)

[pilgrim365]

Originally Posted by LoRd_MuldeR

The fact alone that even the "placebo" preset of x264 doesn't go above 60 is a good indication that you probably don't want to go any higher

True yeah, I didn't think to compare it to that. I have encoded with this value as high as 175 and i've not yet experienced a memory problem.

[LoRd_MuldeR]

With an RC-Lookahead of 175 (and otherwise "very slow" preset) I get a memory consumption of ~4 GB for 1920x1080 footage.

That's quite a lot for a single encode. And with a 32-Bit build it certainly would fail...

More important: Did you ever compare RC-Lookahead 60 -vs- 175 with, apart from that, identical settings (and of course identical output file size)?

I'm pretty sure you won't be able to spot a difference...

[gyth]

http://x264dev.multimedia.cx/archives/98

[pilgrim365]

I've just tested it. One with a setting of 60 and the other 140. The results were, as far as I can tell pretty much identical. The encode still took virtually the same amount of time and the file sizes were within 1mb of one another.

RAM comsumption was higher but otherwise I wouldn't have been able to tell the difference.

So I guess sticking to lower values is fine unless dealing with anime.

[nm]

Originally Posted by pilgrim365

So I guess sticking to lower values is fine unless dealing with anime.

--tune animation doesn't increase rc-lookahead, which implies that higher values aren't needed with that content either.

[cyberbeing]

The main concern with rc-lookahead is just ram usage. One of the reasons 60 was used for placebo and none of the tune settings raise it, was so it was actually usable (i.e. little chance of it crashing x86 on 1080p with out-of-memory errors). Larger values can be helpful in stabilizing quality, but it's very situational.

[JEEB]

Originally Posted by cyberbeing

The main concern with rc-lookahead is just ram usage.

And then there's the issue of larger rc-lookahead leading to movement being parsed as very fast movement with sources that generally have a small amount of movement in scenes, such as anime.

That is also one reason to why rc-lookahead in presets doesn't go any higher than it does

[akupenguin]

Originally Posted by JEEB

And then there's the issue of larger rc-lookahead leading to movement being parsed as very fast movement

What? Slow movement for N frames is treated the same regardless of whether you allow MBtree to analyze more frames after that.

[cyberbeing]

All I know is MBTree, RC-Lookahead, and the WeightP stuff are things I was bugging Dark Shikari to implement a few years back because I was having rate control issues with difficult anime sources. At that time, the only other option was the laughably slow brute-force RDO patch. As far as I know, the usefulness of larger rc-lookahead values depends on the distance between keyframes and scene complexity which x264 has trouble predicting. This means that detailed anime with very long panning-scenes/scene-changes (especially with kenint values higher than 250) and/or extremely grainy sources I would expect to benefit the most from higher values. I believe Dark Shikari did tests back then which found that a lookahead value 1/4 to 1/2 the distance between keyframes was good enough to get the majority of the benefit on your average source without excessive RAM use.

I've never heard of there being a downside of larger values if you have plenty of RAM running x264 x64, but unless you are trying to solve a rate control quality problem or can actually see a difference, just stick with presets.

[JEEB]

Originally Posted by akupenguin

What? Slow movement for N frames is treated the same regardless of whether you allow MBtree to analyze more frames after that.

Hmm, this means I either misunderstood something or my head is full of holes (and/or that I fail at writing my thoughts properly).

All I can remember is that Dark_Shikari was at one point saying that setting rc-lookahead to large values can actually hurt quality.

Edit: No, it doesn't seem like my head is completely full of holes, although I have no idea if this stuff is still valid. VFR MBtree, that was mentioned, at least is already in.

Originally Posted by IRC

00:13 < Dark_Shikari> we need vfr mbtree first, for anime
00:13 < Dark_Shikari> or at least time-limited mbtree
00:13 < Dark_Shikari> in the meantime just stop using rc-lookahead 250
00:20 < Mandarinka> "[23:13] <Dark_Shikari> in the meantime just stop using rc-lookahead 250" --- wait, it actually hurts? As in, the bias effect gets too strong?
00:21 < Dark_Shikari> yes, on completely static scenes, probably so
00:21 < Dark_Shikari> my plan is to implement an internal cap to how long an object can "stick around" as seen by x264

[akupenguin]

@JEEB
That's MBtree correctly measuring very large amounts of information propagation (i.e. very low motion), and going wrong (i.e. too strong) in the step where it converts that to a QP offset.

@cyberbeing
Grain should reduce the effectiveness of (the current implementation of) MBtree. Even if there is a long duration object that can be reused in lots of frames, and even if the grain only corrupts the same HF coefs every time and thus doesn't interfere with the LF components of the object, MBtree only looks at total SATD residual for a block and assumes that the inferred fraction of information propagation applies equally to all coefs. Thus the estimate of propagation will experience exponential decay as a function of temporal distance. (And if those convenient assumptions don't hold, then grain should reduce the effectiveness of any possible implementation of MBtree, not just ours.)

[kotuwa]

Just looking for an update...
Updated info for 2015

Does using --rc-lookahead 250 could affect negatively?... In anime or ay other media!
(Ram usage is not a problem)

I did a small samaple, using 60 and 250.
There the outputs are different, but can not tell which one has better quality...
come areas look better in 60, and some areas look better in 250, some areas, different but can not tell which is better...
So, for me in that sample, since both are same overall, 60 would be okay...
but could be different in other videos, and could be different for other people

[F J Walter]

Originally Posted by kotuwa

Just looking for an update...
Updated info for 2015

I don't think the situation has really changed.

Does using --rc-lookahead 250 could affect negatively?... In anime or ay other media!
(Ram usage is not a problem)

Not really, except that more lookahead allows MBtree ratecontrol to do its job better, so as long as MBtree is doing well (ie, its job is making a positive difference), more lookahead will help that, but in cases where MBtree is mislead into making a bad decision, more lookahead will enhance that.

That said, diminishing returns set in very quickly, and beyond around 20 to 40 you don't get much more improvement by increasing it further. Beyond 60 it's probably placebo territory. Won't harm anything, but you're almost certainly not going to see a benefit. That said, it's not going to harm output in any normal situation notwithstanding what has already been said above.

I did a small samaple, using 60 and 250.
There the outputs are different, but can not tell which one has better quality...

That illustrates what I mean about not seeing a benefit beyond 60. You'll be able to tell it's different, I guess, if you look at specific blocks in specific frames, just due to random variation. But you won't be able to whether it constitutes an overall improvement in RC or not.

So, for me in that sample, since both are same overall, 60 would be okay...
but could be different in other videos, and could be different for other people

The "placebo" preset uses 60. That should tell you all you need to know. Even the x264 developers think increasing it beyond that is useless.