rate control problem of x264

[dy_dragon]

as i understand, the x264 provides some rate control methods, such as ABR,CRF, and so no. however, in these methods, only the ABR can make the real bitrate near the target bitrate. But, the aim of ABR is make the overall bitrate near the target, while it does not consider the rate of each frame. so ,the bitrate curve of ABR result in periodic fluctuation.
in my opinion, the ABR adjust the QP accoding the difference between current bitrate and target bitrate, while G012 or some kindred algorithms(such as TM5,TMN8) give a budget to current frame first, and then make the rate of current frame near the budget.
My question is , can x264 use this idea to get a smooth rate curve?

[Dark Shikari]

however, in these methods, only the ABR can make the real bitrate near the target bitrateNo, 2-pass can make the bitrate near the target bitrate, and do a far better job than any ABR algorithm.

We do not consider 1-pass ABR to be an important algorithm because it is almost completely useless for all use-cases. CRF covers most offline encoding needs, while streaming is usually CBR or capped CRF, not ABR. And if you absolutely need a specific bitrate, you can use 2-pass mode.

While patches to improve ABR are welcome, do note that we generally don't care too much about features that nobody uses. This doesn't mean we won't accept and review relevant patches, but it does mean that we won't work too hard on them.

[dy_dragon]

Thank you, Dark Shikari!
Because the 2-pass mode will decrease the encoding speed significantly, so i can't use it.
I have tried CRF, but the result bitrate is far from the target bitrate. As to CBR, i don't find the corresponding method in x264(maybe i don't which it is).
So i guess, can we develop a method,which encode in 1-pass, and can make the real bitrate near the target bitrate, while keep the rate of each frame in reason.

[Dark Shikari]

Thank you, Dark Shikari!
Because the 2-pass mode will decrease the encoding speed significantly, so i can't use it.Why not use faster encoding settings to compensate for the small speed loss of 2-pass? Remember, x264 automatically uses faster settings on the first pass, so if the first pass makes up 20% of the total time, why not just use settings that are 20% faster?
I have tried CRF, but the result bitrate is far from the target bitrate.That's odd, since CRF doesn't even let you set a target bitrate.As to CBR, i don't find the corresponding method in x264(maybe i don't which it is).CBR is simply the case in which bitrate == maxrate and bufsize is set.

[dy_dragon]

Why not use faster encoding settings to compensate for the small speed loss of 2-pass
The rate curve of 2-pass is acceptable. However, the 2-pass mode can only be used to encode the offline files. When I need to the online captured image, I cant wait to encode until the capture process finished.

So, can we use the 1-pass mode to get the near 2-pass mode result by any skill? For example, can we use 2-pass mode in every single gop?

By the way, I have trid to set bitrate == maxrate and set bufsize, but the curve still fluctuates.

[Dark Shikari]

The rate curve of 2-pass is acceptable. However, the 2-pass mode can only be used to encode the offline files. When I need to the online captured image, I cant wait to encode until the capture process finished. I don't see the point of ABR mode in this case unless you're directly capturing to some media with static size (e.g. a CD) which seems rather silly.So, can we use the 1-pass mode to get the near 2-pass mode result by any skill? For example, can we use 2-pass mode in every single gop?RC-lookahead already does this, albeit for VBV purposes.

For a long video, there is likely no benefit from doing "2-pass over each GOP", because the benefit of 2-pass over 1-pass is overall bitrate distribution across the whole video. No ABR algorithm can fix this; not to say x264's is as good as it could be, but the problem overall is simply unsolvable.By the way, I have trid to set bitrate == maxrate and set bufsize, but the curve still fluctuates.Then you have no idea how CBR actually works. CBR is a leaky bucket buffering model; individual frames can still vary in size.

[dy_dragon]

CBR is a leaky bucket buffering model; individual frames can still vary in size.
I know CBR just means the bandwidth is constant, but the rate of each frame is still different. No algorithm can make every frame has same size, unless stuff it.

I capture the image from camera, and compress it in real time. The coded stream is transmitted to network or saved on hard disk. Which method suit to this usage? 2-pass or RC-lookahead ?

