Video Bitrate | What bitrate should I Use?

Since my posting on Video Resolution, I’ve had requests for similar information on Video Bitrates.  Your wish (up to a reasonable point) is my command.  This is for beginners, and many of you may already have all this in your heads.  Lucky you!

Bitrate – What is it?

Bitrate = the number of bits per second put into the video/audio information, therefore the number of bits that will need to run through the interwebs while your video is playing.

The bitrate is commonly expressed in Kbps (Kilo-bits per second).  Video and audio files are commonly labeled “client_content_300K.mp4” or just “300.mp4.”  The bitrate is one of the four “defining characteristics” of online video:  length, format, resolution and bitrate.  If you know those four, you usually know as much as you need to use the video online.

bits, Bytes and Filesize

Note the small “b” for bits.  It is not “B” for bytes.  Bitrate and bandwidth have been expressed in bits and Kbits since the earliest days of the internet, mostly because of the tiny bandwidth available.  It was much easier to talk about a 14.4K modem than to discuss a .01406KB modem.

Filesize is defined in Bytes:  KB, MB and GB.  A byte is eight bits.  You can work out the file size from the length and bitrate of a video.  Our 300K bitrate above would produce a file that was 37.5KB per second.  If our file were 1.1MB, we would know that it was ~30 seconds long.  I’ll let you play with the math form there.

A Word from the Eminence Grise

Back when I started in video we only worried about two bitrates, because we were only worried about two device types.  There were 28.8K modems and there were 56K modems.  We had to leave out some overhead, so we encoded to 22Kbs and 45Kbs.  This was the time of “Postage Stamp” video at 96×72 and 128×96 pixels.

With the arrival of T-1 and DSL we could stretch out a bit, but the growth of bandwidth never was fast enough for us, and it still isn’t fast enough today.  Clients and encoders are ready to stream 1080p, but the pipes just aren’t big enough.

Which brings us to the golden file of the Golden Age of Web Video:  320×240 at 300kbs.

320×240 @ 300K and Beyond

This was the perfect ratio of Resolution and Bitrate back in the year 2000.  From this ratio, we’ve been figuring out bitrates for larger and larger files for the last eight years.  So, here we answer the main question that I hear every week:  what bitrate should I use for this video.

First we drop out the audio.  It doesn’t count for much and it really comes down to 64K is good and 128k is better.  In this case we’ll assume 64K.  That leaves 236K of encoding power for the video.  If you encode at the above specs, and the video looks good, you can use that as a formula for larger resolutions.

“So, what bitrate should I use for my 640×360 video?”  Start with 320×240 pixels = 76,800 pixels.  That number of pixels looks good when using 236Kbs.  Your desired resolution is 640×360* or 230,400 pixels.  Time for some math:

76,800/230,400 = 236/x   or  236*230,400/76,800 = 708Kbs

*note that this is resolution independent – it doesn’t matter if your video is 4:3 or 16:9

So ~708Kbs for encoding video at 640×360.  Add the audio, still at 64K and we get 772Kbs total bitrate for the file.  You’ll probably want to round down or up so your files can be nicely labeled as “client_content_640x360_750.mp4” or something similar.

But Codecs Have Improved

They certainly have, and sometimes formulas from long ago give very big numbers.  It would be hard to suggest to a client that they go much over 1500k, but they want to stream 720p (1280×720) video.  Our formula puts that at ~3000K!  At that point, you’re going to have to bring it down.  That means create a file at 720p and 3000K, using the best settings you can achieve for your codec; determine that the file looks great, then start testing down.  Most modern codecs will give great results as you go down to 2000K and go under 2000K.  Find your sweet spot.

Summing up

  • Bitrate is the number of bits used to encode or used to stream a video
  • A preliminary bitrate can be determined using a ratio of pixels to bitrate
  • Using modern codecs you can take the bitrate down as the resolution goes higher

I hope this is helpful to someone out there.  Enjoy!

I am available to consult on any Web Video Encoding issues:  wcaulfield@metroencoding.com

Free to Metro Encoding clients

Video Resolution – Mistakes Were Made

The Most Important Thing

Width and height.  Simple, yet so important.  NTSC, PAL, D1, HD; all defined by resolution.  In pre-web days, or in early web days (anyone else use Mosaic?) it was not much of an issue.  An editor brought the video in, edited it and laid it back to tape  (on a side note, does anyone want to buy a Sony BVH-2000 cheap?).  Our editor may know that the video is 720×480 or he may not.  Since it’s always the same resolution throughout the process, it doesn’t really matter to him.

Skip ahead to web video.  Now the video needs a smaller resolution and our editor has a lot to learn.  CIF, QCIF, 320×240 or 128×96(!).  Most of them never did learn, and most people dealing with video still don’t have a grip on the concept.

Video Is Not 720 Pixels Wide

  • The largest online retailer in the world recently sent me specs for placing video on their site. They suggested a width of 720 pixels.  They got it wrong.
  • A major film studio recently contacted me, asking why a trailer was “squished.”  A designer had encoded the video to 720×270.  He got it wrong.

There’s one thing that you should know.  Standard Definition Video, in the real world, is not 720 pixels wide.  If you are about to put video on your site at 720×480 or 720×360, stop now.  Yes, D1 NTSC resolution is 720×480 on the tape and in your editing system and on your DVD, but…it is meant to be played back at 640×480.  This is the standard 4:3 resolution of your analog television set.  If the video is letterboxed to 16:9, it should be played back at 640×360.

*There is only one NTSC exception to this:  anamorphic video.  In most cases this will be a 16:9 video fitting the entire 720×480 frame.  Anamorphic video of this sort can be resized to to 720×404 or played back at 852×480.

