I set my encode for automated 2-pass encode with 18,500Kbps setting.
For some reason though, when it plays, the bitrate displayed in the player details goes all over the place. Sometimes as low as 11,000's up to 37,500 depending on the frame or scene. I set it for 18,500 and its mostly playing at around 12,000-16,000 with random high and low spikes.
Is there an x264 setting I can adjust so it doesn't fluctuate so much? It's free to go up and down in bitrate like it has been, but I would like it more if it did not go more than 4500 above or below the set bitrate in the settings so the bitrate/quality is more even/stable. I don't mind it going up and down some, but I do mind it going all the way down to 11,000 or up to 38,000 at random times when I set it at 18,500.
The first thing I could think of was adjust qpmin and qpmax to try and set a minimum/maximum allowed. It does change things somewhat, but it doesn't seem to be helping all that much or making much difference. Some frames go slightly higher or lower than before, but it still fluctuates just as much. If I put them too close together in value such as 8 qpmin and 18 qpmax, the size increases about 25% as soon as it goes down to under 20. This has worked the best so far though. It just gave the cost of a bigger file size for the chosen bitrate.
I tried raising the qcomp to 0.7, 0.8, and 1.0, but it made most things worse, and only helped faster motion frames by allocating more bitrate to those and less to everything else. It still fluctuated around just as much though. It also pulled it down to the 9000's at some places when compared to no less than 11,000 before it was raised above 0.6. The max went up to 39,000 as opposed to 37,500 before. It seems to fluctuate the minimum and maximum higher amounts when its raised, but it seems to stay around the target setting a little better more of the time as well.
Anything else I can try? Would a higher rc lookahead benefit it any?
Code:cabac=1 / ref=5 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=18500 / ratetol=1.0 / qcomp=0.60 / qpmin=8 / qpmax=26 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
+ Reply to Thread
Results 1 to 15 of 15
Definition of vbr
vbv settings ? (chat gpt&co can help you to explain how to use vbv to restrict bit rate fluctuation)users currently on my ignore list: deadrats, Stears555
You can use --vbv-maxrate and --vbv-bufsize to limit bitrate peaks.
--vbv-maxrate 23000 --vbv-bufsiz 23000
One other thing to check: how are you measuring bitrate variance, and do you trust your tool?
I don't have any specific suggestions, but before you spend a massive amount of time on this, you might want to use some other measurement tool and see if you get the same results.
Could you explain how to read that a bit, please?
I see blue, then purple on top, a red mark, and a gray horizontal line moving up and down across it all.
I figured out what the red mark at the bottom is //Where it peaks//, but whats with the blue and purple colors?
Is that bitrate and buffer sizes?
When encoding for internet, looking for some steady stream, for example some stream around 2000 kbps, doing the same setting CRF 18 and max buffers.
x264 will be overshooting a bit, so counting on that. That would cut peaks off.
The thing is, if having enough bitrate for a resolution, cutting peaks off is actually not that visible at all. On the other hand, you'd notice artifacts in low light/gradients pretty much all the time, but not parts when there is enough bitrate with most likely lit scenes and image is well defined and drawn. So you can increase CRF. If you lower CRF and leaving same VBV max to cut peaks, your distribution will be more and more look like CBR. If you experiment for a while, you would know what to set for your video material.
Last edited by _Al_; 14th Aug 2023 at 02:03.
I always thought the 2-pass encodes I was doing were the bitrate I picked in the settings or CBR for the entire thing. Is there no way to make it 18,500Kbps for the entire video with no changes in bitrate at all as it plays?
And any encoder that allows a constant bitrate will simply pad the low bitrate sections with junk. Using a constant bitrate is basically a stupid idea. Why should an all black shot (or even a detailed still shot) use just as much bitrate as a highly detailed high motion shot? If you use a low bitrate the black shot will look fine but the motion shot will look terrible. If you use a high bitrate the high motion shot may look fine but you will have wasted a lot of bitrate on the black shot.
The reason you are seeing bitrate peaks higher than the vbv specified values has to do with how different programs measure bitrate. The Bitrate Viewer images I posted were in "second" mode. Each bar in the graph represents the bitrate over one second of video. For a 24 fps video the first bar represents the average bitrate of frames 0 to 23, the next frame 24 to 47, etc. Bitrate Viewer also has a "frame" mode where each bar represents the bitrate of one frame. So the first bar is the size of the first frame multiplied by 24 (the duration of that frame is 1/24 second but bitrate is expressed as kbits per second so for the duration of that frame the bitrate is 24 times that size of that frame). The second bar is the size of frame 1 multiplied by 24. Etc.
Second based bitrate:
[Attachment 73209 - Click to enlarge]
The same portion of the video with frame based bitrate:
[Attachment 73210 - Click to enlarge]
So you can see how these two different methods of measuring bitrate show a vastly different max bitrate over that section of the video.
And, in fact, the average bitrate over the entire video is the size of the video stream (ie the sum of every frame) divided by the overall running time. Just like each of the above methods, just over a different duration.
Bitrate Viewer doesn't have a VBV mode, but with VBV the bitrate is basically measured with a sliding window. Hardware devices have a small, fixed amount of memory (the buffer) in which to store incoming frames being decompressed. After a frame has been decompressed it is removed from that memory and a new frame is read from the source. Individual frames are allowed to have higher than the average bitrate (I frames) because there will be a lot of lower bitrate frames around it (P and B frames). So that one frame won't cause a buffer overflow.
With 2-pass one can set the average bitrate to achieve a desired file size (=average bitrate x video duration), so it is typically used when one wants to fit the capacty of a medium, e.g. a DVD. The instantaneous bitrate however fluctuates dynamically according to the complexity of the frames (scenes). It is not constant.
1-pass CRF controls the bitrate on the fly based on a "Constant Rate Factor" (CRF parameter) and looking ahead a number of frames. The bitrate varies according to the complexity of a frame (scene), and the file size is unpredictable. One can however try to achieve a certain file size by adjusting the CRF in a series of manual trial-and-error experiments. The bitrate distribution (fluctuation) of a 1-pass CRF encode and a 2-pass ABR encode is very similar for the same file size, means there is little to no quality difference if we compare a 1-pass CRF encode with a 2-pass encode at the same file size.
Constant bitrate encoding (CBR) is not directly supported by x264. It's not recommended anyway for the reasons jagabo has explained. In x264 --vbv-bufsize and --vbv-maxrate provide a way to ensure that the bitrate is constrained to a certain maximum. It can be used both with 2-pass or 1-pass CRF encoding, so you may want to try it out. But you shouldn't have to tamper with it unless your playback using a certain player stutters due to the bitrate peaks.
For a pseudo "CBR" setting for x264 see here:
Last edited by Sharc; 16th Aug 2023 at 15:16.