[dy_dragon]

I capture the image from camera, and compress it in real time. The coded stream is transmitted to network or saved on hard disk
By the way, the compress video must near a target bitrate.

[Dark Shikari]

By the way, the compress video must near a target bitrate.For what reason? Unless I know why you need a target bitrate, I can't give you a good answer.

[dy_dragon]

Unless I know why you need a target bitrate, I can't give you a good answer
The compressed stream will be muxed to TS stream. This Ts file stream will be transimit over network. The network has a fixed bandwidth, so the video stream must has a target bitrate. If the bitrate beyoud the bandwidth, the video stream or Ts stream can't be transimitted.
Besides, the end-to-end delay can't beyond a level.

[dy_dragon]

RC-lookahead already does this, albeit for VBV purposes.
Dark Shikari, would you please explain me the idea of RC-lookahead? how does it improve the result of rate control. I have no idea about it. Thank you very much.

[Dark Shikari]

The compressed stream will be muxed to TS stream. This Ts file stream will be transimit over network. The network has a fixed bandwidth, so the video stream must has a target bitrate. If the bitrate beyoud the bandwidth, the video stream or Ts stream can't be transimitted.
Besides, the end-to-end delay can't beyond a level.You are confusing "target bitrate" with "constant bitrate". You're describing a case for CBR encoding (or capped constant quality), not ABR encoding.Dark Shikari, would you please explain me the idea of RC-lookahead? how does it improve the result of rate control. I have no idea about it. Thank you very much.It looks ahead over a few dozen frames to improve the effectiveness of VBV.

[dy_dragon]

Yes, I need a CBR. But the curve of X264 CBR fluctuates very much.
So, how can I get a curve like 2-pass while not need to encode it twice?

[Dark Shikari]

Yes, I need a CBR. But the curve of X264 CBR fluctuates very much.You appear to be extremely confused, because you still do not know what CBR is. I suggest you read a basic introductory textbook on video compression, or at least use Google to learn how a leaky bucket buffer works.So, how can I get a curve like 2-pass while not need to encode it twice?You're completely nonsensical now: by definition, 2-pass unrestricted encoding is going to "fluctuate" more than CBR.

[shroomM]

After reading the thread, I got a bit confused about the terms, so could you please confirm that my understanding is correct...
I know this has been discussed a lot, but please just bear with me. :)

If I encode a video using the following commands...
x264.exe --preset medium --tune film --pass 1 --bitrate 7000 --stats "input.stats" --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --nal-hrd --output NUL "input.avs"
x264.exe --preset medium --tune film --pass 2 --bitrate 7000 --stats "input.stats" --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --nal-hrd --output "output.264" "input.avs"

x264 is encoding using a 2-pass CBR mode (using the VBV model a.k.a. leaky bucket buffer).
If I strip the --pass commands (and use only one command, obviously), x264 is encoding using a 1-pass CBR mode (still, VBV).

If I strip the --vbv-maxrate and the --vbv-bufsize, x264 is encoding using the unrestricted ABR mode (1 or 2 pass, depending on the rest of the command line - 2 pass being better).

Setting the --vbv-bufsize to something other than 0 and setting the --vbv-maxrate to something other than --bitrate, x264 is using ABR mode and the VBV model.

Is this correct or am I wrong?

Also, the thing I'm not sure about, is, whether there is a big difference between 1-pass and 2-pass CBR.
The reason for asking is your post in this thread (http://forum.doom9.org/showthread.php?t=151281). Why is it "generally pointless" ?

And a bit of thread hijacking, just a quick question...
If I set the keyint to 25 (I need it for seeking), according to the wiki (http://mewiki.project357.com/wiki/X264_Settings#rc-lookahead), mb-tree will use the rc-lookahead value of 25.

But what about the vbv-lookahead? Is the formula there correct?
In that case, x264 will also use my keyint for vbv-lookahead.

(I'm just asking, because I'm not sure my math still works as it should :))

Regards

[Dark Shikari]

After reading the thread, I got a bit confused about the terms, so could you please confirm that my understanding is correct...
I know this has been discussed a lot, but please just bear with me. :)

