Review: Sorenson Squeeze 5
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). Then I encoded the files serially, which took 31:58, which meant the simultaneous encode gave me 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.
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.
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. Hmm …