Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
28th October 2011, 00:21 | #1 | Link |
Registered User
Join Date: Oct 2011
Posts: 13
|
rc- lookahead values
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! |
28th October 2011, 00:43 | #2 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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!)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 28th October 2011 at 01:23. |
28th October 2011, 01:34 | #3 | Link | |
Registered User
Join Date: Oct 2011
Posts: 13
|
Quote:
|
|
28th October 2011, 01:44 | #4 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 28th October 2011 at 02:02. |
28th October 2011, 07:38 | #6 | Link |
Registered User
Join Date: Oct 2011
Posts: 13
|
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. |
31st October 2011, 05:33 | #8 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
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.
|
31st October 2011, 13:03 | #9 | Link |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
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
__________________
[I'm human, no debug]
|
31st October 2011, 18:51 | #11 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
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. Last edited by cyberbeing; 31st October 2011 at 19:10. |
31st October 2011, 22:26 | #12 | Link | ||
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Quote:
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. Quote:
__________________
[I'm human, no debug]
|
||
31st October 2011, 22:51 | #13 | Link |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
@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.) |
15th June 2015, 06:50 | #14 | Link |
Registered User
Join Date: May 2012
Posts: 66
|
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 |
2nd July 2015, 03:05 | #15 | Link | |||
Registered User
Join Date: Oct 2007
Posts: 47
|
I don't think the situation has really changed.
Quote:
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. Quote:
Quote:
Last edited by F J Walter; 2nd July 2015 at 03:12. |
|||
|
|