QuickSync 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.

4K for the Masses Power Consumption
POST A COMMENT

95 Comments

View All Comments

  • StardogChampion - Monday, June 03, 2013 - link

    I am wondering about this comment as well. Everything I've read seemed to indicate it would be available in mini-ITX form for building AIOs (so likely thin mini-ITX). Haswell will be a big disappointment without availability of the BGA packages in mini-ITX form. Reply
  • Sivar - Monday, June 03, 2013 - link

    Thank you for the article.
    Note that x264 is a specific software encoder, not a type of video or a thing that can be accelerated ("While full x264 acceleration using QuickSync...")
    H.264 is the video standard.

    Also note that x264, the CPU-based encoding software, does not need to run in 2-pass mode to get great quality. 2-pass mode is ONLY if you want a specific file size regardless of quality. If you want a specific quality, you use quality mode. --CRF23, for example, returns small (though variable depending on content) file size and good quality.
    Reply
  • ganeshts - Monday, June 03, 2013 - link

    Sivar,

    I did specifically want to mention full x264 acceleration using QuickSync -- That is because x264 is the H.264 encoder of choice for many users. The most beneficial addition to the CPU would be the ability to get hardware acceleration when using x264 with ANY set of options. That is simply not going to be possible with QuickSync (or, for that matter, any hardware-based encoder).

    Yes, agreed about the mistaken mention of 2-pass for improved quality. I will update it shortly.
    Reply
  • Spawne32 - Monday, June 03, 2013 - link

    People always fail to realize what key element in every one of these releases, how big the enthusiast market truly is. All of us posting here on this comment section regarding this review are a small fraction of the overall market intel targets, this is part of the reason AMD suffers so tragically with their current lineup. Power consumption and price are the two biggest factors in a regular consumers mind when purchasing a PC, be it laptop or desktop. Performance numbers rarely play a factor. I don't know what AMD is doing over there but I long for a day when AMD can actually challenge intel and drive prices down even further, because these 230-400 dollar starting prices for "mainstream" intel processors proves once again why I refuse to invest in them regardless of performance. The marginal increase in speed in my day to day activities does not warrant the price being paid for something that is obsolete in 1-2 years. AMD's highest priced processor right now is 179.99, its comparable intel counterpart in haswell....349.99, you do the math. Reply
  • bji - Monday, June 03, 2013 - link

    Either the increases in speed with each successive generation are great enough to render previous generations obsolete, or the increases in speed with each successive generation are small enough that the previous generation is not rendered obsolete. You can't have it both ways just to try to make Intel look bad, sorry.

    I don't know what margin Intel is making on these parts - do you? Remember that they are sinking large R & D and transistor budgets into these minor speed increases, and at the same time sinking lots of money into developing the next generation of process technology. If $300 is not worth it to you, don't buy the part; Intel won't be able to sustain their R & D budgets if nobody buys the results.
    Reply
  • Deuge - Monday, June 03, 2013 - link

    If one of the GT3 or GT3e parts comes out in a refreshed NUC, id love to see a review of it from an HTPC perspective. Very interested to hear if it can handle Lanzcos + AR or Jinc. Reply
  • dbcoopernz - Monday, June 03, 2013 - link

    Is the inability to use LAV with DXVA-native for madVR an Intel limitation? The devs of both the LAV filters and madVR have told me (on the doom9 forum) that DXVA-native is fine for madVR on AMD GPU's. Reply
  • BMNify - Monday, June 03, 2013 - link

    DXVA native DOES work with AMD using LAV filters and MadVR... I'm using it as I type (watching MotoGP) Reply
  • ganeshts - Monday, June 03, 2013 - link

    It also works with the Haswell piece. I will update the article ASAP. Reply
  • BMNify - Monday, June 03, 2013 - link

    APU is the go to for HTPC builders. And stop with the power this and thermals that... undervolt it, toss in a Pico PSU, suspend to memory when not in use and enjoy. Take the hundreds saved and buy a Kabini or two as clients.

    If we're talking balls to the wall processing might, absolutely, lets talk Intel but not for a simple HTPC.
    Reply

Log in

Don't have an account? Sign up now