Abnormal bitrate and quality drop

[mp3dom]

Using x264 on blurays (high bitrates and vbv)

Under certain unknown circumstances, there are significant bitrates and very visible quality drop on scene changes. Generally, it appears more often when the previous scene is quite complex with some particles effects (snow falling, fire crackles, and so on...). The bitrate drop is very pronunced, it can be even 5x lower than expected.
The problem propagates for no more than a gop (on bluray it translates to 1 second), infact, the *same* scene, after that second, "regain" its bitrate and continue with good quality. I'm not even able to fix it with the use of zones, because with zones I can fix that scene a bit (albeit x264 totally ignore my bitrate multiplier but still it raise the bitrate in a decent way) but the problem is then "shifted", and just after the zone ends, the same bitrate drop appear.

This is an example:

http://images2.imagebam.com/54/24/dc/17b501947562564.png

As you can see here, after a scene change (new scene), the bitrate drops enormously (notice the next six B/P frames with their very low size). Then at the next gop (same scene I frame), the bitrate returns to its right value and so the quality.

The quality in that zone is really low, with lots of compression artefacts... and the average bitrate of the stream should be 33 Mbps.

Also, I would like to point out that it's not happening with a particular x264 release... I already encoutered this type of problem with elder x264 revisions. Depending on the footage, on a general 2 hrs movie this may happens 3-4 times. With the movie I'm working on now (action anime), it's happening 15 times :(

[Sharc]

Interesting Is this the same for 1-pass CRF or 2-pass?
What are your encoder settings?

[mp3dom]

The encoder settings are fairly standard for bluray production:

--bitrate 33000 --preset veryslow --tune film --bframes 2 --bluray-compat --vbv-maxrate 38000 --vbv-bufsize 30000 --level 4.1 --no-fast-pskip --no-dct-decimate
--keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1


The problem is the same on both 1-pass CRF or 2-pass.

[mp3dom]

