Setting a *hard* limit for max bitrate with x264?

[Incendia]

I'm not really sure why I can't find anything about this; Thus far I've been unable to make any combination of params that result in a hard limit on the max bitrate on an encode. Everything seems to result in a soft cap where it can still spike past the maxrate. Is there something I'm missing, or does the functionality just not exist?
Encoding a file at a bitrate of 2000 results in a file that frequently spikes to 2300, upwards of 2500 at times; Setting a vbv max to 2k changes nothing, and the only way I can prevent it is by nuking the buffer size, which ends up reducing the overall bitrate ( ~1700 @ 25fps )... not exactly what I intended ( and even at a quarter the bitrate buffer, with a framerate of 60 I'll still get spikes of 2200-2300. Keep in mind I'm just testing at this point ).

As an aside, why are crf and bitrate control modes mutually exclusive? Shouldn't a constant quality control be able to work /inside/ of an average bitrate restriction?

[Dark Shikari]

x264 will almost never violate the maximum bitrate you give it (if it does, it will spam warnings loudly). "Max bitrate" only makes sense in the context of a buffer size -- which tool are you using to measure the maximum bitrate? Is it VBV-aware? Did you enter the correct buffer size?

[Incendia]

I used mediainfo and dgavcdec in concert to confirm the bitrate ( They both show maximums over the set bitrate ); I've no idea if they're vbv-aware ( What does that mean exactly? ).
Define "correct buffer"? I've tried buffers matching, half, quarter, and lower and I always see spikes, though the average is much lower with a low buffer ( reduced quality as a result ).

