What bitrate should I use when encoding my video?
How do I optimize my video for the web?
Derek Stanley
In this article we will go over some recommendations for compressing your videos for delivery through the Amazon S3 servers.
A scenario you might be familiar with is that you have filmed and edited your content into a package that meets your needs, but once you go to view your video on your website it takes forever to load or the video stutters during playback. This problem is not necessarily a bad encoding, but it could be the result of not encoding your video to a targeted connection speed.
In an ideal world you would be able to load your uncompressed video directly onto the web and end users would be able to view the file. Unfortunately, the quantity of data present along with the bandwidth limitations of your clients, makes this an impossibility at this point in time.
To reduce the data being pushed through your video you will have to perform a compression using a codec, which was covered in our previous article here:
My video has no sound or picture, am I using the right codec? What is a codec anyway?
Which Container and Codec Should I Use?
As previously mentioned in the article linked above the container is simply a way of packaging together the audio and video stream while delineating how they are compressed.
When choosing between the MP4, MOV, FLV, WMV and AVI containers, MP4 is the best option. The complexity of the MOV container can cause devices to stall when playing video. The FLV container is only supported by the Flash plugin, which is not supported by the new HTML5 standard and Apple mobile devices such as the iPhone. The WMV container requires specialized plugins and is generally only supported by Microsoft products such the Zune, or Silverlight. The AVI container is not meant for web distribution, as it is targeted at desktop players (it is also not supported for web playback through our own players, but it is listed here to clear any confusion on the container).
The MP4 container is almost universally supported: Apple, Microsoft, Flash, and HTML5 all offer support for MP4 (there are some outliers). On top of that MP4 can use the H.264 video codec and the AAC audio codec, compatibility wise they are the best choices for compressing your video. H.264 video is supported by just about any player, browser, plugin and device available. It also offers one of the best algorithms for compressing your video on top of being freely available.
How Exactly Do You Encode For A Targeted Connection Speed?
File size is probably the first idea that pops in your head, but you shouldn’t be thinking so much about the file size as the overall bitrate. As long as the viewer’s connection can keep up with the file’s bitrate, it will stream (progressive download or streaming) without stuttering.
File size = bitrate (kilobits per second) x duration
Bitrate is a measurement of the number of bits that are transmitted over a set length of time. Your overall bitrate is a combination of your video stream and audio stream in your file with the majority coming from your video stream.
A simplified analogy is to think about how water is pumped out of a well and how long it will take for water to travel from the well to a faucet. No matter how powerful the pump there will always be a delay because the water has to travel through the pipes connected to the faucet. Your video is the water, while the pump represent the speed of the Amazon s3 server. The connection speed of your end user is the diameter of the pipe. The length of the pipes can be thought as the distance from the server. The pipe is going to bottleneck the water increasing the time it will take to get out the other side. In essence, that is the major problem you face with the streaming of videos online, you have to account for the delay.
If you know the average connection speed of your clients you can set your overall bitrate to be under their download speed to achieve a streaming playback. You should encode at a bitrate below their connection speed because this will help to take into account miscellaneous ambient traffic, distance from the server, and other elements loading into the same webpage.
For example, taking the US broadband average of 3.9 Mbps (as of January 2010) you would probably want to encode somewhere between 2,000 and 3,000 Kbps. (1 Megabit equals 1,000 Kilobits most encoders measure bitrate in Kilobits). What this means is that every second of the video there is 2,000 kilobits required before that second can be displayed. Converting bits to bytes (8 bits equals 1 byte) you can see this is 250 kilobytes a second or 15 megabytes per minute.
Depending on the codec in use and the container this can be a very limiting number. The problem is further extended if you have varying connection speeds across your user base, which is most often the case. If you are only serving one version of your video, you will find yourself pandering to the lowest common denominator. AT&T for example (In the US) guarantees only a download speed up to 1.5Mbps with their starting DSL package.
Cutting Back On The Video Stream
If you have your target bitrate, but are having trouble achieving an acceptable quality video, you will have to cut back in some aspect. The contributing factors that will lead to a higher video bitrate are the amount of pixels (the resolution of the video), the frame rate, and the amount of motion present. If your video is already filmed there is not much you can do about the motion in the video, but in your planning stages you can think ahead.
1. Resolution
The easiest change can come from lowering the number of pixels displayed by simply lowering the resolution of the file. If you are playing your video in a 320 x 240 player on your website and you do not expect the end user to enlarge the video, then there is no reason to have a file with a higher resolution. Even if your camera records at 1080p, it does not mean you cannot scale down to a smaller size to save on bitrate. Although, it should be noted that you want to maintain the image aspect ratio when resizing. Most videos are filmed in either 16:9 or 4:3, changing this ratio can lead to a squishing or stretching effect that is unsightly.
For better quality to bitrate ratio, also remember to keep your resolution in a value evenly divisible by 16, but do not alter a resolution to make it a multiple of 16 unless you over-crop, which will cause you to lose part of your image. Under-cropping or adding a black border around your image will decrease encoding efficiency. Scaling will just degrade the image.
2. Frame Rate
The frame rate is how many unique consecutive images are displayed per second in the video to give the illusion of movement. The human visual system does not see in terms of frames; it works with a continuous flow of light information. Basically this means that the rate at which a video has the appearance of judder (non-smooth motion) is different based on a person to person basis along with the colors (or color of light or actions) in the video.
Around 24 frames per second, the typical film rate which often gives a “cinematic feel,” is where most video creators land and is also a point that most human eyes are fooled into perceiving motion. This is not a standard of course, if your video is a screen cast you can get to frame rates as low as 5fps. On the other hand, large shifts between a pure white or pure black screens can have a perceivable fault below 30fps and footage of video games can often require 60fps to maintain smoothness. Television standards such as PAL (common in Europe and some parts of Asia) uses 25fps, while NTSC standard (used in the US and Japan) uses 29.97fps. Generally you should never exceed the frame rate of the source video. Obviously, the best results will be achieved if the frame rate is kept the same as your original source.
Unfortunately, to lower the bitrate you may have to choose a lower frame rate. Like most of these settings it is best to play around with the encoding to find a setting that looks best for your video. In order to do that it is advisable to consider the amount of action on screen. “Talking head videos” (a tripod shot recording a person talking at the screen) for example does not require a high frame rate because the motion is most likely subdued. While a video of a skate boarder will require at least 24fps to maintain smoothness. When you lower your frame rate make sure to accomplish it in even increments (such as splitting the amount in half) to avoid de-syncing of the video and audio streams.
3. Constant versus Variable
One option you will notice when you go to encode your videos is a selection for VBR (Variable Bit Rate encoding) or CBR (Constant Bit Rate encoding). As a general rule VBR is for progressive or standard downloads and CBR is for use when using a streaming cloudfront.
VBR allows you to set a maximum and minimum bitrate. The compression algorithm then tries to efficiently compress the data dipping into the minimum bitrate when there is little to no motion on screen and spiking to the maximum defined rate when the motion is prevalent. This helps to give you a smaller overall file size, but the unpredictable spikes in bitrate can choke the playback of streaming videos.
CBR is used when a predictable flat bit rate is needed. The flat bitrate throughout the entire file comes at the price of efficiency for the codec. Usually resulting in a larger file, but smoother playback.
However these rules are not universal. Depending on your video you might want to use a VBR for a streaming playback if the spikes do not exceed your target user’s connection speed. For example if there is only one high motion scene in a video, you will be wasting bandwidth on a constant bitrate throughout the entire file and may better serve your user’s by using a variable bitrate. In any case try experimenting with the two settings to find what works best for your video.
4. Quality versus Streaming
If you are not sure what your target connection speed is and you are not shooting to stream your videos, but do not want an abundant amount of bandwidth cost from Amazon, one method that works really well in determining a good bitrate is the Kush Gauge. To find a decent bitrate simply multiply the target pixel count by the frame rate; then multiply the result by a factor of 1, 2 or 4, depending on the amount of motion in the video; and then multiply that result by 0.07 to get the bit rate in bps. Divide your result by 1,000 to get a kbps estimate or by 1,000,000 to get a Mbps estimate.Kush gauge: pixel count x motion factor x 0.07 ÷ 1000 = bit rate in kbps
(frame width x height = pixel count) and motion factor is 1,2 or 4
Screencast example
For example if your video is a low motion 5fps screen cast in a 1280 x 720 frame size you would have a formula like this:
1280 x 720 = 921,600 pixel count
5 frames per second
1 = Low Motion
(921,600 x 5) x 1 x 0.07 = 322,560 bps / 1000 = 322 kbps bitrate
High action video example
Another example on the other side of the spectrum would be a 24 fps high action shot of an action scene with multiple quick cuts in a 1920 x 1080 frame size:
1920 x 1080 = 2,073,600 pixel count
24 frames per second
4 = High Motion
(2,073,600 x 24) x 4 x 0.07 = 13,934,592 bps / 1000 = 13,934 kbps bitrate
For streaming this example would be a bad idea, unless your target audience lives in South Korea. If you do decide to offer a super high quality file, be sure to also encode a lower quality streaming video for clients that may not have the fastest broadband available.
When using this gauge with a variable bitrate (VBR), 75% of the resulting bitrate can be used for the minimum rate and 150% for the maximum rate.
If you do not want to do the math this bitrate calculator will give you a similar result:
http://www.adobe.com/jp/devnet/flash/apps/flv_bitrate_calculator.html
5. Starting Points
If you are completely lost right now and having trouble deciding what your video bitrate should be here are some starting points for you to experiment with for a streaming connection:
| Output size | Bitrate | Filesize |
| 320×240 pixels | 400 kbps | 3MB / minute |
| 480×270 pixels | 700 kbps | 5MB / minute |
| 1024 x 576 pixels | 1500 kbps | 11MB / minute |
| 1280×720 pixels | 2500 kbps | 19MB / minute |
| 1920×1080 pixels | 4000 kbps | 30MB / minute |
In general though we recommend a bitrate of around 2 – 2.5 Mbps, which takes into account the average worldwide broadband connections. Once again we do however suggest you experiment with different settings and see how they work for you.
6. The Other Side of the Equation
Once you have your video bitrate defined, you will still have to decide how to set the encoding for your audio. Most of the settings are straight forward because they can be copied from your source file, but if your file is slightly above your targeted bitrate you can make some small cutbacks on the audio. Even at extremely low bit rates, reasonable audio quality can be achieved.
First you need to figure out if you are going to encode with Mono or Stereo. If your source video was filmed in mono there is no reason to encode in stereo. You can however reduce a stereo stream to mono and it is generally advisable if the video is a simple speech. Talking head videos are usually good candidates for selecting mono over stereo.
For your sampling frequency it is suggested that you maintain around 44.1 kHz for most of your videos or 22.05 kHZ if once again you are recording only a simple speech. Anything below 22.05 kHz will begin to degrade and distort low volume sounds such as breathing to the point where it is noticeable. While above 44.1 kHz is mainly for audio focused projects.
In the end you will probably be looking at 96 – 164kbps for a stereo music tracks, for the same track in mono, bit rates as low as 56 – 80kbps may still be acceptable. If you are once again dealing with speech only tracks you can probably even get comprehensible sound as low as 16 – 24 kbps.
Parting advice
Overall there is no set guideline as to what your video’s compression should be. Do not expect to find a simple universal number to input. For every video this is a decision based on your client’s connection speed and the quality you want to maintain for your file.
Source: https://www.ezs3.com/public/What_bitrate_should_I_use_when_encoding_my_video_How_do_I_optimize_my_video_for_the_web.cfm