Just a quick update: I already changed lots of settings including qcomp, qpstep and others even in an extreme way just to see if something happens, and I guess the culprit is the VBV management. The *only* way I found so far to fix the problem is just to eliminate the VBV management (which of course is not possible for bluray).
In the example I posted above, the "previous scene" without VBV on crf 9 reaches 100 Mbps (it's a complex scene with lots of added grain). The scene just after that, without VBV is around 35-40 Mbps (less grain and less complexity) and it's encoded perfectly fine. But when everything is under VBV management, the 100 Mbps is then capped to 35-38 Mbps (of course, it can't go beyond that), but the scene just after that is "capped" too, to a 10-15 Mbps for the first gop, then it returns to its 30-35 Mbps.
I don't know exactly how it works, but is it possible that something is wrong with vbv, that need to "flush" the buffer for one gop or something similar? Anyway it's too much visible quality wise.
As I already wrote in the post, with this source the problem happens 15 times so in the actual state it's impossible for me to use x264, there's too much visible quality drop.

[sneaker_ger]

Does the same happen with open-gop disabled, vbv enabled?

I'd probably try to cut a sample and send it to #x264dev (on freenode). The vbv-lookahead with your settings should be like 30 frames so it should see the I frame soon enough. Maybe the devs can improve the algo.

[mp3dom]

Need to test about closed-gop (not tested yet, I'll try asap and report).
I tried to get in touch with kierank already on freenode, but unable to speak with him directly... that's why I then wrote here.

[Sharc]

As a workaround you could try to reduce the resolution to 1440*1080, sar 4:3 (for DAR 16:9) which is still blu-ray compliant. It may reduce the bitrate of the previous scene and stress the buffer control less.
A slightly lower overall quality is less annoying than an excellent quality for the vast majority of the frames but with few visibly bad frames.

It surprises me that this probelm has not been discovered before .....

[Emulgator]

Back then when those 3 reference movies were encoded with x264 r1538+1 to prove Blu-ray compliance
I found the same behaviour resulting in "wet patches". x264 is trying to save bits when it should not.
Since then my remedy is to tickle x264 by adding grain and not looking back.
GrainFactory3(2,2,1,100,100,100,0.9,0.7,0.5,0,0,0,0,0,24,56,128,160)
This line is close to the end of my BD-scripts.

[sneaker_ger]

Btw, how does the scene change look? Is it an abrupt cut or some kind of fade?

IIRC the devs recommended using something like --tune grain for such high bitrates anyways as it would more evenly distribute bits. (--tune grain has lower --qcomp and --aq-strength than default and film.)
Maybe you can mitigate the problem a bit that way for the time being.

[mp3dom]

I'm testing the closed-gop now.
BTW, reducing the resolution and going "anamorphic" (assuming this can solve the problem) is out of question mainly because the movie is supposed to be full 1920x1080 and you can't even justify this commercially above the fact that all over the world this was released as 1920x1080. In the worst case I prefer to simply change the encoder and keep the full resolution.

I don't even think it has to do with grain preservation or something "grain-related" mainly because with zones I can fix that part but then the problem is just shifted to when the zone ends regardless of the type of the scene (i.e. it appears with the same problem afterwards).

Regarding the scene change, it's a complete scene change, no fades or something similar. x264 correctly puts the I frame there, I also tried to specify an IDR rather than standard I, but the result is the same.
Also tried to set qcomp way higher or way lower than standard (as an extreme) but nothing changed. I can't vary AQ-strength too much because I have also lots of smooth gradients that I need to preserve. With such high bitrates and the footage I'm working on, I found 0.8 to be a good compromise.

Edit: Closed GOP+VBV didn't change the result

[jpsdr]

It surprises me that this probelm has not been discovered before .....
It's also suprising considering the time x264 has been used, but it seems trigged in specific conditions, and maybe the rare cases it occured, the quality drop wasn't so noticeable than this case mp3dom hits.
Also it occurs only when VBV is used, which is probably "only" almost in blu-ray targeting.
My guess, is more than 95% of x264 users are only doing one pass crf encode without using VBV.
So, finaly, after thinking, maybe a little less surprising (but still a little...:p).

[Sharc]

@mp3dom
Did you try aq-mode 2, or aq-mode 3?

[mp3dom]

I've tried aq-3 with very little difference, the huge bitrate drop is still present.

[Asmodian]

It really does seem like a bug or failing in the VBV logic. Somehow it thinks the buffer is empty when it shouldn't?

[Sharc]

I've tried aq-3 with very little difference, the huge bitrate drop is still present.
It's probably not your favorite, but you may want to try 1-pass ABR. It would distribute the bits somewhat differrently and possibly mitigate the strong drop. Just speculating.

You could also try to PM the developers.

[MasterNobody]

1) it is for sure VBV problem;
2) to fix it developers will need source samples (preferably short one for quick problem reproduction);
3) to mitigate this problem you can try to lower encoder threads count (the lower the better; so you can try even --threads 1) to help VBV (less prediction and faster adaptation).

[benwaggoner]

My guess, is more than 95% of x264 users are only doing one pass crf encode without using VBV.
So, finaly, after thinking, maybe a little less surprising (but still a little...:p).
Maybe 95% of x264 users aren't using VBV, but probably 95% of x264 content does use VBV. Any commercial content meant for playback on HW decoders is going to set VBV and Level to ensure spec compliance and maximize compatibility.

The first thing I'd try is a 2-pass encode, which should fix any rate control oddities from a first pass. With --keyint 24, -rc-lookahead will be capped at 24.

One thing to try, on a hunch that --slices are used very rarely and could have weird quality impacts, is to encode as --level 4.0 --bitrate 25000 --slices 1. If you stick to Level 4.0 in BD, you don't need slices.

You could even try --level 4.0 --bitrate 15000 --slices 1 --keyint 48. If you have a max bitrate of 15M, you can use 2-second GOPs, which would offer a lot more flexible scene cut/IDR placement.

I don't know if either would be a net improvement in quality, but that would help narrow down the source of the issue.

[mp3dom]

2 pass and 1 pass crf have almost the same output, and I'm not saying this from a theoretical point of view, but I've already made both encodes and checked, and the problem is there on both.
Without VBV the output is fine (4 slices included). With VBV the "bad frames" are bad as a whole, there's no discrepancy between each sliced part of the same frame (the quantizers are very similar). I can run an encode with L4.0 and 1 slice for testing purposes, but cannot limit the max bitrate to 25 Mbps on a final encode when blurays allows to go up to 40 Mbps. Also, there's also the possibility that a lower bitrate may "hide" the problem itself.

I'm currently running an encode with only 1 thread, but obviously it's very slow (less than 1 fps). I think by tomorrow I should be able to report the result.

[jpsdr]

