Players buffer streams. The bigger the buffer size, the longer window the encoder has to use higher bitrates for hard content, and then fewer bits earlier or later on easy content, to achieve similar quality for the whole video.
I'll assume you're going to use h.264 (aka AVC) as a codec, as it's the de-facto standard for streaming video on the Internet. VP8 is not as good quality. VP9 can look better than h.264, but support is limited. HEVC (h.265) is also better than h.264, but again player support is limited. (And hardware decode acceleration won't be widespread for years. This matters, because HEVC is very cpu-intensive to decode, more than AVC.)
The quality comparisons I'm talking about are with the best available encoders for each codec. x264 for AVC, Google's VPx for VP8/VP9, and x265 for HEVC. All with settings cranked up nearly all the way. x265 will start to get into seconds-per-frame instead of frames-per-second for 1080p with settings that slow, though. (x264 orders of magnitude faster, since it's been essentially mature for a couple years now, with few new speedups or quality gains being found.)
All these encoders are free open-source software. It's nice that you don't have to pay anything to get world-class quality codecs these days. :)
A random google hit on x264 vbv for streaming:
An example from
Constant bitrate at 1000kbps with a 2 second-buffer:
x264 --vbv-bufsize 2000 --bitrate 1000 -o <output> <input>
(don't actually use one-pass target-bitrate mode, though. Either 2pass if you have a specific target bitrate, or crf with a target quality.)
edit: recommended usage for streaming, according to the x264 lead developer (Jason Garrett-Glaser), is quality target (CRF) mode with VBV-constrained bitrate. e.g.
x264 --vbv-bufsize 2000 --vbv-maxrate 1000 --crf 22 -preset slower -o <output> <input>
vbv-maxrate is the max speed the buffer can fill at. (i.e. the max network bandwidth).
vbv-bufsize is of course the size of the buffer, which allows for non-sustained bitrate peaks higher than
And of course, if you're encoding once to create a file which will be streamed many times, throw as much CPU time at it as you can. Encode time is of little importance compared to getting the most quality per bitrate (rate-distortion tradeoff, aka RD). The encode only happens once, and any bits you can save (while maintaining the same quality) are saved for every download. e.g. Use x264 with