Flash Encoding: VBR or CBR? It depends.

icon_flashencoder.gificon_squeeze.gif

It’s been a few years now since the battle over which video format would dominate the web. It’s hard to argue that over the last few years Flash is by far the clear winner. From entertainment sites like YouTube to news organizations like CNN, when you watch video changes are it’s Flash encoded.

I would argue that as far as quality, bit rates and file sizes go, Flash is not the best choice out there. But its cross platform ubiquity is unquestionable.

This post is not going to get into all of the ins and outs of Flash, but I want to discuss one point. VBR (variable bit rate) and CBR (constant bit rate) encoding.

For those who don’t already know, a CBR encode simply applies the same number of bits to each frame of video, regardless of the material being encoded. The data rate is setup at the start and is applied throughout the encode. What you end up with is a very predictable file size and a very steady, predictable stream of data when playing back the file.

With VBR you also set a data rate at the beginning of the encode, but instead of applying that amount to each frame of video, frames are analyzed to determine how many bits are really needed to recreate the image. The bitrate is actually averaged over the frames, sometimes going lower and sometimes higher then the number you have set.

For example, a talking head over a static background would require less compression then a busy city street full of traffic and people. In the first example, much of the screen from frame to frame stays the same, while in the second example virtually every pixel on the frame will change. What VBR does is apply more data to the frames that need it, and less to frames that can get by with less. As a result, you end up with a very good picture, and with a smaller file size. Sometimes, a significantly smaller file, depending on the material. I recently encoded an 80 minute video in both VBR and CBR for a client. THe CBR file was 267 megs, and the VBR was 169. This is a huge deal when you’re paying for server bandwidth!

I should mention at this point that not every compression program will offer both CBR and VBR, and on some programs it actually costs extra. For example, Sorenson Squeeze includes CBR compression for encoding into the On2 VP6 Codec, but if you want VBR it’s an extra $100.

So you might be wondering why you would ever want to use CBR if VBR creates a better image and smaller file size. Well for one, CBR is a much faster way to encode. Because each frameĀ  does not need to be analyzed, it can take half as long. So if time is an issue, CBR might be the answer. Especially if you’re talking about doing on-line approvals for a job and quality is not as important as having it to the client on time.

There is another reason to consider CBR. Streaming.

If you are encoding files that will be handed off to a client to be used elsewhere (as opposed to creating the files for your own use or site) one question you should always ask is how the files will be used. If they are for the web, they can be streamed using a Flash streaming server, or hosted as a progressive download over a typical http server. Which one is being used affects how you should encode the file.

When a file is being hosted by a streaming server, there is a set bandwidth for the streaming pipe. For example, a service may guarantee that a 500 mbit stream will play without any pausing because they dedicate 500 mbits to each client accessing the file. So with a CBR file, things work well. The server provides the proper bandwidth, and the file stays within that limit. But with VBR, the rate is not constant. And not only does the rate drop when fewer bits can be used, but it can spike to higher then what the dedicated pipe was expecting. The end result is very jerky playback that’s nearly impossible to watch, especially in busy areas of the video.

So the most important thing to take away here is to always ask what the file is being used for. Never make an assumption that even your client knows, often they are just relaying what they were told. Whenever I’m asked for any type of compressed file (Flash or anything else), I always ask how they will be using it, not what technical specs they want. The answer might be PowerPoint, web, CD, laptop playback, or anything in-between. I have found that nearly half the time asking this question (and sometimes several follow up questions) changes what I deliver, and in most cases avoids having to do it over a second time.

Asking pertinent questions is the most important thing you can do for yourself, as well as your client.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.