Bad x264 rc_lookahead value

[rubdub]

Hello,
when I set up Hybrid x264 options and disable mbtree, rc-lookahead gets greyed-out. The underlying x264 command then uses rc_lookahead=0. This is catastrophic: x264 ratecontrol code becomes unable to anticipate the complexity of the next N frames ahead of the current one. ratecontrol becomes strictly reactive to the current frame encoding complexity. The outcome is just low quality encodes or overshoot of VBV.

mbtree uses rc_lookahead value, but disabling mbtree does not mean rc_lookahead is not needed in x264. It would be nice to not default the value and let the user choose it freely (without capping at framerate/2 occasionally?)

[Selur]

As far as I remember:
a. rc-lookahead (mbtree/vbv-lookahead) is only used in x264 when mbtree is enabled.
b. with '--no-mbtree', Hybrid will not add '--rc-lookahead' to the command line. So Hybrid should never set '--rc-lookahead 0'.
c. rc-lookahead is restricted by min(--keyint,250) or min(--keyint/2, 250). (not sure atm.)
If you are sure one or all of these statements are false, please share the links to where this is in the x264 source code, since I'm pretty sure I checked this when I implemented it in Hybrid.

I think, what happens is, that you disabled mbtree. x264 doesn't use rc-lookahead and thus sets it to 0 in the SEI data (this is what MediaInfo looks at to report the 'Encoding setting').
I'm pretty sure this i not a bug in Hybrid, but a correct mirror of how x264 behaves.

Setting rc-lookahead = 0 in x264 does not entirely disable rate control. Instead, it disables the lookahead process for rate control decisions, meaning the encoder will not analyze future frames to optimize bitrate allocation. However, other rate control mechanisms (e.g., CRF, ABR, or CBR) remain active unless explicitly disabled or overridden by other parameters like constant quantizer mode (--qp) or specific configurations (like qcomp = 0 which basically is --cq).

----
upper limit 250: https://github.com/PlatformLab/x264/blob...ase.h#L128
for the rest, see: https://code.videolan.org/videolan/x264/...eads#L1108
this was also discussed over at doom9s a few years ago.


Cu Selur

[rubdub]

I read x264 code and I insist, rc_lookahead value is relevant regardless of mbtree status. In your second link (encoder.c L1108+), there is nothing that overrides lookahead value to zero if mbtree is disabled.

To have more evidence, please search for "i_lookahead" in ratecontrol.c and pay attention to the logic flow. If i_lookahead is zero, then all size prediction of future frame is skipped and it fallbacks to reactive logic at line 2330+ (mere example, there are others "bad" fix-ups for this insane case of no lookahead). You can add debug print there to verify this that lookahead is used properly regardless of mbtree status.

Furthermore, if you look at many commercial blu-rays, SEI data always have rc_lookahead > 0, regardless of mbtree. Example: https://forum.blu-ray.com/showpost.php?p...tcount=377

[humanoid86]

IMHO

due to the many encodings, I realized one thing: this lookahead is useless - anyway, the quality of the content depends on saving and storing and transmitting, and this lookahead is useful when processing GPU-264

[rubdub]

Your comment makes no sense. People have used VBV, zones & co. for years with proper lookahead and produced plenty of Blu-ray Discs with extremely variable bitrate adapted to each scene. VBV compliance defines transmitting, as you even pointed out!!

I think you are biased by this situation: without mbtree, rc_lookahead values exceeding fps * MAX(1.0, (vbv_bufsize / vbv_maxrate)) have no effect.  This comes from the MPEG standards: data that flows in and out of the VBV can only reside there for one second at most (unless vbv ratio is > 1). In other words, current data cannot be affected by data > 1 sec in the future. Value from ]fps ; 250] have little to no impact.

With mbtree, propagation of MB metrics to the current frame can be affected by the lookahead distance, regardless of the value. Without mbtree, any values > fps does not lead to a measurable change.

[Selur]

Since I'm totally groggy today, I did the lazy approach, I called x264 with "--no-mbtree --rc-lookahead 250":

ffmpeg -y -loglevel fatal -i "G:\TestClips&Co\files\test.avi" -pix_fmt yuv420p -fps_mode passthrough -f rawvideo - | x264 --crf 18.00 --no-mbtree --rc-lookahead 250 --demuxer raw --input-res 640x352 --input-csp i420 --input-range tv --input-depth 8 --fps 25/1 --output-depth 8 --output "g:\Output\nomb_rv250.264" -

with a current x264 version.
and then called MediaInfo:

mediainfo "g:\Output\nomb_rv250.264"
General
Complete name                            : g:\Output\nomb_rv250.264
Format                                   : AVC
Format/Info                              : Advanced Video Codec
File size                                : 1.97 MiB
Duration                                 : 17 s 120 ms
Overall bit rate                         : 966 kb/s
Frame rate                               : 25.000 FPS
Writing library                          : x264 core 164 r3204 373697b
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=11 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

Video
...

=> Like I expected, rc-lookahead isn't used. Only if mbtree is used, rb_lookahead is written into the settings.
(iirc. a few years ago x264 version still did write the rc_lookahead info, even when rc_lookahead was not used.)

Cu Selur

[humanoid86]

By the way

won't this Lookahead mode help your RIFE when changing scenes?

[rubdub]

It IS used with nal-hrd vbr/cbr (= VBV):

x264 --vbv-maxrate 40000 --vbv-bufsize 30000 --no-mbtree --rc-lookahead 250 --crf 18 --fps 25/1 --demuxer y4m -o out2.264 input.y4m

=>
options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=250 rc=crf mbtree=0 crf=18.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=40000 vbv_bufsize=30000 crf_max=0.0 nal_hrd=none filler=0 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00

In your command line, you did not specify VBV: there's no bitrate target or constaint so x264 has no ratecontrol activated at all. CRF alone is consistent quality across the video, it is unbounded in term of bitrate. If you additionally specify nal-hrd CBR or VBR, you must specify VBV and then lookahead won't be discarded anymore. In this situation precisely zero must be avoided at all cost!

[Selur]

nal-hrd and vbv are different things.
=> will do some testing later.

[Selur]

The only case Hybrid would set the rc-lookahead to 0 is if keyint=1.
I uploaded a new dev version, which should always set the rc-lookahead unless cq is used.
Note that it might be removed from the command line if it's covered by the defaults.
i.e. with

x264 --crf 18.00 --profile high --level 5.1 --direct auto --b-adapt 0 --sync-lookahead 48 --qcomp 0.50 --qpmax 51 --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 5 --trellis 0 --weightp 1 --aq-mode 0 --vbv-maxrate 300000 --vbv-bufsize 300000 --sar 1:1 --qpfile GENERATED_QP_FILE --non-deterministic --range tv --colormatrix smpte170m --demuxer raw --input-res 640x352 --input-csp i420 --input-range tv --input-depth 8 --fps 25/1 --output-depth 8 --output "J:\tmp\test.264" -

rc-lookahead is not removed from the command line call since it's set to 40 which is the default for preset medium.

Cu Selur