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.
95 Comments
View All Comments
heffeque - Monday, June 3, 2013 - link
Well... the AMD A4-5000 seems to be perfect for HTPC and I don't see in this comparison.Why not try comparing what the AMD A4-5000 can do (4k, 23Hz, etc) versus this Haswell system?
The CPU isn't that good, but there's no need for much CPU on HTPC systems, and also... the price, just look at the price.
meacupla - Monday, June 3, 2013 - link
when you playback hi10 or silverlight content, having a fast cpu helps immensely, since those formats don't have dxva support.halbhh2 - Tuesday, June 4, 2013 - link
Consider prices, at $122 suggested, the new A10 6700 is going to be interesting as the real competition to this Intel chip.majorleague - Wednesday, June 5, 2013 - link
Here is a youtube link showing 3dmark11 and windows index rating for the 4770k 3.5ghz Haswell. Not overclocked.This is apparently around 10-20fps slower than the 6800k in most games. And almost twice the price!!
Youtube link:
http://www.youtube.com/watch?v=k7Yo2A__1Xw
JDG1980 - Monday, June 3, 2013 - link
You can't use madVR on ARM. And most ARM platforms are highly locked down so you may be stuck with sub-par playback software from whoever the final vendor is.HisDivineOrder - Tuesday, June 4, 2013 - link
Because we don't live in next year, Doc Brown?BMNify - Wednesday, June 12, 2013 - link
for the same reason that QS isn't being used far more today, that being Intel and arm devs talk the talk but don't listen to or even stay in contact with the number one video quality partners ,that being the x264 and ffmpeg devs and provide their arm patches for review and official inclusion in these two key Cecil app code bases to actually use the arm/intel Low Level video encode/decode API'sMrSpadge - Monday, June 3, 2013 - link
Use an i5 and the price almost drops in half. Then undervolt it a bit and each regular CPU will only draw 40 - 50 W under sustained load. Which media playback doesn't create anyway.Mayuyu - Sunday, June 2, 2013 - link
2-Pass encodes do not offer any improvements in compression efficiency in x264. The only time you would want to use a 2-Pass encode is to hit a certain file size.Quicksync is irrelevant because their h264 encodes are inferior in quality to xvid (which has been outdated for a long time now).
raulizahi - Thursday, August 29, 2013 - link
@Mayuyu, 2-pass x264 encodes using VBR do offer improvements in compression efficiency at the same video quality. I have proven it many times. An example: target 720p50 at 3Mbps VBR, first pass I get a certain quality, second pass I get noticeably better quality.