<p>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.</p>

<p>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.)</p>

<p>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.)</p>

<p>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.  :)</p>

<p>A random google hit on x264 vbv for streaming:
<a href="http://forum.doom9.org/showthread.php?t=147460" rel="nofollow">http://forum.doom9.org/showthread.php?t=147460</a></p>

<p>An example from <code>x264 --fullhelp</code>:</p>

<pre><code>  Constant bitrate at 1000kbps with a 2 second-buffer:
        x264 --vbv-bufsize 2000 --bitrate 1000 -o &lt;output&gt; &lt;input&gt;
</code></pre>

<p>(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.)</p>

<p>edit: <a href="https://mailman.videolan.org/pipermail/x264-devel/2010-February/006945.html" rel="nofollow">recommended usage</a> for streaming, according to the x264 lead developer (Jason Garrett-Glaser), is quality target (CRF) mode with VBV-constrained bitrate.  e.g.</p>

<pre><code>x264 --vbv-bufsize 2000 --vbv-maxrate 1000 --crf 22 -preset slower -o &lt;output&gt; &lt;input&gt;
</code></pre>

<p><code>vbv-maxrate</code> is the max speed the buffer can fill at.  (i.e. the max network bandwidth).  <code>vbv-bufsize</code> is of course the size of the buffer, which allows for non-sustained bitrate peaks higher than <code>vbv-maxrate</code>.  </p>

<p>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 <code>--preset veryslow</code>.</p>

CC BY-SA 3.0
2015-02-25T21:05:11.900Z
As you say, players buffer streams. So what happens when the buffer runs out? Why the playback stutters and pauses of course!