I'm not getting any bitrate warnings either.
( Output from mediainfo because I can't copy the output from dgavcdec )

https://dl.dropbox.com/u/33446/enc/testo.mp4


E:\rec>x264 --bitrate 2000 --vbv-bufsize 2000 -o testo.mp4 testrgb.avi --demuxer avs
avs [info]: trying AVISource... succeeded
avs [info]: 576x406p 0:0 @ 60/1 fps (cfr)
resize [warning]: converting from bgra to yuv420p
x264 [warning]: VBV maxrate unspecified, assuming CBR
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:40.02 size: 10139
x264 [info]: frame P:589 Avg QP:42.54 size: 4216
x264 [info]: mb I I16..4: 18.5% 67.2% 14.2%
x264 [info]: mb P I16..4: 0.0% 2.9% 0.1% P16..4: 32.9% 15.2% 11.6% 0.0% 0.0% skip:37.3%
x264 [info]: 8x8 transform intra:91.2% inter:63.6%
x264 [info]: coded y,uvDC,uvAC intra: 89.9% 4.2% 1.6% inter: 36.9% 0.2% 0.0%
x264 [info]: i16 v,h,dc,p: 40% 47% 7% 6%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 6% 7% 38% 7% 12% 7% 8% 6% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 19% 20% 10% 11% 7% 9% 6% 7%
x264 [info]: i8c dc,h,v,p: 95% 4% 1% 0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 45.4% 4.3% 30.5% 19.8%
x264 [info]: kb/s:2038.16

encoded 592 frames, 110.24 fps, 2038.79 kb/s



General
Complete name : E:\rec\testo.mp4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 2.40 MiB
Duration : 9s 867ms
Overall bit rate : 2 042 Kbps
Encoded date : UTC 2013-02-22 19:52:23
Tagged date : UTC 2013-02-22 19:52:23

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 9s 867ms
Bit rate : 2 000 Kbps
Maximum bit rate : 2 346 Kbps
Width : 576 pixels
Height : 406 pixels
Display aspect ratio : 1.419
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.143
Stream size : 2.40 MiB (100%)
Writing library : x264 core 129 r2230 1cffe9f
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=12 / lookahead_threads=2 / 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=40 / rc=cbr / mbtree=1 /
bitrate=2000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=2000 / vbv_bufsize=2000 /
nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-02-22 19:52:23
Tagged date : UTC 2013-02-22 19:52:28


https://dl.dropbox.com/u/33446/enc/testo2.mp4


E:\rec>x264 --bitrate 2000 --vbv-bufsize 2000 -o testo2.mp4 testrgb2.avi --demuxer avs
avs [info]: trying AVISource... succeeded
avs [info]: 576x406p 0:0 @ 60/1 fps (cfr)
resize [warning]: converting from bgra to yuv420p
x264 [warning]: VBV maxrate unspecified, assuming CBR
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:23.55 size: 35536
x264 [info]: frame P:260 Avg QP:24.55 size: 6714
x264 [info]: frame B:266 Avg QP:28.30 size: 1262
x264 [info]: consecutive B-frames: 4.9% 79.8% 13.0% 2.3%
x264 [info]: mb I I16..4: 9.7% 41.7% 48.6%
x264 [info]: mb P I16..4: 1.0% 1.2% 0.9% P16..4: 41.9% 19.2% 12.6% 0.0% 0.0% skip:23.3%
x264 [info]: mb B I16..4: 0.1% 0.1% 0.1% B16..8: 35.9% 5.4% 1.3% direct: 1.7% skip:55.5% L0:38.7% L1:56.3% BI: 5.0%
x264 [info]: 8x8 transform intra:39.3% inter:63.4%
x264 [info]: coded y,uvDC,uvAC intra: 58.3% 75.5% 57.4% inter: 17.3% 25.9% 11.0%
x264 [info]: i16 v,h,dc,p: 49% 32% 7% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 28% 24% 3% 5% 4% 7% 3% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 29% 27% 14% 4% 5% 5% 7% 4% 7%
x264 [info]: i8c dc,h,v,p: 38% 33% 20% 9%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 64.5% 16.4% 12.7% 6.4%
x264 [info]: ref B L0: 85.1% 14.3% 0.6%
x264 [info]: ref B L1: 98.4% 1.6%
x264 [info]: kb/s:1985.42

encoded 529 frames, 128.93 fps, 1986.13 kb/s



General
Complete name : E:\rec\testo2.mp4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 2.09 MiB
Duration : 8s 817ms
Overall bit rate : 1 992 Kbps
Encoded date : UTC 2013-02-22 19:56:14
Tagged date : UTC 2013-02-22 19:56:14

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 8s 817ms
Bit rate : 2 000 Kbps
Maximum bit rate : 2 355 Kbps
Width : 576 pixels
Height : 406 pixels
Display aspect ratio : 1.419
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.143
Stream size : 2.09 MiB (100%)
Writing library : x264 core 129 r2230 1cffe9f
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=12 / lookahead_threads=2 / 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=40 / rc=cbr / mbtree=1 /
bitrate=2000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=2000 / vbv_bufsize=2000 /
nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-02-22 19:56:14
Tagged date : UTC 2013-02-22 19:56:19


I'm not sure if I'm even using the right tools to check this honestly, I can't find a bitrate graphing program like I
originally wanted.

https://dl.dropbox.com/u/33446/enc/testo3.mp4


E:\rec>x264 --bitrate 2000 --vbv-maxrate 2000 --vbv-bufsize 2000 -o testo3.mp4 testrgb2.avi --demuxer avs
avs [info]: trying AVISource... succeeded
avs [info]: 576x406p 0:0 @ 60/1 fps (cfr)
resize [warning]: converting from bgra to yuv420p
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:23.58 size: 35467
x264 [info]: frame P:260 Avg QP:24.54 size: 6715
x264 [info]: frame B:266 Avg QP:28.21 size: 1263
x264 [info]: consecutive B-frames: 4.9% 79.8% 13.0% 2.3%
x264 [info]: mb I I16..4: 9.3% 41.5% 49.3%
x264 [info]: mb P I16..4: 1.0% 1.2% 0.9% P16..4: 41.9% 19.0% 12.6% 0.0% 0.0% skip:23.4%
x264 [info]: mb B I16..4: 0.1% 0.1% 0.1% B16..8: 35.8% 5.4% 1.3% direct: 1.7% skip:55.5% L0:38.9% L1:56.1% BI: 5.0%
x264 [info]: 8x8 transform intra:39.0% inter:63.1%
x264 [info]: coded y,uvDC,uvAC intra: 58.1% 75.9% 57.2% inter: 17.3% 25.9% 11.0%
x264 [info]: i16 v,h,dc,p: 49% 34% 7% 10%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 27% 24% 3% 5% 4% 7% 3% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 28% 14% 4% 5% 5% 7% 4% 7%
x264 [info]: i8c dc,h,v,p: 38% 33% 20% 9%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 64.5% 16.4% 12.8% 6.3%
x264 [info]: ref B L0: 85.2% 14.2% 0.6%
x264 [info]: ref B L1: 98.4% 1.6%
x264 [info]: kb/s:1985.64

encoded 529 frames, 128.80 fps, 1986.35 kb/s



General
Complete name : E:\rec\testo3.mp4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 2.09 MiB
Duration : 8s 817ms
Overall bit rate : 1 993 Kbps
Encoded date : UTC 2013-02-22 20:04:49
Tagged date : UTC 2013-02-22 20:04:49

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 8s 817ms
Bit rate : 2 000 Kbps
Maximum bit rate : 2 355 Kbps
Width : 576 pixels
Height : 406 pixels
Display aspect ratio : 1.419
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.143
Stream size : 2.09 MiB (100%)
Writing library : x264 core 129 r2230 1cffe9f
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=12 / lookahead_threads=2 / 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=40 / rc=cbr / mbtree=1 /
bitrate=2000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=2000 / vbv_bufsize=2000 /
nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-02-22 20:04:49
Tagged date : UTC 2013-02-22 20:04:53


https://dl.dropbox.com/u/33446/enc/testo4.mp4


E:\rec>x264 --bitrate 500 --vbv-maxrate 500 --vbv-bufsize 500 -o testo4.mp4 testrgb2.avi --demuxer avs
avs [info]: trying AVISource... succeeded
avs [info]: 576x406p 0:0 @ 60/1 fps (cfr)
resize [warning]: converting from bgra to yuv420p
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:34.47 size: 12128
x264 [info]: frame P:260 Avg QP:35.47 size: 1577
x264 [info]: frame B:266 Avg QP:39.20 size: 346
x264 [info]: consecutive B-frames: 4.9% 79.8% 13.0% 2.3%
x264 [info]: mb I I16..4: 21.6% 50.7% 27.7%
x264 [info]: mb P I16..4: 1.0% 0.9% 0.2% P16..4: 32.0% 5.6% 2.8% 0.0% 0.0% skip:57.4%
x264 [info]: mb B I16..4: 0.1% 0.0% 0.0% B16..8: 27.6% 1.0% 0.1% direct: 0.2% skip:71.0% L0:34.9% L1:64.8% BI: 0.3%
x264 [info]: 8x8 transform intra:46.1% inter:82.6%
x264 [info]: coded y,uvDC,uvAC intra: 35.6% 62.7% 40.5% inter: 4.2% 9.6% 1.8%
x264 [info]: i16 v,h,dc,p: 41% 38% 11% 10%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 22% 35% 3% 4% 4% 6% 3% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 35% 16% 3% 4% 3% 6% 3% 5%
x264 [info]: i8c dc,h,v,p: 50% 31% 14% 5%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 65.9% 17.7% 11.9% 4.5%
x264 [info]: ref B L0: 89.8% 9.9% 0.3%
x264 [info]: ref B L1: 98.5% 1.5%
x264 [info]: kb/s:488.46

encoded 529 frames, 150.33 fps, 489.17 kb/s



General
Complete name : E:\rec\testo4.mp4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 534 KiB
Duration : 8s 817ms
Overall bit rate : 496 Kbps
Encoded date : UTC 2013-02-22 20:05:43
Tagged date : UTC 2013-02-22 20:05:43

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 8s 817ms
Bit rate : 500 Kbps
Maximum bit rate : 573 Kbps
Width : 576 pixels
Height : 406 pixels
Display aspect ratio : 1.419
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.036
Stream size : 526 KiB (99%)
Writing library : x264 core 129 r2230 1cffe9f
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=12 / lookahead_threads=2 / 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=40 / rc=cbr / mbtree=1 /
bitrate=500 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=500 / vbv_bufsize=500 / nal_hrd=none /
ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-02-22 20:05:43
Tagged date : UTC 2013-02-22 20:05:47


I'm also not sure how using bitrate and vbv-maxrate in unison affects things, if it does at all ( Doesn't seem to ).