If I encode a video using the following commands...
x264.exe --preset medium --tune film --pass 1 --bitrate 7000 --stats "input.stats" --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --nal-hrd --output NUL "input.avs"
x264.exe --preset medium --tune film --pass 2 --bitrate 7000 --stats "input.stats" --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --nal-hrd --output "output.264" "input.avs"

x264 is encoding using a 2-pass CBR mode (using the VBV model a.k.a. leaky bucket buffer).
If I strip the --pass commands (and use only one command, obviously), x264 is encoding using a 1-pass CBR mode (still, VBV).

If I strip the --vbv-maxrate and the --vbv-bufsize, x264 is encoding using the unrestricted ABR mode (1 or 2 pass, depending on the rest of the command line - 2 pass being better).

Setting the --vbv-bufsize to something other than 0 and setting the --vbv-maxrate to something other than --bitrate, x264 is using ABR mode and the VBV model.

Is this correct or am I wrong?Correct.Also, the thing I'm not sure about, is, whether there is a big difference between 1-pass and 2-pass CBR.
The reason for asking is your post in this thread (http://forum.doom9.org/showthread.php?t=151281). Why is it "generally pointless" ?Because RC-lookahead is good enough to make 1-pass CBR similar to or even better than 2-pass CBR.And a bit of thread hijacking, just a quick question...
If I set the keyint to 25 (I need it for seeking), according to the wiki (http://mewiki.project357.com/wiki/X264_Settings#rc-lookahead), mb-tree will use the rc-lookahead value of 25.

But what about the vbv-lookahead? Is the formula there correct?
In that case, x264 will also use my keyint for vbv-lookahead.Correct.

[shroomM]

Thanks for all the answers!

Because RC-lookahead is good enough to make 1-pass CBR similar to or even better than 2-pass CBR.

Wow, really? A 2-pass CBR encode could actually be worse quality? Even at such (relatively) small RC-lookahead values?

That is... surprising. :)

I've always had it in my mind, that 2-pass > 1-pass.

Thanks again!

[Lam3rD]

He probably made a typo and meant 1 pass CRF, not CBR. On another note probably 1 Pass CBR has also reached the level of 2 pass CBR with the help of rc-lookahead.

[Dark Shikari]

Thanks for all the answers!

Wow, really? A 2-pass CBR encode could actually be worse quality? Even at such (relatively) small RC-lookahead values?

That is... surprising. :)

I've always had it in my mind, that 2-pass > 1-pass.

Thanks again!

He probably made a typo and meant 1 pass CRF, not CBR. On another note probably 1 Pass CBR has also reached the level of 2 pass CBR with the help of rc-lookahead.Not a typo. The current 2-pass VBV algorithm makes a lot of assumptions about the first pass, most notably that the first pass was actually accurate. If you used a fast first pass, this can sometimes result in 2-pass CBR actually being slightly worse than 1-pass.

In the case of either CBR or VBV-capped constant quality, I would generally recommend 1-pass over 2-pass.

[nurbs]

Hey shroomM, you can shorten your command line to the following without changing the settings used:
x264.exe --tune film --pass 1 --bitrate 7000 --stats "input.stats" --keyint 25 --vbv-bufsize 30000 --vbv-maxrate 7000 --aud --nal-hrd --output NUL "input.avs"
x264.exe --tune film --pass 2 --bitrate 7000 --stats "input.stats" --keyint 25 --vbv-bufsize 30000 --vbv-maxrate 7000 --aud --nal-hrd --output "output.264" "input.avs"

[shroomM]

Hey,

thanks for the reply, but I only posted an example command line.

Otherwise, I'm using a batch file ...

"%exepath%" --preset %1 --tune %2 --pass 1 --bitrate 7000 --stats "%~n3_001.stats" --level 4.1 --keyint 25 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --nal-hrd --output NUL "%3"
"%exepath%" --preset %1 --tune %2 --pass 2 --bitrate 7000 --stats "%~n3_001.stats" --level 4.1 --keyint 25 --ref 3 --bframes 3 --vbv-bufsize 30000 --vbv-maxrate 7000 --rc-lookahead 25 --aud --nal-hrd --output "%~n3_001.264" "%3"

