Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
In addition to the deinterlacing issue discussed here, Squeeze 5.0 also suffered two H.264 encoding problems. One related to very ugly key frames like those shown in Figure 1. On the left, you see the poor quality frames incident to Squeeze 5.0. Specifically, this is the first frame after a scene change, and you can see that Squeeze didn’t handle it well. Not only was this frame of poor quality, those immediately subsequent in the file were also pretty ugly as well. It took the better part of a year, but as you can see on the right, Sorenson got it fixed in version 5.1, available for downloading now at www.sorensonmedia.com/downloads. 
Figure 1. Old ugly key frame on the left, new high quality key frame on the right.
At first glance, the problem appeared to be that Squeeze didn’t recognize the scene change and didn’t put a key frame at that frame. Analyzing the file in Inlet Semaphore revealed that Squeeze did insert a key frame at the scene change, but the data allocated to the frame was insufficient, resulting in poor quality. To fix the problem, Sorenson inserted at the Contrast Maximum Data control that you see in Figure 2. I set this to 200% as shown, and the problem disappeared.
Figure 2. This control fixed the low quality key frame issue. I’d go with 200% as a default.
Improving Overall H.264 Quality
The other H.264 related problem was simply poor quality video in comparison to other H.264 encoders, which fortunately has also been resolved in version 5.1. Below are full resolution comparison frames with Squeeze 5 on the bottom left, Squeeze 5.1 on the top left, the Adobe Media Encoder on the bottom right, and Rhozet Carbon Coder on the top right.
I encoded to my standard SD encoding parameters, or a video data rate of 468 kbps, 2-pass VBR at 640×[email protected] fps, with a key frame setting of 300 and auto key frame upon scene change for programs that supported it. Audio was 32 kbps mono, and all data rates are within 5% of the target. For the video, this computes to about .051 bits per pixel, which is comparably very aggressive. For example, the lowest per pixel data rate I found in web sites using H.264 was Ziff Davis’ Cranky Geeks, at .072 (at 640×360), while Wal-Mart used .118 (at 640×426). Neither Squeeze nor Adobe Media Encoder had a setting for VBV Buffer, and I used the auto setting for Carbon Coder.
I added the Adobe Media Encoder and Carbon Coder comparisons because they both use the MainConcept codec, as does Sorenson. Note that I encoded the Carbon Coder file using the maximum available quality settings, as I did with all three other tools. For Carbon Coder, which is much more configurable, I used the settings shown in Figure 3, which enable all available H.264 quality-related options (as I understand them), and set search parameters to the maximum. 
Figure 3. Controls used for the Carbon Coder clip.
For both versions of Squeeze, I used the settings shown in Figure 4. Note that Adobe Media Encoder doesn’t really have any quality related H.264 controls beyond Profile, which I set to High.
Figure 4. Controls used from Squeeze.
Here are some of the comparable frames. Click each frame to see a full resolution version of the comparison in a separate window.
First is the pita comparison, a shot from a market in Tel Aviv that combines high motion (the spinning pita) and fine detail (the pinstriped shirt on the upper right. Note the improvement from Squeeze 5 to 5.1. 
This is the high motion skate scene. Squeeze 5 looks muddy and unfocused, while Squeeze 5.1 looks much more crisp and clear. 
Here’s a scene from Jerusalem, walking through a market street with my camcorder on my chest, shooting away. Extremely high motion, not a lot of detail. Note how much clearer the face is in the Squeeze 5.1 image, which is clearly superior to both Squeeze 5 and the Adobe Media Encoder. 
Finally, here’s skate 2, which combines high motion (the end of the skate sequence) and fine detail (the fencing around the skater). In particular, note the blurry fence regions in the Squeeze 5 shot on the bottom left, which is vastly improved on the upper left.
In addition, note how close Squeeze 5.1 and the Adobe Media Encoder come to achieving the same clarity as the Carbon Coder image. In my view, Carbon Coder is clearly superior to both Squeeze and the Adobe Media Encoder, but you couldn’t spot the difference without these side by side comparisons, which, of course, viewers never have. 
One interesting discussion that’s been making the rounds on one of the advanced compression forums that I monitor is how much difference the advanced encoding parameters available in Carbon Coder actually make in a real world clip with multiple types of content. You would think that features like Rate Distortion Optimization, Pyramid B-frame coding, and the Hadamard transformation would make a significant difference in the quality of the output, but you don’t see it here.
It’s always tough to make generalized conclusions about a few moments of source footage. It’s possible that using different footage or a much lower data rate would bring out the advantages of using these advanced encoding techniques. On the first point, this streaming test file contains 42 different scenes ranging from talking heads to very high motion, so at least in design, it was intended to represent a good cross section of real world clips.
On the second point, the data rate used for these comparisons was lower than the data rate used by any web site using H.264 video that I could find, so certainly in this regard, the tests are very relevant. Bottom line, while Squeeze can’t touch Carbon Coder’s automation and especially its multiple processor efficiency, the H.264 quality is very, very close.