Am I just coming at this the wrong way?

[phibertron]

Not sure what happend to this tool

http://handbrake.dynaflashtech.net/cgi-bin/vbv_calculator.cgi

But in a nutshell, whether you are using bitrate or crf mode
and are setting --vbv-maxrate and --vbv-bufsize
the numbers specified in those can go higher than the maxrate
According to that calculator and my limited knowledge of vbv
spikes of short duration can be higher than the max bitrate specified,
and still not break vbv-buffer limits
which is why you are most likely seeing bitrates higher than you specified

[phibertron]

There is also this thread on the topic

http://forum.doom9.org/showthread.php?t=147460&highlight=vbv-bufsize

[paradoxical]

I used mediainfo and dgavcdec in concert to confirm the bitrate ( They both show maximums over the set bitrate ); I've no idea if they're vbv-aware ( What does that mean exactly? ).

Those are the wrong tools to use. If you don't want to buy an expensive tool, donate the $15 so you can get Neuron2's VBVChecker. That is how you would properly view if bitrate is exceeding the vbv settings you set.

[Dark Shikari]

Mediainfo is not VBV aware and cannot be used to meaningfully verify VBV compliance. Its "maximum bitrate" is not particularly meaningful.

[Incendia]

Mediainfo is not VBV aware and cannot be used to meaningfully verify VBV compliance. Its "maximum bitrate" is not particularly meaningful.