Take your example quoted above. Imagine that a user gets a solid 1200kbit/sec connection to my service. Imagine that user is watching a stream that requires about 1000kbit/sec for the first five minutes. Great! But now if that file is VBR (note their example isn’t) your file might suddenly require 2500kbit/sec for the next five minutes. Your 2 sec buffer runs out pretty quickly and the viewer can basically no longer watch the video.
grovberg
CC BY-SA 3.0
2015-02-25T23:44:18.327Z
The whole point of telling the encoder the buffer size is so it can take that into account for rate-control, to make sure it doesn't underflow the buffer.  x264 will always warn you if it couldn't meet your VBV requirements.  (e.g. extremely low bitrate for HD, and it couldn't get there even by blurring everything to crap.)
Peter Cordes
CC BY-SA 3.0
2015-02-26T03:36:05.330Z
I think what the stuff you've found so far didn't explain is that VBR doesn't have to mean pure quality-target-only VBR.  Modern audio and video encoders now support constrained-VBR ratecontrol, where overall and local bitrate limits are obeyed, too.  But they're otherwise free to spend bits where needed to get as much quality for the whole clip as possible.  You're right that there's an issue here that needs to be accounted for, and `--vbv-buffsize` is how it's done.
Peter Cordes
CC BY-SA 3.0
2015-02-26T03:58:52.483Z
edit: updated my answer after googling again.  `vbv-maxrate` is the buffer-fill rate, not decoder-CPU-limited decode peak.  And CRF + VBV is the recommended way to go for online (realtime) or offline encoding of video for streaming.
Peter Cordes
CC BY-SA 3.0
2015-02-25T05:12:14.130Z
2015-02-26T03:56:41.820Z
2015-02-26T03:56:41.820Z
Peter Cordes
<p>I'm building presets for our users to convert the videos into an appropriate format for our online video repository. Since it's been awhile since I've built something like this from scratch, I've been looking at what others recommend, and notice that a lot of them specifically recommend variable bitrate encoding. For example:</p>

<p><a href="https://support.google.com/youtube/answer/1722171?hl=en" rel="nofollow">https://support.google.com/youtube/answer/1722171?hl=en</a></p>

<p>Even with progressive or pseudo-streaming, wouldn't that just introduce pausing and stuttering in playback once you hit a segment with a high bitrate? It just seems odd as a general recommendation when that's likely to create a poor playback experience. Or am I just overestimating the problems since it's been some years since I last looked into it. Do you generally use a variable bitrate for online delivery these days?</p>

CC BY-SA 3.0
2015-02-24T21:24:55.563Z
I think you misunderstand what variable bitrate encoding does. It doesn't introduce stuttering or pausing.
Dr Mayhem
CC BY-SA 3.0
2015-02-25T05:14:02.850Z
IDK who downvoted this.  It's not a bad question, IMO, just a complete-beginner question.
Peter Cordes
CC BY-SA 3.0
2015-02-25T05:16:04.367Z
Oh, also note that your link is for how to make videos to UPLOAD to youtube, for them to transcode before streaming them.  That encode once, decode once, with no realtime constraint, use case is completely different from hosting videos for people to stream.  For uploading to youtube, you want to use lots of bitrate, and if you have the upload bandwidth, encode time is of similar value to resulting filesize.  So you might use `x264 --crf 16 --preset fast`.
Peter Cordes
CC BY-SA 3.0
2015-02-25T21:01:00.113Z
I'm not misunderstanding, nor am I a beginner (built my first streaming video service in 1997 actually). I'll reply to the rest in your answer there but to clarify—the link was just one example of a recommendation I'm seeing everywhere. Based your answers it seems that everyone just assumes the pipes and buffers are big enough to compensate for spikes in bitrates these days.
grovberg
<encoding><webvideos>
Variable Bitrates for Streaming?
grovberg
# Variable Bitrates for Streaming?

(Asked by: username_0 on 2015-02-24)

I'm building presets for our users to convert the videos into an appropriate format for our online video repository. Since it's been awhile since I've built something like this from scratch, I've been looking at what others recommend, and notice that a lot of them specifically recommend variable bitrate encoding. For example:

<https://support.google.com/youtube/answer/1722171?hl=en>

Even with progressive or pseudo-streaming, wouldn't that just introduce pausing and stuttering in playback once you hit a segment with a high bitrate? It just seems odd as a general recommendation when that's likely to create a poor playback experience. Or am I just overestimating the problems since it's been some years since I last looked into it. Do you generally use a variable bitrate for online delivery these days?

**Tags:** encoding, webvideos

> **Comments:**
> **username_1**: I think you misunderstand what variable bitrate encoding does. It doesn't introduce stuttering or pausing.  
> **username_2**: IDK who downvoted this.  It's not a bad question, IMO, just a complete-beginner question.  
> **username_2**: Oh, also note that your link is for how to make videos to UPLOAD to youtube, for them to transcode before streaming them.  That encode once, decode once, with no realtime constraint, use case is completely different from hosting videos for people to stream.  For uploading to youtube, you want to use lots of bitrate, and if you have the upload bandwidth, encode time is of similar value to resulting filesize.  So you might use `x264 --crf 16 --preset fast`.  
> **username_0**: I'm not misunderstanding, nor am I a beginner (built my first streaming video service in 1997 actually). I'll reply to the rest in your answer there but to clarify—the link was just one example of a recommendation I'm seeing everywhere. Based your answers it seems that everyone just assumes the pipes and buffers are big enough to compensate for spikes in bitrates these days.  

---

## 1 answers

### Answer by username_2 on 2015-02-25. Score: 4

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:
http://forum.doom9.org/showthread.php?t=147460
An example from x264 --fullhelp:
  Constant bitrate at 1000kbps with a 2 second-buffer:
        x264 --vbv-bufsize 2000 --bitrate 1000 -o  

(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  

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 vbv-maxrate.  
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 --preset veryslow.

> **Comments:**
> **username_0**: As you say, players buffer streams. So what happens when the buffer runs out? Why the playback stutters and pauses of course!  Take your example quoted above. Imagine that a user gets a solid 1200kbit/sec connection to my service. Imagine that user is watching a stream that requires about 1000kbit/sec for the first five minutes. Great! But now if that file is VBR (note their example isn’t) your file might suddenly require 2500kbit/sec for the next five minutes. Your 2 sec buffer runs out pretty quickly and the viewer can basically no longer watch the video.  
> **username_2**: The whole point of telling the encoder the buffer size is so it can take that into account for rate-control, to make sure it doesn't underflow the buffer.  x264 will always warn you if it couldn't meet your VBV requirements.  (e.g. extremely low bitrate for HD, and it couldn't get there even by blurring everything to crap.)  
> **username_2**: I think what the stuff you've found so far didn't explain is that VBR doesn't have to mean pure quality-target-only VBR.  Modern audio and video encoders now support constrained-VBR ratecontrol, where overall and local bitrate limits are obeyed, too.  But they're otherwise free to spend bits where needed to get as much quality for the whole clip as possible.  You're right that there's an issue here that needs to be accounted for, and `--vbv-buffsize` is how it's done.  
> **username_2**: edit: updated my answer after googling again.  `vbv-maxrate` is the buffer-fill rate, not decoder-CPU-limited decode peak.  And CRF + VBV is the recommended way to go for online (realtime) or offline encoding of video for streaming.  

---

