How to Convert DVDs for Adaptive Streaming: Part 4 of 4

Welcome to Part IV of our case study where we take three training DVDs and convert them to multiple H.264 files for adaptive streaming.  When I left you in the last segment, we had gotten the approval to go ahead with the project; now I had to encode in Sorenson Squeeze using the workflow and encoding parameters that I had devised, and perform quality control procedures on the files.

To review, I had three projects, two right around 3:17 (hour:min) the other 3:24, that I had to encode to three files each. Since it took awhile to produce the intermediate files in Adobe Premiere Pro, I wanted to start encoding when each file was ready. While I edited on my eight-core Apple Mac Pro, rendering took a lot of CPU cycles, so I wanted to spread the encoding load. I sent the first two files over to my 12-core HP Z800 workstation for encoding with Squeeze, keeping the final file for encoding on the Mac.

Some interesting points about Sorenson Squeeze. First, Squeeze can encode files in parallel, but only if you import multiple files into the program. That is, if you load three files into Squeeze and choose a preset for each, Squeeze will encode the three files in parallel, which is more efficient on a multiple-core workstation than serial encoding, where the files are rendered one after another. However, if you load a single file into Squeeze and choose three output presets, it encodes the files serially.

To get around this, you can load the same file three times, and Squeeze will encode in parallel, as shown in Figure 12. So, this is the procedure that I used to encode each source file to the three outputs.

Second, if you load another source file into Squeeze while it's already encoding, it won't start encoding the new file until it finishes all the old files. However, you can load multiple instances of Squeeze that run simultaneously on both the Mac and Windows platforms, which you can learn how to do here.  (http://www.streaminglearningcenter.com/articles/accelerating-encoding-on-multiple-core-workstations.html).

So if you started encoding in one instance, and want to start encoding another batch right away, you can simply run another instance of Squeeze, load the source file, choose your presets, and start encoding. While you wouldn't want to do this on a dual-core computer, when you have 12-cores like my HP Z800, it's the best way to max out CPU utilization and accelerate the encoding. So, I loaded two instances of Squeeze on the HP Z800 and one on the Mac, and produced close to 30 hours of video in under 24 hours.

Quality Control with Inlet Semaphore

Obviously, with 30 hours of video, watching every minute of every file was out of the question. Fortunately, I had a standalone copy of Inlet Semaphore, which can perform a suite of quality control tests on a batch or interactive basis. You start in the Quality Alerts screen shown in Figure 13. There, you configure different alerts that tell the program to look for when it analyzes the encoded file.

For example, in Figure 13, I have four alerts configured, including one that will alert me if quantization levels exceed 30 for longer than 2 seconds. To explain, quantization is a measure of how much compression was applied to a particular frame to reach the target bitrate. With H.264, once levels exceed 25-30, it could indicate in ugly video. The other alerts identify dropped or skipped frames, when audio exceeds or falls below certain levels, or when the bit rate exceeds certain levels. Once I choose these alerts, I save them in an .salert file.

I can analyze files in the main program interface, which is shown in Figure 14. It's a bit tough to see, but just below the average bit rate line below the video window, you can see a purple bar, which corresponds with the quantization alert shown in Figure 13. This is the ugly fast zoom out scene that almost got the project canned--I should have QC'd my files before showing them to the client. In addition, the blue bars reflect data rate alerts, the green bar an audio alert. Obviously, these alerts let me quickly identify where problems may exist in my files, while the graphs below the alerts line show a bunch of useful file-related information, like bit rate, frame size, and quantization and audio levels.

In addition to running Semaphore in UI mode, I can point the program to a single file or folder, then run the report in batch mode (Figure 15). Semaphore will analyze all the files and create an HTML report that details the location of any issues. This is how I ran the program to check my final files, and it did not identify any issues.

The only problem with Semaphore is that it's no longer sold as a standalone product; you can only get it as part of Inlet's Armada encoding suite, which starts at several thousand dollars. Actually, it's no longer Inlet, since Cisco bought the Raleigh-based company in early 2011.

Unfortunately, I'm unaware of any standalone tool that performs similar functions, though I'm guessing that they exist. I recommend that you find and price one before your next major project, particularly if it involves long form adaptive streaming. I would have been awfully nervous shipping files to a client without some measure of QC.

So that's it. This may be the only case study in history that took longer to write than the project took to perform (encoding time excluded, of course), but if you made it through this far, I sincerely hope you learned a lesson or two.

Jan Ozer's article first appeared on OnlineVideo.net