After launching the thread over here and after ordering the given PC, I can now confirm that the J1800 is not offering the normal QSV performance . I would not say it is as bad as the experience from overwale, but QSV is definitely slower than normal encoding. Still, ARK confirms that this particular CPU indeed offers QSV.

If you need any specific results or if I can assist in any way, just give me a shout.

Seems like HandBrake or any other tool for QSV is not at fault, it's just Intel holding back on the drivers. It took me quite some effort but hidden in the corners of the internet is this little page: http://www.touslesdrivers.com/index.php ... code=40504. For those that don't speak French, it lists a newer driver for Bay Trail graphics (made in January, released in February) that is currently unavailable from the Intel website. Sure enough, installing these drivers suddenly unlocks QSV to its full potential. Converting Wreck-It Ralph in medium at 1080p was going at a nice 4fps, but enable QSV and it jumps up to an impressive 70fps.

Unlike the J1800 used by kvaruni, the Intel ARK website indicates that the N2820 processor does not support Quick Sync Video. However, since the encoder was detected as available, my original assumption was that either of the following applied:

- the Intel ARK website was incorrect for some reason, and the processor does in fact support QSV
- the graphics driver was buggy and used a code path meant for another processor/GPU combo

Now, looking at your first post (80% CPU usage and B-pyramid used even though the implementation supposedly doesn't support it), I have another theory: Intel Quick Sync Video is indeed NOT supported on your processor, and the graphics driver is using the hardware implementation…'s fallback software implementation.

If that theory is correct, you'll need a new processor is you want hardware-accelerated QSV encoding.