Blog

In a recent project we here at Sundog got a chance to work on, we got the chance to flex our video streaming muscle, and we hit a rather odd bug.  As the video played it progressively got worse and worse until it barely intelligible.  This had me perplexed for a number of weeks until we found the culprit: Variable Bit Rate encoding. 

First a few terms defined:
Streaming is one of two ways to deliver video online.  The other is progressive download.  The difference is slight, but to end-user, streaming eliminates the initial wait for video to begin, and it has the ability to dynamically change the quality of the video to suit your connection speed.  So users on high-speed cable or T1 connections will get the highest quality delivered while the someone on a low-end DSL or wireless connection would get an accordingly smaller video delivered.  This method of having multiple versions of a streamed video is called dynamic streaming. 

Variable Bit Rate encoding (VBR) is also one of two different options when it comes to delivering video online.  When you ready a video for online delivery, you must first decide the type of user you want to deliver to, and their connection speed will define the amount of data you can allot to each second of video, which is the bitrate.  This number is measured in kbps or kilobytes per second.  With Constant Bit Rate encoding (CBR) , that’s all there is to it, but with VBR we take a few liberties.  VBR lets you define the core bitrate, as with CBR, but you also define the wiggle room.  VBR encoding will measure the video, and allot more data for seconds with more dynamic frames.  This allows for the less dynamic areas to be encoded with less data, and the more dynamic areas to have higher image quality. 

VBR seems like the obvious choice.  Approximately the same size video, with the data used more “intelligently.”  The problem comes when you combine it with dynamically streaming video delivery.  Streaming doesn’t buffer in the same way that progress download does.  Streaming only holds on to the next few seconds of video.  What we found in our most recent project is that each period with more dynamic video and more data per second essentially tricks the video player to thing its connection speed was insufficient. 

It happens like this…  When your user initially connects, their connection speed is detected.  Based on that, it will serve up the appropriate sized video from our set of different quality renders.  Let’s say our user is at home, on his blazing new cable connection, so he gets a big nice crystal clear 2000 kbps version of the video.  With CBR the video would remain at 2000 kbps throughout, but in VBR world it may actually start at 1800 kbps and go all the way up to 2200 kbps.  As a more dynamic section approaches,  the data stream gets a little fatter (think a mouse in a snake).  So now your video player realizes that it no longer has as much of buffer as it did before.  Originally 5 seconds of video was 9000 kb, but now the same amount of data only allows it to have ~4 seconds.  To be sure that the video can keep playing, the video player compensates the only way it can, by lowering the version of video it’s streaming.  Each time it hits another dynamic area, it can happen again, slowly stair-stepping down to lesser and lesser versions of the video. 

Now, if the video player is smart enough to step-down every time there’s a problem, can’t it step-up every time the high-data section passes?  Well it can.  Given enough time at the lower density area your dynamic streaming video should try to increase the quality again.  Keep it mind it takes a bit to buffer 3-5 seconds of additional video at the same time as you’re streaming your active video, so you’re going to wait a bit (in my experience, about 8 seconds) 

However, there’s a more important reason not to do it this way.  What we’ve just described is kludge way to dynamically create a CBR video.  So, while the user wasn’t able to take the 2000 kbps stream when it went up to 2200 kbps, he was downgraded to a 1600 kbps stream that was concurrently inflated to 1800 kbps. 

All-in-all, save Variable Bit Rate encoding for progressive download, where the buffering can handle it.  Or better yet, don’t make your user wait, and dynamically stream with Constant Bit Rate encoding.