Again, what does "vbv aware" mean? What does it take to be as much?

[Guest]

Do you understand the concept of VBV? I doubt (understandably) that Dark Shikari is going to give you a newbie account of that.

[LoRd_MuldeR]

Again, what does "vbv aware" mean? What does it take to be as much?

VBV is a buffering model. Put simply, there is a buffer of a specific size (vbv_bufsize) and that buffer is filled at a specific maximum data rate (vbv_maxrate).

An encoder is "vbv aware", if it ensures that the buffer will never underflow. It means that the encoder makes sure that there will always be enough data left in the buffer for the decoder to decode the next frame.

However it does not do more than that. So you cannot calculate the "average bitrate" for arbitrarily defined intervals (e.g. 1 second) and expect that the result will remain below an arbitrarily defined threshold.

(Instead you will need to use a VBV verification tool. And even that can only work, if you setup the same VBV parameters that had been used by the encoder)

[Incendia]

Do you understand the concept of VBV? I doubt (understandably) that Dark Shikari is going to give you a newbie account of that.

I have a bare concept of how it works, I'm just not sure why an app as popular as mediainfo would not support it, and what would be required to add support to an application.

VBV is a buffering model. Put simply, there is a buffer of a specific size (vbv_bufsize) and that buffer is filled at a specific maximum data rate (vbv_maxrate).

An encoder is "vbv aware", if it ensures that the buffer will never underflow. It means that the encoder makes sure that there will always be enough data left in the buffer for the decoder to decode the next frame.

However it does not do more than that. So you cannot calculate the "average bitrate" for arbitrarily defined intervals and expect that the result will remain below an arbitrarily defined threshold.

(Instead you will need to use a VBV verification tool. And even that can only work, if you setup the same VBV parameters that had been used by the encoder)


Aye, I understand how it works, I just didn't get how it played in to things. The more I think about it, the more it makes sense. Basically I don't need to worry about spikes if the buffer is set correctly, right?

[LoRd_MuldeR]

I have a bare concept of how it works, I'm just not sure why an app as popular as mediainfo would not support it, and what would be required to add support to an application.

...because VBV verification requires "emulating" a decoder, process the complete stream, frame-by-frame, like a real decoder would, and keep track of the buffer filling level.

At the same time, calculating the "average bitrate" is much easier. For example we can take the size of the whole file (video data only) and divide it through the duration (in seconds). Done ;)

Furthermore a VBV verification always requires that you set a vbv_bufsize plus a vbv_maxrate. And the result will only be valid for exactly those VBV parameters...

Aye, I understand how it works, I just didn't get how it played in to things. The more I think about it, the more it makes sense. Basically I don't need to worry about spikes if the buffer is set correctly, right?

Bitrate "spikes" are okay, as long as the buffer doesn't run out of data. And that's exactly what a "VBV aware" encoder will take care of.