And I need to have 3 b-frames and 3 refs.

The only thing I can strip (and I see that now) is the --rc-lookahead.

Thanks for the suggestion, though! :)

[nurbs]

I see. You can also get rid of the --level since that is automatically set and with your bufsize it will come out as 4.1 anyway.

edit: I mixed up maxrate with bufsize. With that maxrate it could also be lower than 4.1 depending on resolution, so maybe you want to keep it anyway.

[sneaker_ger]

edit: I mixed up maxrate with bufsize. With that maxrate it could also be lower than 4.1 depending on resolution, so maybe you want to keep it anyway.

Question is why someone would want to set the level flag higher than the actual level?

[Asmodian]

Question is why someone would want to set the level flag higher than the actual level?

Because x264 sometimes guesses the level a bit lower then it actually is (It mentions this in the documentation).

[sneaker_ger]

But then it wouldn't be higher than the actual level anymore. ;) Since we're talking about using VBV here I'd say that shouldn't happen in this case. You may have a point for other use cases though.

[Trahald]

Question is why someone would want to set the level flag higher than the actual level?

One reason would be your target format may only accept streams with levels 4, 4.1 but your settings may fit at level 3.0. without intervention x264 would set at level 3.0, but forcing the level up to 4 (or 4.1) would be desired here. this is ok since raising the level is safe.

[sneaker_ger]

I see. Does Blu-Ray require that? (Or any other format?)

[Trahald]

I see. Does Blu-Ray require that? (Or any other format?)

for 720p and up.. yes (wrt only 4.0 or 4.1)

[dy_dragon]

You appear to be extremely confused, because you still do not know what CBR is. I suggest you read a basic introductory textbook on video compression, or at least use Google to learn how a leaky bucket buffer works.
I'm not just a X264 user. I can assure you that I resarch the rate control theory not less than you. I have deeply research the H.263 TMN8 rate control algorithm and the G012 algorithm.

You're completely nonsensical now: by definition, 2-pass unrestricted encoding is going to "fluctuate" more than CBR.
We allow the curve fluctuates. But, the fluctuattion should allocate vailable rate reasonably to each frame, to keep each frame has same quality, instea of allocate bitrate optionally. Usually, we allocate more bits to I frames, and little bits to B frames.
However, the CBR mothed can't do this. It opten allocate little bits to I frames than P frames. This will results in decrease in quality of I frames. The 2-pass can improve this situation obviously.

[Dark Shikari]

I'm not just a X264 user. I can assure you that I resarch the rate control theory not less than you. I have deeply research the H.263 TMN8 rate control algorithm and the G012 algorithm.Understanding rate control algorithms doesn't mean that you understand how the leaky bucket VBV model in H.264 actually works. Your posts suggest you don't understand it.We allow the curve fluctuates. But, the fluctuattion should allocate vailable rate reasonably to each frame, to keep each frame has same quality, instea of allocate bitrate optionally. Usually, we allocate more bits to I frames, and little bits to B frames.
However, the CBR mothed can't do this. It opten allocate little bits to I frames than P frames. This will results in decrease in quality of I frames. The 2-pass can improve this situation obviously.You are confusing the concept of CBR with an implementation of CBR.

2-pass CBR is still CBR. Furthermore, in x264, 1-pass CBR is often better than 2-pass.

You've made this same thread before and you haven't learned a single thing since the last time you made it. You still have no idea what you're talking about and you refuse to learn anything else, so I give up. Find someone else who can educate you on the basics of video compression, the difference between a ratecontrol algorithm and a ratecontrol model, and how a leaky bucket works.

[[ReX]]

Furthermore, in x264, 1-pass CBR is often better than 2-pass.

Tell if I'm wrong: In VBR the first pass gather details of where to use more bitrate and where to use less and use them to do the second pass, right? So if you use two passes in CBR, it'll be using the same bitrate for everything... because of that it is pointless?

[Dark Shikari]