In the first case above, they assumed that 720 was the standard width of video.  They did not realize that most video will have to be stretched in some direction to meet their specs.  720×480 would be stretched to 720×540.  720×360 (after stripping out the letterboxing) would be stretched to 720×404.

In the second case, the designer simply took a 720×480 trailer, stripped out the 2.35 Widescreen letterboxing and encoded.  The files looked fine at 640×270.

Video Resolutions Are Always Even (at least)

Video compression works geometrically.  The early codecs, MPEG-1 and MPEG-2 worked on a 16×16 basis.  The best resolutions used a width and height divisible by 16.  720×480, 320×240, 512×384 and etc.  Later, usable resolutions expanded to include resolutions divisible by eight and four.

Today, one can only ask for even.

  • I was recently asked by a major online site for FLVs at 400×277 and 130×89.  They got it wrong.
  • The major media company in the world asks for FLV at 364×205.  They got it wrong.

How did they get it wrong.  They may have understood that video should be 4:3 or 16:9 or 2.35:1.  They then chose their width and tried to figure out the correct height.  In the second case, that would be 364*9/16=204.75.  Their mistake was rounding up to an odd integer.  The correct move would be to round down to 204, conveniently divisible by 4.

In the first case, they are all over the map.  400 width in a 16:9 should have gotten them 400×225, easily rounded down to 224 (beautifully divisible by 16).

Wrapping Up

Hopefully this information will be helpful for Designers and Execs trying to make decisions about their online video.  Summing up:

  • The largest 4:3 online resolution available from NTSC is 640×480.  The largest 16:9 resolution available from letterboxed NTSC is 640×360.  Anything larger is a stretch (literally).
  • All online video resolutions should be (at a minimum) even in width and height.  Divisible by 4, 8 or 16 is better and better.

I am available for consultation on these issues:

wcaulfield@metroencoding.com

No charge to clients of Metro Encoding.

Why I Hate QuickTime (at this moment)

It’s The Hinting

Alright, that’s a bit extreme.  I hate Streaming QuickTime.  More specifically, I hate “hinting” files for a QuickTime streaming server.  QuickTime, or Apple, has left their streaming capabilities to die.  At the same time they have never completely embraced H264.  This combination of oversights has caused myriad headaches for me over the last year.

For anyone who doesn’t know, a “hinted” QuickTime file has a set of instructions at the head that the Server needs to stream the file.  Slightly more information here:

Hint Tracks

This all used to make sense back in the day.  You encoded a file in Sorenson 3 Pro, encoded the audio in QDesign Pro and the Encoding Software (Cleaner usually) hinted the file.  The QuickTime Server needed the hints to stream the file.  It couldn’t just be flattened, it had to be hinted.

At the same time, any Real or Windows Media file could stream from their respective servers.  No special “tracks” needed, no extra hassles.  QuickTime was, however, the big dog of the pack.  Clients wanted to stream QuickTime and there was no issue as long as it was easy to hint the files.

Enter H264

QuickTime was the first of the Formats to embrace H264.  Well…not so much embrace as “stick their toe in the water.”  They first included support for H264 baseline.  Later they moved up to Main Profile and even limited B frame support.  They also came out with an H264 encoder of quite limited scope.  And that’s where they stopped.

Meanwhile (within the last year) Adobe Flash and Silverlight have given over to H264, accepting the full profile for streaming and download playback.  They’re looking to the future and the future looks like H264.

Over the last few years many vendors have come out with H264 codecs.  At my fingertips (so to speak) I have Ateme, Main Concept, Nero, Sorenson and Apple H264 codecs.  Those first three are extremely powerful and configurable.  They’ve all been through the usual “shoot outs” and had a few years to show their strengths and weaknesses.

So What’s The Beef

Anyone starting to use Web Video today would probably not even consider QuickTime.  It’s only useful for editing in Final Cut and serving to iPhones.  Flash has taken over the world.  Microsoft is planning a coup with Silverlight.

But most of my clients have been with me since the Sorenson 3/QDesign days.  Their content is on huge CDNs and they’ve always streamed QuickTime.  Keeping up with the times, I’ve supplied H264 QuickTimes to them.  This all worked well at the beginning.  Some encoding software even licensed QuickTime to produce reasonable quality in a hinted H264 MOV.

But that was four or so years ago.  The QuickTime H264 codec has fallen to the rear.  I would prefer to use any of the others, and I do.  Leaving me with the final problem.

Hinting H264

Here are three embedded videos: Flash Trailer | Silverlight Trailer | QuickTime Trailer

You’ll need Flash 10, Silverlight 3 and QuickTime 7 to see them all.  The only interesting thing about them is (apart from the fact that this is a great movie!) that all of them are the same MP4 file.  It was encoded using Main Concept; 2 pass, main profile, B frames.

Even though this file will play in the QuickTime Player and Plugin, and even though it falls within the QuickTime spec for H264; it will not hint or even flatten.  My clients want this as an MOV.  Nothing else will do, forcing me to use a weaker codec with neutered settings in order to produce a file that is acceptable to QuickTime.

Solutions

I see three possible solutions to my headaches:

  • QuickTime updates their Streaming and loses the “hinting”
  • QuickTime opens up to the full capabilities of H264
  • My clients go over to Flash and/or Silverlight

I’ll leave you to decide which is more likely.

Speak to Me

OK, I don’t really hate QuickTime.  Just being sensationalistic!  I assume that many reading this are smarter than me.  If you have a good solution for hinting H264 as an MOV please let me know.  I’m always open to new ideas.