Intel's Haswell - An HTPC Perspective: Media Playback, 4K and QuickSync Evaluated
by Ganesh T S on June 2, 2013 8:15 PM ESTQuickSync Gets Open Source Support, Regresses in Quality
I have traditionally avoided touching upon QuickSync in any of my HTPC reviews. The main reason behind this was the fact that support only existed in commercial software such as MediaEspresso, and even that functionality was spotty at best. Limited source file type support as well as limited configuration options rendered these unusable for the power users. While full x264 acceleration using QuickSync is out of the question, the developers of HandBrake have come forward with support for QuickSync in their transcoding application.
The feature is still in beta (for example, only H.264 files are allowed as input right now, and cropping isn't working properly), but we took it out for a test drive. We took a m2ts file from a Blu-ray and compressed it with a target bitrate of 10 Mbps using x264 single pass (everything at default) as well as QuickSync. The time taken for compression as well as the average power consumption during the course of the process are tabulated below. Numbers are also provided for the same process using our passive Ivy Bridge HTPC (which has the HD4000 GPU).
| H.264 Transcoding Performance | |||
| Transcoding Configuration | Engine | Power (W) | FPS |
| 1080p @ 36.2 Mbps to 1080p @ 10 Mbps | QuickSync on HD4600 | 41.81 W | 90.41 |
| x264 on Core i7-4765T | 67.93 W | 51.66 | |
| QuickSync on HD4000 | 50.32 W | 127.64 | |
| x264 on Core i3-3225 | 53.63 W | 25.99 | |
| 1080p @ 36.2 Mbps to 720p @ 7 Mbps | QuickSync on HD4600 | 44.02 W | 166.91 |
| x264 on Core i7-4765T | 65.37 W | 32.88 | |
| QuickSync on HD4000 | 59.67 W | 206.65 | |
| x264 on Core i3-3225 | 53.85 W | 16.31 | |
Fast and power-efficient transcoding is not the only requirement in the market. Video output quality is also very important. Encoder companies may present whitepapers with cherry-picked frame captures to show their efforts in good light. For all it is worth, the company's selected frame might be an I-frame, while the competitor's samples might be P or B-frames. PSNR is also presented as a metric indicating better quality. However, this is very unfair because encoders might be particularly tuned for PSNR but look bad when compared against the results of encoders tuned for, say, structural similarity (SSIM).
QuickSync is usually pretty fast, but the choice of bitrates in Handbrake seem to force it into one of the new modes in Haswell which actually regressed in both performance and image quality. This explains why the FPS on HD4000 is much more than than on the HD4600. However, Haswell remains very power efficient. Anand had mentioned in passing about image quality degradation in QuickSync on Haswell in yesterday's review. I was also able to replicate it. Given below are 10 consecutive raw frames from the various encoders. Take a look and judge for yourself on the basis of how the encoders handle movement and whether there are any image artifacts in the encoder results.
In our opinion, the QuickSync results on HD4600 appear to be worse than what is obtained on the HD4000. With Haswell, Intel introduced seven levels of quality/performance settings that application developers can choose from. According to Intel, even the lowest quality Haswell QSV settings should be better than what we had with Ivy Bridge. In practice, this simply isn't the case. There's a widespread regression in image quality ranging from appreciably worse to equal at best with Haswell compared to Ivy Bridge. I'm not sure what's going on here but QuickSync remains one of the biggest missed opportunities for Intel over the past few years. The fact that it has taken this long to get Handbrake support going is a shame. Now that we have it, the fact that Intel seems to have broken image quality is the icing on a really terrible cake.
For users looking for the best quality transcodes, software based x264 can deliver better output with tweaked options two-pass encodes (such flexibilities are just not available with the QuickSync encoder). The big attraction to QuickSync remains low CPU utilization (< 10% in many cases) while you transcode. The image quality produced by Haswell's seemingly broken QSV implementation is still good enough for use on smartphones and tablets, it's just a step in the wrong direction.
Facebook
Twitter
RSS
95 Comments
View All Comments
meacupla - Monday, June 3, 2013 - link
there's like... exactly one mITX FM2 mobo even worth considering out of a grand total of two. One of them catches on fire and neither of them have bluetooth or wifi.LGA1155 and LGA1150 have at least four each.
TomWomack - Monday, June 3, 2013 - link
The mITX FM2 motherboard that I bought last week has bluetooth and wifi; they're slightly kludged in (they are USB modules apparently glued into extra USB ports that they've added), but I don't care.The Haswell mITX boards aren't available from my preferred supplier yet, so I've gone for micro-ATX for that machine.
BMNify - Monday, June 3, 2013 - link
I know you're trolling but the fact is more people are content with converting their 5 year old C2D cookie cutter desktop into an HTPC ($50 video card + case + IR receiver = job done) than buying all new kit.We reached the age of "good enough" years ago. Money is tight and with all the available gadgets on the market (and more to come) people are looking to make it go as far as possible. Intel is going to find it harder and harder to get their high margin silicon into the homes of the average family. Good enough ARM mobile + good enough x86 allows people to own more devices and still pay the bills. It looks like AMD has accepted this, they've taking their lumps and are moving forward in this "new world". I'm not sure what Intels long term strategy is but I'm a bit concerned.
Veroxious - Tuesday, June 4, 2013 - link
Agreed 100%. I am using an old Dell SFF with an E2140 LGA775 CPU running XBMCbuntu. It works like a charm. I can watch movies while simultaneously adding content. That PC is near silent. What incentive do I have for upgrading to a Haswell based system? None whatsoever.kallogan - Monday, June 3, 2013 - link
2.0 ghz seriously ??? The core 45W Sandy i5-2500T was at 2,3 ghz and 3,3 ghz turbo. LOL at this useless cpu gen.kallogan - Monday, June 3, 2013 - link
Forget my comment didn't see it was a i7 with 8 threads. 35W tdp is not bad either. But the 45W core i7-3770T would still smoke this.Montago - Monday, June 3, 2013 - link
I must be blind... i don't see the regression you are talking about.HD4000 QSV usually get smudgy and blocky.. and that i don't see in HD4600 ... so i think you are wrong in your statements.
comparing the frames, there is little difference, and none i would ever notice while watching the movie on a handheld device like an tablet or Smartphone.
The biggest problem with QSV is not the quality, but the filesize :-(
QSV is usually 2x larger than x264
ganeshts - Monday, June 3, 2013 - link
Montago,Just one example of the many that can be unearthed from the galleries:
Look at Frame 4 in the 720p encodes in full size here:
HD4600: http://images.anandtech.com/galleries/2836/QSV-720...
HD4000: http://images.anandtech.com/galleries/2839/QSV-HD4...
Look at the horns of the cattle in the background to the right of the horse. The HD4000 version is sharper and more faithful to the original compared to the HD4600 version, even though the target bitrate is the same.
In general, when looking at the video being played back, these differences added up to a very evident quality loss.
Objectively, even the FPS took a beating with the HD4600 compared to the HD4000. There is some driver issue managing the new QuickSync Haswell modes definitely.
nevcairiel - Monday, June 3, 2013 - link
The main Haswell performance test from Anand at least showed improved QuickSync performance over Ivy, as well as something called the "Better Quality" mode (which was slower than Ivy, but never specified what it really meant)ganeshts - Monday, June 3, 2013 - link
Anand used MediaEspresso (CyberLink's commercial app), while I used HandBrake. As far as I remember, MediaEspresso doesn't allow specification of target bitrate (at least from the time that I used it a year or so back), just better quality or better performance. Handbrake allows setting of target bitrate, so the modes that are being used by the Handbrake app might be completely different from those used by MediaEspresso.As we theorize, some new Haswell modes which are probably not being used by MediaEspresso are making the transcodes longer and worse quality.