Decoding the Truth About Hi-Def Video Production

Then I tried some variations on the data rate, both lower (800Kbps) and higher (3Mbps). On both the PowerMac and the 8710P, boosting the data rate increased the required playback horsepower, which decreased the display rate on the PowerMac and caused "slicing" artifacts, where only the top part of the frame would decode, making it look like the bottom half was sliced off. At the other end of the spectrum, the 800Kbps file played about as smoothly as the 2Mbps Baseline file on the PowerMac, though the iMac still lost sync–at all data rates.

Since the 800Kbps file produced with the High Profile delivered the same display rate as the 2Mbps file produced using the Baseline Profile, I compared the two files to determine which delivered the best quality. Interestingly, the quality was very similar, thus making the 800Kbps file produced using the High Profile the better option, since it should reduce your total bandwidth costs over the higher-bitrate options.

Finally, I tried playing back the file from the local hard drive, as a user would experience if the website offered the file for manual download in addition to progressive download. As you can see, this finally produced a scenario where the file played back smoothly on all three computers.

Why would this be? Though the Adobe Flash Player uses the computer’s GPU (graphics processing unit) to play back full-screen video, decoding at 100% of resolution, as I did in these tests, is all performed by the host CPU. In contrast, after downloading the H.264 file, I played it in QuickTime Player, which uses the GPU for full resolution as well as full-screen playback. In essence, the ability to decode using the graphics hardware makes the QuickTime Player a more efficient playback engine for H.264 video than the Flash player, making download-and-play a good alternative strategy for low-powered computers. When not possible, you’ll get the best results encoded to the lowest possible data rate, which should improve the playback rate on fringe computers.

You can view all the files mentioned in this section yourself at the following URLs:
—www.doceo.com/H264_Tests/H264_800K/test.html
—www.doceo.com/H264_Tests/H264_3M/test.html
—www.doceo.com/H264_Tests/H264_2M/test.html
—www.doceo.com/H264_Tests/H264B_2M/test.html

Improving the Silverlight Experience
To optimize the Silverlight viewing experience, I first tried playing back a file encoded using the VC-1 Main Profile as opposed to the Advanced Profile, which I used in the initial tests. This actually worsened the experience on the PowerMac and had no impact on the iMac. I then tried two alternative data rates, 800Kbps and 3Mbps, finding again that encoding at the lower bitrate improved playback performance on the PowerMac, though not curing issues on the iMac. Clearly, producing at the lowest possible bitrate is the best option for Silverlight.

Testing from the desktop revealed the only configuration that played acceptably well on the iMac, again an incentive for HD Silverlight producers to make their files available for download-and-play. The reason is the same as with Flash—that is, neither the Windows nor Mac Silverlight players use the system’s GPU for decoding. Once on the hard drive, the QuickTime Player on the Mac and Windows Media Player on Windows do use the GPU, improving performance, decreasing the load on the CPU, or both.

Interestingly, Silverlight’s inability to access the GPU during playback can inadvertently become a problem for producers who use a scaleable player that automatically adjusts the video resolution with the size and position of the browser. For example, the first Silverlight player I created (using a template from Expression Encoder 2) required 78% of the CPU when playing back on the HP xw4100 compared to 52.5% for the fixed resolution Silverlight player that Waggoner created. The scaleable player also boosted CPU requirements on both the PowerMac and 8710P.

In particular, note that all Expression Encoder 2 templates are scalable by default and can’t be converted into fixed resolution players within Expression Encoder 2. If you’re publishing high-definition video with Silverlight, you should either modify a player created in Expression Encoder 2 to play at 100% resolution or create your own, otherwise you could compromise performance on lower power computers.

You can view all the files mentioned in this section yourself at the following URLs:
—www.doceo.com/SL_Tests/SL_800K/test.html
—www.doceo.com/SL_Tests/SL_2M/test.html
—www.doceo.com/SL_Tests/SL_3M/test.html
—www.doceo.com/SL_Tests/SL_2M_Main/test.html
—www.doceo.com/SL_Tests/SL_2M_ScalablePlayer/test.html