Squeeze 6 – No, But Yes

After a few weeks testing with Sorenson Squeeze 6, I can say that I will upgrade my licenses.  I can’t say that it’s worth the money charged for an upgrade, and I’m not interested in the new “features.”  They fixed one bug that had made me crazy with the Main Concept H.264 codec.  They’ve zipped up the speed quite a bit.  Basically, when you have multiple licenses of a software and they decide that a bug fix should be a new version, your choices are to upgrade or let it pass and buy into something else.

Granted, I have Anystream Agility, Digital Rapids, Procoder and Flix Pro.  But I’ve put a few years into Squeeze and I still believe that it could be a Professional Level video encoding software in the future.

This is a continuation of my first run of tests for some specific problems:  see previous post to get caught up.

My testing was very specific to what we do, so YMMV.

Testing Runs

  • Source was Norah Jones “Chasing Pirates” downsized from an HDCAM capture.  YUY2 AVI.
  • Profile was three VP6 FLVs, three WM9 and four H.264 Main Concept.  All 2 pass.

The source file was exactly as I wanted it.  I don’t trust cropping, resizing, deinterlacing, inverse-telecine, gamma correction (or anything else you can name) to encoding software filters.  If you’re used to using Avisynth, you’ll know what I mean.

First speed run with Squeeze 5 – 2:48 video took ~51 minutes to encode.  I had Squeeze set to four Simultaneous Compressions (Maximum).  Squeeze was able to do the three WMV files at once, but could not do more than one VP6 or MP4 at a time.  About half of the 51 minutes was watching Squeeze slog through the last three H.264 encodes.

Next up, Squeeze 6 – the same 2:48 video took ~22:30 minutes on Squeeze 6.  VP6 is now multi-threaded but Main Concept is not, i.e. no simultaneous compressions.

Knowing what the “support” staff at Sorenson would say, I tried this with the Sorenson H.264 codec.  That did do simutaneous encodes but…the whole thing took longer.  Leading to my next test:

Main Concept H.264 vs. Sorenson H.264 – doing only the H.264 encodes, here’s the problem:  Sorenson H.264, running four encodes at a time, took 14 minutes.  Main Concept, running one at a time, took 6 minutes (with CABAC!).

Watch Folders – using Watch Folders should be a part of any Professional encoding software.  Squeeze has had them for quite a while.  Very often you had to use them.  If you tried to import 20 or 25 sources into Squeeze 5 it would (I assume) run out of memory and crash.  So on to the Watch Folder.  The problem there was: no simultaneous encodes.  Each file grinds through each encoding profile separately.  Using projects with up to 14 profiles, this can be a drag.  Many projects took three times as long to complete.

Sad to say, it’s exactly the same in Squeeze 6.  My hopes dashed again.



  • Speed boost can be up to and over double.
  • fixed small bug with Main Concept sticking on the last few frames

Still the same:

  • Cannot create hinted QuickTime H.264 MOV
  • No support for Avisynth
  • Main Concept H.264 – no simutaneous encodes
  • Watch Folders – no simutaneous encodes.

If you are encoding a lot to a lot of different codecs, I do recommend that you buy Squeeze 6.  If you are using Squeeze 5, and have been happy with it, it’s probably not worth the upgrade.  For me, I’ll wait a bit for them to iron out any bugs that I haven’t run into yet, but it seems inevitable.

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:


No charge to clients of Metro Encoding.