Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
*/]]>
Sorenson Squeeze has always been one of my favorite batch-encoding programs, offering broad output format support, straightforward (if not copious) encoding parameters, and good encoding quality. It’s also the only batch-encoding tool available on both the Mac and Windows platforms, a nice bonus for those who work with both operating systems.
In version 5, Sorenson added the ability to simultaneously encode multiple files, switched from the Apple to the MainConcept H.264 codec, added support for Microsoft’s VC-1 codec, and made several interface tweaks, most of them very beneficial. The results are generally positive, though the performance boost the program gets from the ability to encode multiple files simultaneously is less than expected, and performance from the MainConcept codec is flawed in some instances.
Note that Sorenson plans to quickly release an update for several targeted features, including workflow improvements for those publishing on YouTube and updates to the MainConcept codec that should cure potential incompatibility issues with playback on Apple’s iPod as well as the flaws we uncovered. We’ll review the update when it becomes available and publish the results on StreamingMedia.com.
As before, Sorenson is releasing multiple product versions with pricing that varies by feature and operating system. For example, the full-blown, any-codec-you-ever-dreamed-of version (Squeeze 5 Pro) costs $500 for Windows and $779 for Macintosh, and includes VP6 output and Bias Sound Soap, a useful audio noise reduction program. There are also versions with every codec but Flash (Squeeze 5) and only Flash (Squeeze 5 for Flash). A great table that displays the price and features of each version can be viewed at http://secure.sorensonmedia.com/products/?pageID=1. The page also contains a link for upgrade pricing, which varies based on operating system, the user’s current product, and the product he or she wants to acquire.
For this review, I’ll start with changes to the interface, then discuss encoding performance, then look at deinterlacing quality, and finish with codec features and compressed output quality.
Interface Tweaks
Sorenson has a useful video tutorial explaining the new features available on its website at http://secure.sorensonmedia.com/pages/?pageID=143. If users are not familiar with Squeeze, I would recommend that they view at least the initial minute or two to get a feel for the workflow.
Briefly, as before, users click the Import File button on the upper left (Figure 1) to load a file or files into the batch window, then drag one or more encoding presets from the Audience Presets menu onto the files. Click the Squeeze It! button on the bottom right, and Squeeze starts encoding.
One nice feature about Squeeze is that users can add additional source files and encoding presets after they start encoding. They can even edit and add presets and the like. This means that they don’t have to batch up all their encodes before they start encoding. They can add them as they go along.
Figure 1—Squeeze 5 is familiar enough to eliminate any learning curve and features nice additions, such as the workflow sort for presets and publish presets.
Sorenson added many useful interface tweaks to the new version, most of them evolutionary rather than revolutionary, but helpful nonetheless. For example, users now have multiple views of the encoding presets, including the format view, which sorts all output presets by codec.
The workflow view is a new feature. The view displays presets by output type—including devices, discs, presentation, set-top and web, format and workflow, and favorites—which is nice. There’s also a favorites folder that can eliminate a click or two for all repetitive encodes, a useful custom folder that contains all customized presets, and a new search function. Users can also create folders of presets, then apply them via drag and drop, another nice convenience.
Sorenson also added publish presets that allow users to deliver the compressed file to a designated location, whether it be a local directory, a FTP, or an application for further processing. Users could do this in Squeeze 4.5, but couldn’t apply the settings as a preset. Instead, they had to manually specify the output parameters for each job.
Users could always create filter presets for drag-and-drop application to their source files, and Squeeze 5 makes these presets more prominent. However, where the old interface used checkboxes and slider bars in one easy-to-see, fixed window (Figure 2, on the left), the new hides presets behind configuration panels that users have to twirl to open, meaning it now takes longer to configure and reconfigure. Perhaps this change was necessitated by the new filters added to the program—which include hue and saturation adjustments, a more easily customizable watermark, and 3:2 pulldown—but it makes it harder for users to see their configuration options at a glance.
Figure 2—Filters old (left) and new (right). It is much easier to configure and scan on the left, though Sorenson has added more filters to the new version.
Performance
One of the most significant new features relates to performance. Specifically, Sorenson added the ability to encode multiple files simultaneously, as shown in Figure 3. In previous versions, Squeeze encoded files serially, one after the other, which often wasted processor utilization on multiple-core systems.
For example, the On2 Flash encoder that Sorenson integrates into Squeeze is very inefficient when running on multiple-core systems, consuming as little as 13%–15% of overall processor capacity on an eight-core system. When encoding files to Flash format serially, the remaining 85% is essentially wasted, assuming that users are not performing other functions on the computer.
In theory, enabling multiple simultaneous encodes would harvest some of this 85%; for example, in a perfect world, encoding six Flash files on an eight-core system would use close to 100% of the available processor power and encode each file as quickly as the program could encode a single file.
Figure 3—Choosing the number of maximum simultaneous compressions
Obviously, since this feature is designed to improve encoding performance, that’s where I focused my testing. I started out on a 2.6 GHz HP xw8400 Dual-Processor, Quad-Core system with eight total cores.
Everyone’s encoding chores are different, and on this system, I wanted to test how much simultaneous encoding would speed the encoding of multiple files to a single codec. This would be the scenario for a shop that strictly uses either Windows Media, Flash, or H.264, and periodically encodes multiple files to that single format.
I loaded eight 1-minute source files into the hopper, selected Flash output, and waited for Squeeze to start encoding multiple files at once. It didn’t happen. The program encoded serially, as before. Then I tried H.264 output using the new MainConcept codec—ditto. Then I tried Windows Media Video, and Squeeze started encoding all eight files at once.
I contacted Sorenson, which advised me that while the MainConcept and VP6 codecs are multithreaded and use multiple processor cores during one encoding session, Squeeze couldn’t currently open multiple compressions with either codec. So if users operate shops that only handle Flash or H.264, simultaneous encodes won’t help them.
To test Windows Media performance, I encoded my eight files in eight simultaneous sessions, which took 29:02 (minutes:seconds), as you can see in Figure 4. Then I encoded the files serially, which took 31:58, a time savings of about 10%. Note that users can also simultaneously encode the same file to multiple Windows Media targets, though I didn’t benchmark the time savings here.
Figure 4—Producing multiple Windows Media files simultaneously
Ten percent doesn’t sound all that thrilling, but I couldn’t tell if the bottleneck was in Squeeze or the Microsoft encoding DLLs Sorenson uses to produce the files. So, on the same system, I ran similar tests using the latest version of Rhozet’s Carbon Coder.
Rendering the same eight 1-minute files serially to Windows Media format took 26:31, while rendering them simultaneously in the Queue Manager took 11:11, a drop of about 57%. Carbon Coder could encode multiple files to VP6 format simultaneously (using the Flix Pro QuickTime Export Component), and rendering in parallel as opposed to serially reduced encoding time from 21:00 to 9:27, a time savings of about 56%. Carbon Coder could also simultaneously encode files to H.264 format using the MainConcept codec, but the time savings were not significant.
Clearly, if users operate a one-codec shop, Squeeze 5’s ability to open simultaneous encoding sessions won’t significantly reduce overtime hours spent rendering files to final format. What about mixed-codec encoding runs? Here, the picture brightens considerably.
For these tests, I switched to a 3.0 GHz HP xw4600 quad-core system, and produced WMV, FLV, and MP4 files first serially, which took 11:05, then using simultaneous encoding, which dropped total encoding time down to 7:08, a tidy drop of about 36%. Significantly, processor utilization reached upwards of 90% during these tests, indicating good utilization of the available cores.
For most users who frequently encode one or more files to multiple-codec targets, this alone should easily justify the upgrade price. Overall, however, though Sorenson’s move toward simultaneous encoding was a necessary first step, it falls short of being a compelling reason to upgrade outside of these parameters.
Which Computer to Buy
Once a user has decided to buy Squeeze, he or she might also consider purchasing a new encoding station. Here, the most common question is whether to spend money on multiple cores or processor speed. The two HP systems I used for testing—the 2.6 GHz Dual-Processor, Quad-Core Xeon system with eight cores and the 3.0 GHz Quad-Core xw4600 with four cores—would reveal the answer with just a couple of additional tests.
2.6 GHz xw8400
3.0 GHz xw4600
One-minute file to FLV, MP4, WMV
7:08
13:46
Eight Files to WMV
29:00
18:38
Table 1—Test performance on two different systems
I encoded the same 1-minute source file to each of the three formats on the 2.6 GHz xw8400 system, which encoded the files simultaneously in 13:46, almost twice as long as the xw4600 (Table 1). Hmm …
Returning to the xw4600, I then compressed the same eight source files to Windows Media format using four simultaneous encoding sessions, which took 18.38, more than 10 minutes faster than the eight core xw8400. Clearly, if a user is buying an encoding station for Squeeze, a fast four-core system is a smarter buy than a slower eight-core system.
Deinterlacing Quality
Since many of us still work with interlaced source video, the deinterlacing quality produced by a batch-encoding tool is a key comparison metric. To test this, a while ago I created a 1-minute DV test file containing short clips of hard-to-deinterlace scenes, which typically involve high motion, diagonal lines, great detail, or all of the above. I’ve since deinterlaced this file with virtually all video editors and batch-encoding tools, creating a QuickTime file I can compare to new products and updates, such as Squeeze 5.
Figure 5—Despite multiple techniques, deinterlacing quality is a problem for Squeeze.
Squeeze has never been a star performer in deinterlacing tests, and I was psyched when I learned that one of the new features in Squeeze 5 was multiple deinterlacing options. To make sure I produced the optimal results, I sent my test file to Sorenson and asked them to recommend the best deinterlacing routine for the file. Sorenson recommended Discard Even Field, which I used to create the video shown in Figure 5. This particular scene, with the “jaggies” highlighted in the diagonal lines shown on the right, has been a challenge for Squeeze in the past, and it remains so. There are also several other scenes in the test file that display similar problems.
Overall, when shooting for streaming, it’s good practice to eliminate fine detail and diagonal lines whenever possible, and if users do so, deinterlacing in Squeeze won’t be a problem. But for real-world shoots, when users often can’t tailor their content for streaming, they should deinterlace in their video editors before producing the intermediate file to be encoded with Squeeze.
General Encoding Parameters
With this as background, let’s tackle the encoding configuration options and output quality. With all encoding presets, Squeeze presents both a simple and advanced view, shielding novices from the minutiae of encoding though occasionally leaving out some encoding parameters that advanced compressionists might want to see. For most codecs, Squeeze presents both single and dual pass VBR and CBR with several format-specific variations, such as Quality VBR.
For output resolution, users can check Same As Source or specify a frame size. When changing the resolution, they can select via radio button to leave the display aspect ratio unconstrained, to maintain the aspect ratio, or to insert a letter box or pillar. Leaving it unconstrained is usually the correct option. Frame rate options are expressed by frames per second or ratio, with 1:1 meaning 1 frame in the encoded file for each frame in the source.
Squeeze 5 applies an auto crop deinterlace effect to all files before encoding, which users can disable in the preferences field. These controls worked intelligently in my tests, deinterlacing interlaced source footage, leaving progressive footage alone, and not cropping any pixel that I didn’t want cropped.
Sorenson actually performed these same functions in earlier versions, which was immensely helpful because, otherwise, users could ruin a long encoding run by simply forgetting to deinterlace. In Squeeze 5, Sorenson simply brought the controls out from under the hood. These touches make Squeeze by far the most approachable program for novices, and it has the easiest learning curve.
Windows Media Encoding
Sorenson made few changes to Windows Media Video encoding in version 5. From a configuration perspective, users can access all the controls available in the Windows Media Encoder with several additional options. Specifically, they can produce WMV files in 1-Pass or 2-Pass CBR, 1-Pass Quality VBR, and 2-Pass Data Rate VBR, to which they can assign a target data rate and maximum data rate, the latter control available only in the advanced view of the preset.
The advanced view also reveals the smoothness versus quality slider, which is active only for CBR encoding, and a quality slider active for the 1-Pass Quality VBR. The only other control available in the advanced view is the Maximum Startup Latency, which sets buffer time before the clip begins to play.
Users can create multiple-bitrate files for distribution via a streaming server by dragging a special MBR template onto their source clips. MBR parameters can then be saved into a custom preset for repetitive use.
There is no control for enabling Squeeze to insert key frames at scene changes, but analysis in Inlet Semaphore revealed that Squeeze did so automatically about 50% of the time. Squeeze encodes all files using the main profile, which is appropriate, but with no control for choosing between the main and baseline profiles or B-frame interval, something advanced compressionists may wish they had.
There are also no encoding tweaks such as those provided by the Windows Media Power Toy, which is a feature that is starting to appear in more and more encoding tools, such as Rhozet Carbon Coder and Inlet’s Fathom, albeit at a much higher cost. Note that Squeeze does expand the encoding parameters when producing files using the VC-1 codec, which is the Windows Media 9—Advanced Profile codec, opening a different preset targeted primarily at encoding for Blu-ray production.
From a quality perspective, Squeeze’s WMV quality is very similar to that produced by the Windows Media Encoder and other tools such as Grass Valley ProCoder. The Windows Media format is very mature, and there is little difference between most encoding tools.
VP6 Encoding
For VP6 Flash encoding, Sorenson added support for On2’s VP6-E and VP6-S profiles, with the latter being a lower complexity profile targeted towards cell phones and other low-power devices (Figure 6). Flash-encoding options are very extensive, including most of the controls offered in On2 Flix Pro’s video/audio tab and VP6’s advanced features tab.
Figure 6—Squeeze supports both VP6-E and VP6-S, the latter a lower complexity profile for low-power devices.
For Flash, Sorenson lets users select whether to enable auto key frames with a threshold slider and set the maximum key frame interval. There are also minimum and maximum quality sliders, a VBR variability slider for customizing VBR and CBR parameters, a checkbox that allows Squeeze to drop frames to maintain the data rate, a sharpness versus smoothness slider, and noise preprocessing. Users can also customize minimum and maximum 2-Pass VBR data rate values, which default to 40% (minimum) and 400% (maximum). Other than ensuring that the auto key frames option is checked, which it now is by default, users can probably ignore these settings and work in the simple view.
I produced a VP6-E test file, which compared favorably to a file produced with On2’s Flix Pro, the gold standard for Flash encoding. Playing the files side by side, I saw virtually no difference in quality, even in the scenes with hard-to-compress backgrounds, which had been a problem for Squeeze in previous versions.
Users can produce both FLV and SWF files, and if they opt for the latter, Squeeze lets them choose an SWF player from among 10 different templates with useful options such as the ability to link or embed the actual video file (Figure 7). The templates are serviceable and will get users going quickly, and Sorenson includes a PDF reference detailing how to create custom templates in the template folder.
Figure 7—Squeeze lets users insert and configure a player when producing SWF files.
Squeeze also lets users encode video with an alpha channel for overlaying over a Flash background, though I didn’t test this feature.
H.264 Encoding
The most significant change for most streaming producers will be Sorenson’s switch to the MainConcept H.264 encoder, which proved spotty in my comparative tests. This is unfortunate because the MainConcept encoder is well-regarded for output quality. More on that in a moment.
Figure 8—Screens from Squeeze’s H.264 preset
From a configuration standpoint, users start by choosing format constraints, if any, including the Adobe Flash F4V format (Figure 8, on the left). Then they set basic configuration options, which include 1 and 2-Pass VBR (but not 2-Pass CBR) as well as resolution, aspect ratio, frame rate settings, and the like.
H.264-specific settings include those shown on the right in Figure 8. Users can choose the profile but not the level, which may frustrate some advanced users, but they can select the number of B-frames and whether to apply context-adaptive binary arithmetic coding (CABAC), a more efficient data-packing algorithm that requires more decompression horsepower. However, encoding effort and slices mean different things in different H.264 encoders, and Squeeze’s help file hadn’t been updated to define these controls.
Video quality was generally good, a nice improvement over the Apple codec Sorenson used in previous versions. Unfortunately, quality suffered frequently after scene changes, as shown on the right in Figure 9. This is the first frame after a major scene change, with Squeeze 4.5 on the left and Squeeze 5 on the right.
Sorenson has reproduced the problem and promises to have it resolved by the time that the aforementioned patch is released. Note that I didn’t see the same problem when producing H.264 files with the Apple codec in Squeeze 5. If users are upgrading from version 4.5 on the same system, they should still have the Apple codec available in Squeeze 5, and I would recommend using that codec until Sorenson fixes the problem.
Figure 9—With the new MainConcept codec, Squeeze didn’t recover quality after scene changes.
Overall, with Squeeze 5, Sorenson took baby steps in some critical new directions, including simultaneous file encoding and switching to the highly regarded MainConcept H.264 codec. Unfortunately, unless it’s your child, baby steps are seldom graceful or particularly effective, and that’s the case here.
Until Sorenson resolves the scene-change issue, I can’t recommend Squeeze for H.264 producers unless they already have the Apple codec on their systems. If users are looking for a dramatic increase in encoding speed from previous Squeeze versions, they’ll only see it if they are encoding many files with different codecs and not if they own a single-codec shop.
