Quick Sync: Power Consumption
In order to get a closer look at Quick Sync's benefits in the mobile space, we're using an unprotected 1080p BDAV source on our hard drive to transcode with Cyberlink's MediaEspresso 6.5. If you use MediaEspresso on a Sandy Bridge system, Cyberlink always implements the encoder that Intel provides with MediaSDK, which happens to be the company's turn-key reference library for hardware-accelerated encoding and decoding. As a result, Cyberlink provides two pathways for trascoding: performance or quality. This setting is independent of the overall bitrate target, but it does change the granular aspect of variable bit rate control. Using the performance pathway, scenes with high motion won't be preserved as well, nor will scenes with high detail. But we deal with that in an upcoming article on transcoding image quality.
Today, we are more interested in the Core i7-2820QM, and we want to point out that the reported power values are more than just averages. They are the cumulative power numbers reported on the DC circuit. We have integrated the values over time, but are only reporting the values over a two second interval for charting purposes. These numbers represent the energy required to power the notebook during a transcode workload, with the display set to 100 nits, Wi-Fi off, and in Balanced power mode. So, we are specifically isolating the power consumption of the SSD, LCD panel, motherboard, and CPU.
Using the Performance setting, Quick Sync expectantly uses the least amount of power. Even though it ramps up, it completes the transcode in a fraction of the time. CPU utilization is less impacted by whether you're using hardware or software-based decoding, but going that route results in the transcoding workload taking longer than hardware-based decoding.
When you ratchet up to the Quality setting, there is a larger performance difference between using a hardware and software encoder. Intel's software decoder is fairly efficient, as you never see total CPU usage go beyond 30%. Even though a hardware decoder can make for better transcoding performance and lower power consumption, the biggest gain in both areas comes from using the fixed-function encoder. That is why performance falls largely into two tiers. The encoders are the lynch pin. That is why a decoder matters less in a transcode. If you look at the CPU usage and power profiles, hardware or software encoding, regardless of the decoder used, fall close together.
| MediaEspresso 6.5 Transcodemm:ss | Performance | Quality |
|---|---|---|
| Hardware-Based Encode/Decode | Time: 00:48Avg CPU %: 15.1Power (W): 35.6 | Time: 00:44Avg CPU %: 11.3 Power (W):39.9 |
| Hardware Encode/Software Decode | Time: 2:51Avg CPU %: 23.2 Power (W): 31.8 | Time: 2:49Avg CPU %: 22.8 Power (W): 35.0 |
| Software Encode/Hardware Decode | Time: 1:18Avg CPU %: 51.7 Power (W): 59.4 | Time: 2:27Avg CPU %: 75.8 Power (W): 63.8 |
| Software-Based Encode/Decode | Time: 2:32Avg CPU %: 52.7 Power (W): 56.1 | Time: 3:30Avg CPU %: 80.6 Power (W): 59.1 |
When you break the results down into a table, you see some interesting trends. Generally, you can split everything up into a software or hardware encoder camp. Surprisingly, using the quality setting, it takes less time to transcode using the hardware-based decode and encode than using the performance-oriented pathway. Part of this is because the fixed-function encoder is optimized for transcode processing. By preserving the quality, the pipeline is shorter. The software-based decoder doesn't really have a choice, one way or another. It just has to get through the work by brute force CPU horsepower.
Whether you are trying to pack movies onto your iPad for a flight or break down a file to a more manageable upload to YouTube, Quick Sync is the way to go, when it's available. You can do it fast with a low cost to power consumption, and that's a real win when you're on battery power. While it's a shame that Quick Sync isn't going to be available to anyone on the desktop with discrete graphics (at least not yet), you're much more likely to have access to it in the mobile space. Naturally, that's why we wanted to dedicate some time to testing its power impact more thoroughly here.