View Full Version : Changing the bitrate after the first x264 pass?
Stereodude
17th June 2011, 01:06
I did some searching and everything points to the fact that the bitrate in the command line doesn't have to be the same between the first pass in x264 and the second pass, which means you can change the bitrate after the first pass and not generate any errors and have a successful encode. But, is there a rule of thumb in terms of the percentage change in bitrate you can make before you should redo the first pass? Say, something like +/-5% from the first pass bitrate, or is the answer more complicated than that?
Basically, if I end up with something that won't fit on a disc after spending >24hours encoding using placebo due to cutting it a little too close, I'd like to know if I can adjust the command line bitrate slightly and simply run the 2nd pass again cutting the encoding time in half.
:thanks:
Blue_MiSfit
17th June 2011, 01:20
This is correct, you can use a different bitrate in the second pass. It makes things somewhat less ideal, but it's still better than 1 pass VBR :)
I don't think you can boil it down to an easy rule like "if it's 5% different, you must re-do both passes". I'd do some PSNR or SSIM tests to see how much impact it ultimately has.
Consider this though.. so called "adaptive streaming" systems usually run a single analysis pass at bitrate Y, and then multiple output passes at bitrates X, Y, and Z. These bitrates are always wildly different (1.5mbps to 4.5mbps). The first pass stats are re-used because these adaptive streaming systems require matched GOP structures, and these decisions are all made in the first pass. Does this have some impact versus letting each output have a full 2 pass encode? Yes. Does it look like crap? No. Would I suggest doing this unless you had to? Definitely not :)
At the end of the day, I wouldn't worry if my second pass was going to target a substantially different bitrate... but then again I always use CRF encoding at home, so I couldn't care less. :devil:
Derek
benwaggoner
17th June 2011, 21:41
Consider this though.. so called "adaptive streaming" systems usually run a single analysis pass at bitrate Y, and then multiple output passes at bitrates X, Y, and Z. These bitrates are always wildly different (1.5mbps to 4.5mbps). The first pass stats are re-used because these adaptive streaming systems require matched GOP structures, and these decisions are all made in the first pass. Does this have some impact versus letting each output have a full 2 pass encode? Yes. Does it look like crap? No. Would I suggest doing this unless you had to? Definitely not :)
One complexity with adaptive streaming is that frame size is generally different per GOP as well, which can increase the suboptimization. Also, lower bitrates may be at half fps, with even a bigger difference.
However, a general 1st pass plus lookahead for the 2nd passes seems to work pretty well. Adaptive streaming tends to be pretty CBR-ish, so there isn't THAT much room to spread bits around.
nhakobian
18th June 2011, 02:37
One complexity with adaptive streaming is that frame size is generally different per GOP as well, which can increase the suboptimization. Also, lower bitrates may be at half fps, with even a bigger difference.
However, a general 1st pass plus lookahead for the 2nd passes seems to work pretty well. Adaptive streaming tends to be pretty CBR-ish, so there isn't THAT much room to spread bits around.
So does it just require that IDR frames lie on the same frame numbers in each of the bitrates/resolutions or does it require the whole GOP structure to be identical? Your comment about lower bitrates suggests that it just requires IDR frame alignment between the streams. There is an interesting thread on doom10 right now (which very well might have spawned this question), but havent found much discussion on the topic.
Dark Shikari
18th June 2011, 04:33
The first pass stats are re-used because these adaptive streaming systems require matched GOP structuresBitrate has no effect on GOP structure.
Blue_MiSfit
18th June 2011, 22:45
@Dark_Shikari:
So is it safe to assume that the following encodes would give precisely identical gop structures, assuming input.avs is the same video, at the same resolution?
x264 input.avs --bitrate 2000 --vbv-maxrate 2000 --vbv-bufsize 2000 --output 2000.264
x264 input.avs --bitrate 4000 --vbv-maxrate 4000 --vbv-bufsize 4000 --output 4000.264
x264 input.avs --bitrate 6000 --vbv-maxrate 6000 --vbv-bufsize 6000 --output 6000.264
@BenWaggoner:
You're right about frame sizes usually changing with adaptive streaming. That's certainly the case for many systems, but for the system I'm most familiar with, frame size does not adaptively change, only bitrate. Switching to a lower resolution means a few seconds of rebuffering, and switching to a higher resolution (480p->720p->1080p) usually means also coughing up another buck or two ;)
Dark Shikari
18th June 2011, 22:45
It should be.
Blue_MiSfit
18th June 2011, 23:19
Interesting. I'll have to do some tests!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.