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
eio - Sunday, June 23, 2013 - link
great example! very interesting.I agree with Montage that for most snapshots, HD4600 is significantly better than HD4000 for retaining much more texture, even for this frame 4 in 1080p.
but in 720p HD4600 shows its trade off of keep more fine grained texture: looks like HD4600 are regressed in low contrast, large scale structral infomation.
as you said, this type of regression can be more evident in video than snapshots.
eio - Sunday, June 23, 2013 - link
another thing that surprises me is: x264 is a clear loser in this test. I don't understand why, what are the specific params that handbrake used to call x264?nevcairiel - Monday, June 3, 2013 - link
@ganeshtsI'm curious, what did you use for DXVA2N testing of VC-1?
LAV Video doesn't support VC-1 DXVA2 on Intel, at least on Ivy Bridge, and i doubt Haswell changed much (although it would be a nice surprise, i'll see for myself in a few days)
ganeshts - Monday, June 3, 2013 - link
Hendrik,I made a note that DXVA2N for interlaced VC-1 has software fallback.
That issue is still not fixed in Haswell. That is why you see QuickSync consuming lower power compared to DXVA2N for the interlaced VC-1 sample.
zilexa - Monday, June 3, 2013 - link
To be honest, now that I have a near-perfect Raspberry setup, I would never buy a Core ix/AMD Ax HTPC anymore. Huge waiste of money for almost un-noticable image quality improvement.The Raspberry Pi will use max 6.5w, usually much lower. Speed in XBMC is no issue anymore, and it plays back all my movies just fine (Batman imax x264 rip 7-15MBps). I play mostly downloaded tv shows, streams and occasionally a movie. It also takes care of the whole download process in the background. So I don't even have a computer anymore at home. I sold my old AMD 780G based Silverstone M2 HTPC for €170 and it was the best decision ever.
Still cool to read about the high end possibilities of HTPC/MadVR or actually just video playback and encoding, cos thats what this is really about. But I would never buy a system to be able to support this. HTPC in my opinion is to be in a lazy mode and able to playback your shows/movies/watch your photos and streams in good HD quality and audio.
If you need HTPC, in my opinion there is no need for such an investment in a computer system which is meant for a huge variety of computing tasks.
jwcalla - Monday, June 3, 2013 - link
It's going to depend on individual needs of course, and I think your Raspberry Pi is on the other end of the extreme, but otherwise I kind of have the same reaction. This has got to be an $800+ build here for an HTPC and then I begin to wonder if this is a practical approach.Owing to the fact that Intel's entire marketing strategy is to oversell to the consumer (i.e., sell him much more than he really needs), it seems that sometimes these reviews follow the strategy too closely. For an HTPC? Core i3 at the max. And even that's being generous. If one needs certain workloads like transcoding and such then maybe a higher end box is needed. But then I question if that kind of stuff is appropriate for an HTPC.
superjim - Monday, June 3, 2013 - link
Playback a raw M2TS 1080p 60fps file on your Pi and get back to me.phoenix_rizzen - Monday, June 3, 2013 - link
How did you get around the "interface is not accelerated" issue on the RPi? I found it completely useless when trying to navigate the XBMC interface itself (you know, to select the show to watch). Sure, once the video was loaded, and processing moved over to the hardware decoder, things ran smooth as silk.I sold my RPi two weeks after receiving it due to this issue. Just wasn't worth the headaches. Since moved to a quad-core AthlonII running off an SSD with a fanless nVidia dGPU. So much nicer to work with.
vlado08 - Monday, June 3, 2013 - link
What about Frame Rate Conversion (FRC) capability?ericgl21 - Monday, June 3, 2013 - link
Ganesh,Let's assume you have two 4K/60p video files playing in a loop at the same time for a duration of 3 hours.
Is it possible that Iris or Iris Pro could play those two video streams at the same time, without dropping frames and without the processor throttling throughout the entire movie playback ?
I mean, connecting two 4K TVs, one to the HDMI port and the other to the DisplayPort, and outputting each video to each TV. Would you say the Iris / Iris Pro is up to this task? Could you test this scenario?