;1353402']Tell if I'm wrong: In VBR the first pass gather details of where to use more bitrate and where to use less and use them to do the second pass, right? So if you use two passes in CBR, it'll be using the same bitrate for everything... because of that it is pointless?That, combined with the fact that RC-lookahead is generally Good Enough to calculate a reasonable bitrate distribution to satisfy the VBV constraints.

[dy_dragon]

Understanding rate control algorithms doesn't mean that you understand how the leaky bucket VBV model in H.264 actually works. Your posts suggest you don't understand it.
Well, a method accord with VBV model doesn't mean that the rate allocation is reasonable.
I will implement a new method with 1-pass coding process which give better ratecontrol effectthan current CBR. I will prove the CBR can be better.

[dy_dragon]

[snip] the real rate of encoding sequence closes to target rate accord to transmiting bandwidth by CBR rate control and CBR rate control limits rate of every frame to avoid network underflow or overflow. so my question as follows,
X264 does not have one method to implement CBR rate control which considers about total target bit and also every frame target bit with 1_pass. yes or no?
[snip] I just want to know whether if there has CBR rate control without 2_pass[snip]

[shroomM]

dy_dragon ... what is the bandwidth of your network?

At which bitrate do you want to mux the transport stream?

[Trahald]

@dy_dragon
Dark_Shikari has stated that he wouldnt explain again. Of course you may ask the question in open forum, just not directly to him. I removed any directed comments and left the core question on your post.

[LoRd_MuldeR]

[snip] the real rate of encoding sequence closes to target rate accord to transmiting bandwidth by CBR rate control and CBR rate control limits rate of every frame to avoid network underflow or overflow. so my question as follows,
X264 does not have one method to implement CBR rate control which considers about total target bit and also every frame target bit with 1_pass. yes or no?
[snip] I just want to know whether if there has CBR rate control without 2_pass[snip]

It seems to me that you are missing a point: The buffer on the receiver's side. Even if the data is transferred over the network at a 100% constant speed, the actual video bitrate is still allowed to fluctuate. It's even desired, because not all frames have the same complexity. If the video bitrate exceeds the network transfer speed for a short moment, this only means the buffer slowly runs out of data. But unless there it too few data in the buffer, so the next frame cannot be decoded, everything is fine! If, after the bitrate peak, the bitrate falls below the network transfer speed, the buffer will start filling again. In other words: All fluctuation is allowed, as long as it does cause any buffer underflows. And that's exactly what VBV does avoid. So if you see fluctuations, that alone is absolutely no problem. VBV violations would be a problem. And x264 doesn't violate VBV without telling you. Or to say it again in yet another way: Data is arriving a the receiver's buffer through the network at a constant rate. But data can be taken from the receiver's buffer by the H.264 decoder at a varying rate. As long as the buffer never runs empty, this will be perfectly fine, because the full network bandwidth is leveraged and the bitrate is adapted to the video contents.

[Stephen R. Savage]

Question: How can 2pass CBR ever be better than 1pass CBR? The whole idea of CBR is that the bitrate is overall constant, and the idea of 2pass is to make the bitrate overall variable to optimize quality within an average size target. If your bitrate can't change, shouldn't that mean that a second pass can't change the results in a meaningful way?

[Dark Shikari]

Question: How can 2pass CBR ever be better than 1pass CBR? The whole idea of CBR is that the bitrate is overall constant, and the idea of 2pass is to make the bitrate overall variable to optimize quality within an average size target. If your bitrate can't change, shouldn't that mean that a second pass can't change the results in a meaningful way?CBR is a leaky bucket-based system. Here's an example.

Let's say we're at 10 seconds into the video, with a 1-second buffer of size 1 megabit, and the buffer is 30% full, meaning it has 300kbit of data in it. If the video is exactly 1mbps at this point, the buffer will stay at 30% full indefinitely.

It might be worthwhile to drop quality slightly here in order to ensure that the buffer has enough room in it at the 20 second mark, where, say, a big action scene comes in. One can generally get away with the approximation of only looking a second or two in advance, like RC-lookahead does, but an absolutely optimal solution requires an unbounded lookahead, i.e. 2-pass.