For example, after a number of "small" frames enough data may have accumulated in the buffer to have a number of "large" frames next - without getting an underflow.

From the VBV point of view, this is fine. But if you only look at the "average bitrate" for, e.g., 1 second intervals, you might see a significant fluctuation...

[Incendia]

...because VBV verification requires "emulating" a decoder, process the complete stream, frame-by-frame, like a real decoder would, and keep track of the buffer filling level.

At the same time, calculating the "average bitrate" is much easier. For example we can take the size of the whole file (video data only) and divide it through the duration (in seconds). Done ;)

Furthermore a VBV verification always requires that you set a vbv_bufsize plus a vbv_maxrate. And the result will only be valid for exactly those VBV parameters...



Bitrate "spikes" are okay, as long as the buffer doesn't run out of data. And that's exactly what a "VBV aware" encoder will take care of.

For example, after a number of "small" frames enough data may have accumulated in the buffer to have a number of "large" frames next - without getting an underflow.

From the VBV point of view, this is fine. But if you only look at the "average bitrate" for, e.g., 1 second intervals, you might see a significant fluctuation...

I see, I'm just trying to figure out the most bandwidth-stable way to serve data. Net connections seem to have problems with VBR moving from low bitrate -> high bitrate, and streams are more "stable" from a viewer standpoint using CBR all-round ( Even though vbr is more bandwidth conservative during downtime, which is important in this age of ridiculous data caps ). Couldn't figure out why I was getting spikes in my "CBR" though :p

[benwaggoner]

I see, I'm just trying to figure out the most bandwidth-stable way to serve data. Net connections seem to have problems with VBR moving from low bitrate -> high bitrate, and streams are more "stable" from a viewer standpoint using CBR all-round ( Even though vbr is more bandwidth conservative during downtime, which is important in this age of ridiculous data caps ). Couldn't figure out why I was getting spikes in my "CBR" though :p
In the net streaming case, you can also think of buffer in terms of time: "in no period x of seconds may the bitrate exceed y." A peak bitrate of 2000 with a VBV of 10000 would mean that no 5 second chunk of your file would have an average bitrate above 2000. However, a 1 second chunk could have an average bitrate of 8000 if the bitrate 2 seconds before and after that chunk are below 500 Kbps.

The right buffer size varies with networking type, with smaller VBVs correlating with faster worst-case startup and random access times. I wind up in the range of 1-5 seconds for the vast bulk of projects I work on.

Also, note that MediaInfo doesn't actually do any stream analysis of files. It just reports the metadata in the elementary streams and container format. It's incredibly useful, but it can't know anything the encoder didn't tell it.

[LoRd_MuldeR]

I see, I'm just trying to figure out the most bandwidth-stable way to serve data. Net connections seem to have problems with VBR moving from low bitrate -> high bitrate, and streams are more "stable" from a viewer standpoint using CBR all-round ( Even though vbr is more bandwidth conservative during downtime, which is important in this age of ridiculous data caps ). Couldn't figure out why I was getting spikes in my "CBR" though :p

You don't care about how much the video bitrate fluctuates. You do care about "smooth" playback. That is: You don't want that the playbacks gets interrupted, because the player needs to "buffer".

If the player interrupts playback for "buffering" (i.e. giving the buffer some time to recover), this means nothing else but that the player just encountered a buffer underflow!

Consequently you have to set the "vbv_maxrate" to the available/guaranteed network bandwidth and the "vbv_bufsize" to size of the buffer used by the playback software (on client machine). And that's it!

Note that the data always flows into the buffer at the maximum possible rate, as defined by the network bandwidth. What fluctuates is that rate at which the data is taken from the buffer, by the decoder.

(Of course in reality the network bandwidth may also have some fluctuations, due to congestion, so the "vbv_maxrate" should be chosen conservatively)

[Sn8kbordin]

So if my WiFi G network can really support 2MB/s max in reality, I should set VBV Max bitrate to 15000 and leave VBV size at 31250 (right now both are set at 31250)?

[Blue_MiSfit]

That sounds like a reasonable plan, assuming you're okay with a ~ 2 second buffer period. I'd imagine this is fine.

You might even consider bringing video maxrate down to 12000 or so, to give yourself some breathing room. I always like to pad things by 20% whenever possible.