As MasterNobody said, it's seem now obvious that it's a VBV problem. Are you able to provide devs a small sample which produce the problem, allowing them to analyse/check and, hopely, fix it ?
For now, it seems the only thing to do to have a real solution, i'm affraid. And if done "quick enough", and by luck, they have the possibility and time to make a fix within not too long, and they put it on their dev branch, i would be able to make a build with the fix.

[mp3dom]

I'm able to provide only encoded parts that shows the problem. Just a part of the source is not enough, because it doesn't "trigger" the problem if encoded as "standalone", it appears only when the length is quite long but the source itself is very huge in filesize (not considering that, since it comes from a real master, I can't provide it anyway).

Edit: It appears also with threads=1

[jpsdr]

I may have an idea... Are you able to provide a source which trig the issue creating a file like this :
You choose a small part where the scene change trig the issue, the sample will have 3 scenes, so 2 change scene :
[Scene 1][Scene 2][Scene 3]. The issue is trigged between scene 2 and Scene 3.
You create an avs script like this (i'm assuming input file is an avi file in lossless codec) :

a = AviSource("Small_Sample.avi").trim(0,xxxx)
b = AviSource("Small_Sample.avi").trim(xxxx+1,0)
a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+b

xxxxx/xxxx+1 : The frame number of the scene change between Scene 1 and Scene 2. So a will have only [Scene 1], and b will have [Scen2][Scene3}.
Put enough "a" to finaly be able to trig the issue at the end of the file.
Will that trick enable you to provide a trigged sample, without having to provode the whole file (which is of course totaly not possible) ?

[mp3dom]

Ok, found a good trim.
If some dev really want to look into that, please drop me a PM (I can't share the source publicly).
Thanks.

[Sharc]

In case something positive will develop it would be great to learn about it here. Thanks.

[mp3dom]

Yep, so far the problem appears even with threads=1, and with ABR the problem is even more evident (it last 4 seconds, while with CRF or 2-pass it last up to 1 second).
I gave the source to one dev anyway, so if there's something that needs to be fixed, I guess the git will be updated.
Thanks.

[jpsdr]

Ok, at least, things are on their way. After, it will be done when it will be done...:D

[Emulgator]

mp3dom, out of interest if my approach would fit your scenario:
Does the bitrate behave properly if you add grain as I suggested in post 8 ?
(Since the source is not published, otherwise i would try myself.
My encodes were all Bluray 2-pass Level 4.1, slices = 4)

[mp3dom]

I haven't tried an encode with your settings, but checked the effects of the added grain.
I think there's too much grain compared to the original, tbh. It may probably work but mainly because if the grain is always present throughout the stream, the problem is not "triggered" at all (i.e. x264 always keep the quantizers at a certain level).
I see this more like a way to "work around" the problem rather than to fix it.
It may work now, but I can't add grain to every stream...

[Emulgator]

That was what I wanted to know, no matter if it is your grain or my grain (the latter being barely noticeable at 2,2,1 delta pixels), it is only my workaround to exactly make "x264 always keep the quantizers at a certain level" and it does not fix the underlying problem, I agree right away from the start.

[mp3dom]

Yep, but in fact I thank you for the suggestion and effort, and I'll keep it as an alternative way just in case, but currently, as I work on commercial titles, I can't "deviate" from the real source too much, especially if the title is already available in other countries and can be easily compared.
Also, I guess the grain can't be too low or too much "invisible", because you can get the opposite effect (not enough quantization applied by x264 with blocky grain)

[benwaggoner]

Yep, but in fact I thank you for the suggestion and effort, and I'll keep it as an alternative way just in case, but currently, as I work on commercial titles, I can't "deviate" from the real source too much, especially if the title is already available in other countries and can be easily compared.
Also, I guess the grain can't be too low or too much "invisible", because you can get the opposite effect (not enough quantization applied by x264 with blocky grain)



Did you try —level 4.0 —bitrate 25000 —slices 1? If that fixes the problem, that’d narrow down the issue to rate control of slices in particular.

I kind of hate slices; even though they work well most of the time, if you have significant variability in content characteristics between the slices, the encoder might wind up with some obvious QP differences along very visible horizontal lines.

IIRC Blu-ray only has slices for Level 4.1 to make it easier to make parallelized software decoders for PC playback. Frame-threaded decode is generally preferable, but it’s harder to do with only two B-frames.


Sent from my iPad using Tapatalk

[mp3dom]

It happens even with level 4.0 and bitrate 25Mbps with 1 slice... but I think to have a little understood the culprit.
The problem appears only with VBV for a basic reason: given the maximum bitrate to be 40 Mbps and focusing on the last second only (where the scene change and the problem appear), the scene-change is at about 3/4 of that second. Previous scene (18 frames length) is bitrate hungry (crf-7 eats about 100 Mbps without VBV) while the remaining 6 frames (where the problem appears) is less demanding (crf-7 eats 40 Mbps without VBV), so x264 allocate the most of the bitrate to the hungry scene leaving not enough bitrate to encode the last 6 frames efficiently. The QPs on the grainy scene are near 15, while on the other scene are near 12. After that second, the scene "regain" its bitrate because the 40 Mbps are now spread across the same kind of scene, and not a new (totally different) one and the average qp is lowered to about 6. I guess adding grain to those 6 frames makes some difference mainly because I just "force" x264 to lower the quality on the grainy scene and give some more bitrate to the gradient scene.

[benwaggoner]

It happens even with level 4.0 and bitrate 25Mbps with 1 slice... but I think to have a little understood the culprit.
The problem appears only with VBV for a basic reason: given the maximum bitrate to be 40 Mbps and focusing on the last second only (where the scene change and the problem appear), the scene-change is at about 3/4 of that second. Previous scene (18 frames length) is bitrate hungry (crf-7 eats about 100 Mbps without VBV) while the remaining 6 frames (where the problem appears) is less demanding (crf-7 eats 40 Mbps without VBV), so x264 allocate the most of the bitrate to the hungry scene leaving not enough bitrate to encode the last 6 frames efficiently. The QPs on the grainy scene are near 15, while on the other scene are near 12. After that second, the scene "regain" its bitrate because the 40 Mbps are now spread across the same kind of scene, and not a new (totally different) one and the average qp is lowered to about 6. I guess adding grain to those 6 frames makes some difference mainly because I just "force" x264 to lower the quality on the grainy scene and give some more bitrate to the gradient scene.
Sounds like a job for two-pass encoding!

[mp3dom]

I'm resuming this topic just to know if some dev had the chance to take a look into the problem that, depending on the source, may happens more or less often but it's very difficult and time consuming to fix afterwards, even with the use of zones.
Thanks.

[benwaggoner]

I'm resuming this topic just to know if some dev had the chance to take a look into the problem that, depending on the source, may happens more or less often but it's very difficult and time consuming to fix afterwards, even with the use of zones.
Thanks.
Yeah, it is a thorny one. Did you use a different encoder in the end?


Also, I'm curious if you tried --slices 1 --vbv-maxrate 25000. It might not make sense in practice, but could pinpoint whether this is a rate control issue specific to slices (which are a relatively rarely used x264 feature).

Also, what are the QPs before and after you get the hit? It's possible raising --qpmin some might reduce the initial VBV peak, allowing for a shallower valley to follow.

Lastly, perhaps try a third pass to see if that changes anything?

[mp3dom]

I was able to fix it a bit (the problem is still there, but less evident) adding a cetain amount of grain to the image, but this clearly is a workaround and not the right way to fix it, since the grain was not there in the source! Also, adding grain is not always enough, it depends on the scene itself and with totally flat sources, adding grain on selected scenes is a no-way... too much evident that there's something wrong.
The problem is triggered when using vbv, 1 slice or 4 slices doesn't make any difference, and the same apply to the use of a third pass or lowering the threads.
During and after the "hit" there's a big jump in QP values, I saw a difference of 14-15 on some cases and since the scene is exactly the same, it's clearly visible especially on gradients/shades, albeit the problem last for 1 second.

[jpsdr]

As far as i know, even if trigging the issue is not easy, you have provided the devs specific materials to reproduce the issue since a little time now.

[benwaggoner]

I was able to fix it a bit (the problem is still there, but less evident) adding a cetain amount of grain to the image, but this clearly is a workaround and not the right way to fix it, since the grain was not there in the source! Also, adding grain is not always enough, it depends by the scene itself and with totally flat sources, adding grain on selected scenes is a no-way... too much evident that there's something wrong.
The problem is triggered when using vbv, 1 slice or 4 slices doesn't make any difference, and the same apply to the use of a third pass or lowering the threads.
During and after the "hit" there's a big jump in QP values, I saw a difference of 14-15 on some cases and since the scene is exactly the same, it's clearly visible especially on gradients/shades, albeit the problem last for 1 second.
Yeah, sounds like a fundamental rate control issue. Blu-ray uses a lot shorter GOPs than "normal" x264 scenarios, which limits the scope of --rc-lookahead, which could factor in. A real fix will require dev work.

A temp fix would probably entail reducing the initial peak, so the following valley doesn't need to go so low. Something like --qpmin 8 or --nr 500 might be worth trying. Hopefully lower values could work in practice.

[mp3dom]

As far as i know, even if trigging the issue is not easy, you have provided the devs specific materials to reproduce the issue since a little time now.

3-4 months ago I think...

A temp fix would probably entail reducing the initial peak, so the following valley doesn't need to go so low. Something like --qpmin 8 or --nr 500 might be worth trying. Hopefully lower values could work in practice.
Yeah, but it's very time-consuming because if you have 5-6 of these problems in a single movie, it's hard to fix all of them and you're going to encode the movie a lot of time before getting acceptable results.

[benwaggoner]

3-4 months ago I think...


Yeah, but it's very time-consuming because if you have 5-6 of these problems in a single movie, it's hard to fix all of them and you're going to encode the movie a lot of time before getting acceptable results.
Yeah, I don't see any production-ready solution without an actual bug fix.

[Emulgator]

Out of curiosity, while getting back to adding grain as I suggested seemed to help,
has anyone tried x264 incorporated in TMPGEnc AuthoringWorks 5 regarding that matter?
I found that private x264 build quite nice for the few occasions I used it on
but did not bother doing elaborated comparisons regarding the bitrate drop problem back then...

[infoeater]

Maybe you could lower qcomp value? 0, will produce nearly constant bitrate without any peaks, 0.3 may be enough to prevent such high bitrate peaks. It will be suboptimal, but still better then adding artificial noise (providing both better compression/quality ratio and similarity to original).

[mp3dom]

It can be a workaround, but only if the average bitrate is close to the maximum bitrate allowed.
It doesn't make sense to have a "constant bitrate" at 20 Mbps when I can have bitrates up to 40 Mbps according to the scene complexity.
The risk is to have a way worse visible quality, since this "quality drop" problem I get affects the first second/gop of a scene, the time needed for the encoder to "recover" its quality.

[jpsdr]

As far as i know, all the necessary data have been provided to the devs to reproduce and analyse the issue, months ago.
If any dev is reading this thread, is it possible to have any feedback on the status of this issue ?

[infoeater]

It can be a workaround, but only if the average bitrate is close to the maximum bitrate allowed.
It doesn't make sense to have a "constant bitrate" at 20 Mbps when I can have bitrates up to 40 Mbps according to the scene complexity..
First default qcomp=0.6 provides some bitrate variability. Then if it exceeds limits, it's limited by broken bitrate management. Probably not only in places where you see it, but many more, where quality drop is not so noticeable.

When you lower qcomp for whole movie, bitrate variability before broken bitrate management is stabilized, so it's not used that much. qcomp=0.0 will give you nearly constant bitrate, but it will be indeed needed only if your average bitrate is close to maximum bitrate allowed.

When you lower qcomp, to say qcomp=0.3, bitrate is stabilized in quite smart way. It's taken much more from places with bitrate above allowed maximum (places with highest bitrate), and it's taken first from places where it will be less noticeable. This bitrate is not totally wasted, but distributed to places with low bitrate. Compare it to adding artificial noise, which will change distribution of bitrate, but also just waste a lot of it (encoding noise is very bitrate-demanding, in fact it works just because it is so bitrate demanding, that complexity of rest of the video becomes less important) to lower quality.

While lowering qcomp is suboptimal (because most bitrate is taken from scenes with bitrate 80 Mbps, but some (but less) also from scenes with 40 Mbps, it is designed to change overall bitrate distribution, not enforce maximum bitrate), the loss in quality is not big.


The risk is to have a way worse visible quality, since this "quality drop" problem I get affects the first second/gop of a scene, the time needed for the encoder to "recover" its quality

qcomp when lowered just as needed for this particular encode will probably not do that. The optimal value depends on particular video (higher difference between maximum allowed and average bitrate -> higher qcomp, more problematic scenes -> lower qcomp). But there is a great chance you will find value which is ok for 99% videos, or you will learn how to adjust it. You can always check on two levels faster preset (which will speed up many times). You can encode video without bitrate restrictions first to see level of bitrate before broken bitrate management. Give it a chance;)

Other way is limiting bitrate of high complexity scene before problem with zones. If you have time to find optimal bitrate multiplier<1 and length of scene for each scene for each encode it will be nearly optimal. It's just what working bitrate management should do. Note that in fact you need to limit it's bitrate only a bit, but you may need very low bitrate multiplier to accomplish this, because it affect not actual bitrate, but bitrate before broken bitrate management.

Also note, that perfect quality even without this problem might not be sometimes possible without removing details from source, because maximum allowed bitrate might be just not enough.

[mp3dom]

I checked a whole full 2hrs movie, on a frame by frame basis also with debuggin tools, to spot this issue, to see when and where it happens and created, also thanks to jpsdr, a video sequence that can easily trigger the issue.
The problem refers mainly to the vbv management and, by reflection, the bitrate. When there's a very complex and lengthy scene (mainly "particles effects", dust or a "grainy" scene that easily eats bitrate, when both previous and next scenes doesn't have grain or this kind of complexity) the bitrate go well over the allowed max bitrate thanks to the vbv. This is fine and expected, but the problem is that the vbv reach its very maximum, it hits its fullness and so, when the complex scene ends, the next one (simpler) is used by x264 to flush the buffer. In that circumstance, the vbv go from 30 Mbps (its maximum on bluray) to almost 10-12 Mbps in one gop/1 second, thanks to an extreme bitrate drop. From the next gop, both vbv and bitrate regain their right values. In that 1 second/gop quality drop, the qp values are very high (in the 24-25 range) whereas otherwise it would have been 10-12, so compression artifacts are very visible.
The qpcomp can't be changed by zones, I can't encode different segments either (on a 2 hrs movie I risk to have 6-7 segments ). Lowering bitrate using zones for the complex scenes may be not enough either and it's not always working. Raising the bitrate for the next simpler scene doesn't work at all (seems to just ignore the zone, probably because the vbv status doesn't allow this).

I'll try to encode with a more lower qcomp and see if this happens anyway or not.

It's a serious problem especially for animation, when you go from simple to complex scene very ofter... quite unlikely this happens on standard movies.

[StvG]

Did you try rc-lookahead 250 ?

[mp3dom]

With bluray encoding, the max value of rc-lookahead is one second (24).

This is the vbv/bitrate ratio:
http://images2.imagebam.com/d9/96/30/a059ed1202601404.png

[benwaggoner]

The qpcomp can't be changed by zones, I can't encode different segments either (on a 2 hrs movie I risk to have 6-7 segments ). Lowering bitrate using zones for the complex scenes may be not enough either and it's not always working. Raising the bitrate for the next simpler scene doesn't work at all (seems to just ignore the zone, probably because the vbv status doesn't allow this).

I'll try to encode with a more lower qcomp and see if this happens anyway or not.

It's a serious problem especially for animation, when you go from simple to complex scene very ofter... quite unlikely this happens on standard movies.
Maybe use the qpfile to raise the QP of the difficult region so it doesn't exhaust the VBV so much? Manually lowering QP for the following easy region might also help.

I'm curious if the quality issues are due to the first IDR of the lower quality region being specifically low; IDR is very important in animation! Just setting that frame's QP might change things a bunch.

[StvG]

With bluray encoding, the max value of rc-lookahead is one second (24)...

... rc-lookahead is not necessarily capped to keyint, the mb-tree lookahead is... (https://forum.doom9.org/showpost.php?p=1321553&postcount=20)

vbv-lookahead can actually be even higher than keyint depending on other settings (https://forum.doom9.org/showpost.php?p=1322119&postcount=28)

[jpsdr]

It will be capped because vbv_buffer_size=30000, maxrate=40000 => bufsize < 1 => X264_MAX( h->param.i_keyint_max, bufsize*fps ) = keyint_max (in our case of Blu-Ray encode where fps=24 and keyint_max=24) => X264_MIN( h->param.rc.i_lookahead,keyint_max) = keyint_max = 24.
Unless... I'm assuming wrong thinking vbv_buffer_size is also the value of vbv_max_rate...
What happens if we don't redure rc-lookahead and/or vbv-lookahead ?