New Encoder Rig build - which CPU/how many cores?

[Rev Jim Jones]

I want to build out an encoding rig.

I would like to try to stick with mini-itx if possible as i have a number of 2U rack mount cases for mini-itx boards sitting around. The 2U cases have a 2 x mini-itx layout (that is, 2 x mini-itx boards inside the one 2U case), with a total of 8HDD caddies on the 2U housing to be used by the 2 x mini-itx boards (so 4 HDD's per mini-itx board).

There is also room for 1 x HDD inside the case itself for each mini-itx board. These days i could also get a m-itx board with an M2 NVE SSD drive onboard as well, so that could be 12 drives in total over the 2 x mini - itx boards (6 each board). So lots of room to store encodes as i do them.

I am interested in batch encoding and using RIPBOT to spread the encoding over several machines to speed it all up. I have never used RIPBOT so not sure yet what is entailed.But having the 2U case with 2 x m-its boards inside seems to be ideal for multi rig encoding using Ripbot (i think)

Goal is to take large BD remux collection down to MP4's for tablet viewing on the go.

Typical Remux size is around 25GB +/- (of course this varies greatly but is a good middle of the road number).

From extensive reading i see that the HDD spindle speed is of little relevance to encoding and then writing out the files. It seems to be all about CPU frequency and core count.

I am after insight from those who do lots of encoding as to the best bang for buck setup given all the above. Should i be looking at i7 6700K? or previous gen 5850? Do i go up to 8C 6850? or am i better to be looking at Xeon E5-2620 V4 8C CPU?

Mini-itx is going to limit my choices somewhat i expect.

If mini-itx is too limiting then i have little choice but to go ATX or similar and choices really expand. What do you recommend? Budget is middle of the road - not tight but i dont want to spend silly money to get an extra 5% performance either.

At this stage is it better to wait to see what Zen will be all about and what the specs/core count/$$ ratio is ?

[sophisticles]

For pure encoding, i.e. no editing, I think it's hard to argue over a Kaby Lake / Quick Sync solution, I would just buy the cheapest laptop with a Kaby Lake processor (you can get one for $350) and call it a day or buy a Pascal based gpu and encode that way.

Your usage scenario screams hardware encoder, much lower power consumption, faster and depending on which tests you believe in some cases better quality.

The solutions you mentioned are great if you plan on doing editing, and I would wait to see what Zen brings to the table, but otherwise...

[Rev Jim Jones]

But isn't Quick Sync and GPU encoding of lower quality? Not sure myself as i have never used these new technologies.

I am going all out to build a fast high quality encoding setup- I have about 2000 BD's to encode and i want to do several different formats per BD, so lots and lots of encoding.

I am interested in RIPBOT distributed encoding.

So really want to do this right - not sure a laptop fits this profile but its something i have never considered.

[usually_quiet]

But isn't Quick Sync and GPU encoding of lower quality? Not sure myself as i have never used these new technologies.

I am going all out to build a fast high quality encoding setup- I have about 2000 BD's to encode and i want to do several different formats per BD, so lots and lots of encoding.

I am interested in RIPBOT distributed encoding.

So really want to do this right - not sure a laptop fits this profile but its something i have never considered.

Quick Sync encoding for H.264 and H.265 has improved quite a bit. Some people find Quick Sync is close enough in quality to CPU-based encoding to use it for very fast encodes. You will have to try it for yourself to find out if it is good enough to meet your needs.

If you can wait, Kaby Lake desktop CPUs and motherboards are supposed to be released in early January, and the first AMD Ryzen CPUs and motherboards are supposed to be released in mid-January.

[Rev Jim Jones]

yeah it seems at the end of December 2016 it seems better to sit and wait and see what Zen brings.

Still interested in knowing which is generally the best way to go - more cores (and how many) or Ghz (and how much).

i will be encoding to h.264 MP4/AAC from BD remux

[usually_quiet]

yeah it seems at the end of December 2016 it seems better to sit and wait and see what Zen brings.

Still interested in knowing which is generally the best way to go - more cores (and how many) or Ghz (and how much).

i will be encoding to h.264 MP4/AAC from BD remux

I'm not a frequent re-encoder, but have seen threads here and elsewhere about multi-core encoding.

Here are two recent threads at doom9:
http://forum.doom9.org/showthread.php?t=173277
http://forum.doom9.org/showthread.php?t=173522

[LigH.de]

If you are interested in a good speed for software encoding, get a CPU which supports modern instruction set extensions for SIMD and vector math (SSE3+, AVX+). Even though x264 still scales well for many cores, x265 does not as much, here a faster core speed and more efficient architecture are better than a lot of cores with not quite the most modern architecture.

QuickSync can be useful for several parts of the whole field of video processing, e.g. video decoding and maybe even fast and simple encoding. In general, modern intel Core i# are more related to "raw power" than AMD CPU families, but cost a lot more, so know what you can afford. And multi-socket systems may be useful if you want to process several videos in parallel, but their use to speed up one single process is limited.

[ezcapper]

If they release a zen equivalent to the fx 6300, that would be the way to go. It is under $70. The kaby lake chips will not be cheap, especially if you will be buying mulitiple ones. It would be a good idea to try a kaby lake laptop-type underclocked processor first like the 7100u and if quicksync is not good enough quality for you just return it. If you have to use x264, you would like to select the "very slow" preset and a crf value of 17. You can google any of that if unfamiliar. You really don't need a 6700k or the fastest zen processor. For x264 you would be fine with a mid-level desktop processor. Try to find one with a passmark benchmark score above 6000, that will give you good speed, I'm guessing around 3.5x realtime or better.

Here is a video with how to use handbrake to encode with Quick Sync H264 if you go the Kaby Lake route:

https://youtu.be/qswaXopAhow

[Rev Jim Jones]

Thanks for the input/s.

Lots to ponder. Its never easy, is it?

[Rev Jim Jones]

It would be a good idea to try a kaby lake laptop-type underclocked processor first like the 7100u and if quicksync is not good enough quality for you just return it.

Thanks for the interesting idea but this is not possible for me. I am in the middle of Africa, so freight in/out, clearing fees, duties etc make this unrealistic for me.

[Rev Jim Jones]

So...... how good/bad is this Quick Sync encoding ?

I know, i know, how long is a piece of string....... but this idea of using a low end laptop to encode is intriguing me. If H/W encoding is fast (please educate me, how fast? - say a 25GB remux to "very slow, CRF=17 settings) then maybe i am wasting time and money on building an encoding rig.

I do plan to do video editing but still sometime away from that, so better to build that rig once i actually start shooting footage.

[usually_quiet]

So...... how good/bad is this Quick Sync encoding ?

I know, i know, how long is a piece of string....... but this idea of using a low end laptop to encode is intriguing me. If H/W encoding is fast (please educate me, how fast? - say a 25GB remux to "very slow, CRF=17 settings) then maybe i am wasting time and money on building an encoding rig.

I do plan to do video editing but still sometime away from that, so better to build that rig once i actually start shooting footage.

I've seen the speed and quality available from Quick Sync from recent Intel CPUs compared to x264 at the very fast preset. There have been incremental improvements in the quality available from Quick Sync with each CPU generation. However, better quality and smaller file sizes are available from x264 using higher quality settings, at the expense of encoding time.

You might find this post interesting: https://forum.videohelp.com/threads/381481-Quick-Sync-(Haswell-Skylake)-h264-Info?p=2468311

[Rev Jim Jones]

I'm not a frequent re-encoder, but have seen threads here and elsewhere about multi-core encoding.

Here are two recent threads at doom9:
http://forum.doom9.org/showthread.php?t=173277
http://forum.doom9.org/showthread.php?t=173522

So having read all that from those threads, this is not a simple thing actually. So it sounds to me like dont go mad on core count. Stick to reasonable level like 6C or 8C on a single Proc.

In general will faster encoding come from say 4C at 3.4GHz Vs 8C at 2.1Ghz ?

Just trying to get a basic idea of a very complicated situation. Its sounding to me like 4C at higher GHz per mini-itx is going to be the most reasonable solution for me at this stage that i am at ---- which is, starting out !

Still intrigued by 2 concepts.......

1/ RIPBOT doing distributed encoding

2/ Quick Sync on a cheap laptop.


Still not sure about how much faster Quick Sync would be for a given file Vs software encoding on the same file.

But i am taking this into consideration re the Quick Sync...... i am encoding down from BD Remux to MP4/AAC for mobile and tablet devices. I intend to encode to 1080P, but maybe at small screen sizes 720P is more then enough ?

None of this is easy. But its fun.

[ezcapper]

if you pm the member vhelp he can do quicksync quality tests for you. He has this laptop and is able to encode in real-time:
https://www.amazon.com/Acer-Aspire-i3-7100U-Windows-E5-575-33BM/dp/B01K1IO3QW

this is a sample he has done, but he would probably one with whatever video content you want to meet your needs:
https://forum.videohelp.com/attachments/39995-1482333611/2016-12-21_09-52-59.mp4

like usually_quiet mentioned, people assume the quality of kaby lake quicksync to be around x264 very fast. Using that, you can assume that the result of your video won't be worse than the video below encoded with x264 ultra_fast setting (one step below very fast) at crf 17. The speed settings affect the file size and not very much the quality, so note that the overall bitrate is 15.5 Mbps with audio. Ultrafast results in a larger file size and tries to achieve the same quality as very slow. Similary quick sync will try to achieve the similar quality to very slow but at a larger filesize, but not quite as large as ultra fast:

http://bit.ly/2ivzMak

The above file was encoded using x264 ultrafast crf 17 (recorded off of 1366x768 desktop upscaled to 1920x1080 at a framerate of appx 30 fps before encoding). It is a clip from the movie Tears of Steel

[Selur]

as a side note:
qsv, vce, nvcenc all do not support hdr signaling during encoding, so it you plan to (re-)encode to H.265 with HDR signaling you are suck with software encoding.

[Rev Jim Jones]

No plans for H265 at this time.

Need maximum compatibility with mobile devices <phablets> <tablets> etc. Also for laptop when travelling but then H265 is fine for that.

Aiming for MP4/H264/AAC at either 1080P or 720P. Thinking 720P makes more sense for the Phablet/tablet needs. But not sure yet. I bought a number of used Nook HD+ tabets as they have very nice 1080P screen at almost 10" ...will have to encode a few titles to see how they look on the Nook HD+

But again, intrigued by this QuickSync thingy. It may well be good enough for the Nook HD+ as its only a 10" screen.

So if i went Quick Sync then Staxrip would be the way to go - no??

[Rev Jim Jones]

this is a sample he has done, but he would probably one with whatever video content you want to meet your needs:
https://forum.videohelp.com/attachments/39995-1482333611/2016-12-21_09-52-59.mp4

Thanks for the link. I downloaded that and watched it. Interesting.

Would be good to see some movie footage of QS encoding * Vs * h264 slow preset at level of 18 encoding to compare.

Looked up the laptop at Amazon. Amazing little machine for the money. Thinking about getting one just for use as a laptop as it pushes al the right buttons for a budget machine. If it can do some quality encoding so much the better. it has an M2 slot onboard so thats a plus. Run OS and all the apps from M2 and output the encodes to the 1TB HDD. Sounds ideal to me. Also takes up to 32GB RAM.

Thanks for this heads up !!

What sort of time difference are we talking between software encode and HW encode on the same file ?

[ezcapper]

Here is a white paper that might be able to answer some of your speed differential questions:
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/cloud-computi...hite-paper.pdf

With staxrip, under Quick Sync encoder options I would use LA-ICQ mode, quality Best, quality 17, la-depth 30. You will get very very good quality. But file might be too large for you I don't know. For small file size quality 25. Using these settings you will get quality good enough for your needs.

[Rev Jim Jones]

OK so i am getting excited about Quick Sync.

The more i read and research the more Kaby Lake is the way to go. It would seem that the QS quality is ok and quite fast. I am no expert so correct me if I am wrong but for encoding down to suit Mobile devices with smaller screens any loss of quality, if there is indeed any loss at all, would have almost no impact on quality to those small screens - right?

Seems for my use case the Acer Laptop is the way to go. I sure cant setup those mini-itx boards/CPU/RAM for the price.

Guys you have sold me !! Thanks so much for this heads up !

[ezcapper]

yes, the smaller screens is the main reason you shouldn't be able to casually tell the difference between the two. take care!

[jagabo]

On recent CPUs QS h.264 encoding is about the quality of x264 at the veryfast preset. And on a i7 it's not much faster than x264 at that preset. x264 at say, the slow preset, is significantly better though slower.

Watch for small, low contrast details to disappear (film grain, fuzzy sweaters) and posterization artifacts.

[Rev Jim Jones]

http://www.anandtech.com/show/10880/asrock-upgrades-beeboxs-sff-pcs-with-kaby-lake-cpus

[usually_quiet]

http://www.anandtech.com/show/10880/asrock-upgrades-beeboxs-sff-pcs-with-kaby-lake-cpus

You want to re-encode a large number of files. The BeeBox and similar tiny PCs are not a good choice for someone who will use them for long encoding sessions. Most tiny PCs aren't well ventilated and usually don't have a CPU fan. Although Quick Sync is more energy efficient than CPU-based encoding, you could still face overheating problems when running batch encodes.

If ASRock produces a mini-STX PC for Kaby Lake like their current DeskMini 110 for Skylake, that would be better. It uses desktop CPUs. The case is well-ventilated and the CPU fan helps to cool the entire system. http://www.anandtech.com/show/10404/asrock-deskmini-110-ministx-pc-review

[ezcapper]

http://www.anandtech.com/show/10880/asrock-upgrades-beeboxs-sff-pcs-with-kaby-lake-cpus

Here is a video review of that box:

https://www.youtube.com/watch?v=QBiZVtvmSVE

I think the beebox is worth the increase in cost over the Acer, but other's might think not. If you're willing to use more power, you can like jagabo said go with a skylake desktop for the significantly less than that beebox.

https://www.amazon.com/Lenovo-Ideacentre-300-Computer-90DA00LPUS/dp/B01KLSMWVA/ref=sr_...+desktop&psc=1

But your electricity requirements will go up quite a bit with the Lenovo (tdp 51w processor). The pro would be that you can use either x264 or quick sync depending on which you liked more.

[Rev Jim Jones]

OK. Got it. After much reading......and reading, it seems like Quick Sync on Kaby Lake will be a good amount of quality increase and good enough for encodes for small screens and less important stuff. Still cant get an idea of how much time is saved though over a software encode.

It appears that for quality, with H.264, a software encode with slow preset and quality of 17-18 is still the way to go for TV's and the like.

The way i am seeing this is, Quick Sync is another tool in the tool box to be selected for particular use needs. Kaby Lake desktop parts will be good for software encoding. So seems like a Kaby Lake Desktop CPU on the mini-itx boards is the way to go for now as it allows all encode scenarios. Use Staxrip for Quick Sync encodes and Ripbot for distributed encoding over several PC's (mini-itx boards in my case)

That little Acer laptop seems to hit the spot though for encoding the low end stuff i need.

Going to be lots of options very soon i think - CES starts in a few days.

after many many hours of reading and digging around that's my take on it.

Thanks to all who chipped in (excuse the pun)

[vhelp]

First, I want to say that bluray movies are nearly horrible or horribly mastered in this medium. What have they done!

In my latest find, on the movie "Weird Science, 1985, AR:1.85, pop # 61106367" the movie gives you the appearance that it was either up-scaled from 480p and/or processed with vhs-like filtering. The only thing that gives it any quality is that they pump up the bitrate. I believe that most bluray's are given the bitrate of 25 Mbps and not more, and for good reason. The only way to maintain the level of detail that you do see (butchered or not) is through this high bitrate method.

I never expected to see or experience bluray like this. ever! And its pretty easy to realize this when you upgrade to a better viewing monitor. Although I do not notice it on a typical laptop, even my newest 7th gen (1920x1080) laptop, it is definitely noticeable on my upgrade 22" monitor. This is not a pro monitor. In fact, its pretty cheap, but definitely better than my dell laptop. With this new monitor I can now see the imperfections in all the videos I have worked with, plus all the new movies I am now playing on this monitor. And I don't have to adjust this monitor to realize that. I am shocked and surprised and a little bit disappointed with bluray.

Ok. Rant over.

In my opinion, the birate should be high, not low. It should be between 9 Mbps and 15 Mbps or more but definitely not the same as the disc's bitrate, which is 25 Mbps. Otherwise, you are better off not transcoding and just playing them direct from disc. The goal should be to cut the file size in half or less but without noticeable loss to image detail. There is no more competition for how low bitrate you can go with a given movie. Those days are long gone. Over. Today is about preserving or cutting down the fat off of content such as bluray. Using tools as AVC and HEVC, the latest in video format allows us to accomplish this.

With bluray, you have to be mindful of the image processing in each movie because they vary from movie to movie. Some movies have varying levels of grain, from none, to low, to mid to high. And because of this, encoding strategies will have to be constantly monitored and adjusted accordingly. For instance, "Weird Science" has no grain, but has heavy noise reduction (NR) applied to it, giving it the usual "temporal-screen-matted" appearance during various kinds of panning or motion. While, on the other hand, in the movie, "The Matrix" it has mid-to-mild film grain. At first glance, it looks great. But wait till you start transcoding it to AVC or HEVC, or other preferred destination format, and you have problems because of its mostly "dark" and "green cast" special-effects. There are lots of "rainbow" artifacts in dark scenes. So annoying to attempt to remove or at least reduce, but to no avail since 8bit video is limited and part of the cause of this typical artifact. Then there is the movie, "The Fifth Element". It has high film grain. The grain can be annoying at times. I try not to look at it, to not notice if I can help it. All of these things effect how you will encode the video. Just throwing it in some chopper and assigning it a default bitrate ie, { CQ 18 } or { CRF 18 } is not the best way to transcode but it does serve as a starting point which I do use at first and observe the file size. You still want to control the file size to some degree.

Suggestions, below.

Gauging. This is a good technique I use when I am encoding video. I always start with the best encoder. x264. It is the day-facto tool for video production. I start with a typical recipe:

1. x264 --preset slow --crf 18
2. note the file size (and quality, of course)
3. using the test encoder (ie, Intel's quicksync, or QS) set your encoding params and encode the video, note the following: file size and quality

First, begin by playing the x264 encoded video. review the play quality. Look for obvious scenes for areas that give you the perception of poor quality or noticeable artifacts. If you don't notice anything wrong, great. But if you do, don't worry. This first clip is your test base, your sample gauge, to use against the other test encoder, QS.

Now, begin playing your other encoder's video. ie, QS. Ask yourself the question: is the file size the same or near (by a few MB's) or is it too large than the x264 video? If its too large, then adjust your QS param(s) and re-run the QS encode. Then, once you are satisfied with the file size, move on to the video analysis steps. You want to review the image detail and compare it against the x264 video. Is it as good or better or worse? Did the image details (ie, film grain) carry over into the QS test encode video? does the video appear acceptable to you? Only you can answer that to yourself.

I have two flags for setting off the red-alert or to re-encode section(s) again:

First flag is the file size. That is my number one gauge.
Second flag is the video analysis gauge, my number two gauge. The two work hand in hand, and both must pass the flag test. No flags should be raised

Once you are satisfied, then you can encode the video completely.

Then, repeat the steps outlined above for the next movie.

By the time you do a dozen or so movies, you'll begin to discern how the remaining movies should be processed and the whole process will go slightly quicker. The above is my basic steps to how I process video. But just throwing every movie into some master template is not the best way to go. So, keep that in mind. I hope this helps some.

[Rev Jim Jones]

Hey vhelp........

Thanks for the run down.

In your opinion...... for h.264. More cores and up to how many OR more Ghz and what is reasonable....ie, 4Ghz base clock speed monster or 2.4Ghz average CPU ?

For a given file, say;

Fifth Element..... using h.264 slow/QF 18......takes how long approx ?

Fifth Element..... using QS max quality ......takes how long approx ? (using Kaby Lake CPU)

Thanks for any insights you can give.

[ezcapper]

Hey vhelp........

Thanks for the run down.

In your opinion...... for h.264. More cores and up to how many OR more Ghz and what is reasonable....ie, 4Ghz base clock speed monster or 2.4Ghz average CPU ?

For a given file, say;

Fifth Element..... using h.264 slow/QF 18......takes how long approx ?

Fifth Element..... using QS max quality ......takes how long approx ? (using Kaby Lake CPU)

Thanks for any insights you can give.

with the entry level i3 skylake desktop maybe 3.5x realtime, i5 appx 2x realtime, i7 appx 1.5x realtime for x264, and realtime for QSV.

For that kaby lake laptop, I'm guessing he gets maybe 7x realtime for x264 and realtime for QSV.

with the slow preset as you mentioned for x264, so Fifth element would take 15 hours to encode on the laptop and a little over 3 on an i7 desktop

edit: Jagabo's test's show suggest that QuickSync will be faster than realtime. His processor encodes x264 slightly faster than the i3 Skylake desktop, but slightly slower than an i5 6600, if that helps you estimate encoding time. There is no point comparing the implementation of Quick Sync in it's first generation (i5-2500k) with it's current implementation. It would be like comparing an IBM PS/2 with a modern computer. I will try to pull up a kaby lake quick sync encode from the internet

here is a comparison of the 2nd generation of Quick Sync with a blu ray source and x264, done with an hd graphics 2000 processor:

https://www.youtube.com/watch?v=0c_loMvtHMU

Now here is skylake QSV test with dark scenes (8Mb/s). This trailer is currently the main clip used for avc benchmark testing:

https://www.dropbox.com/s/9th5edicnk5bpse/I%20Am%20Legend%20-%20Trailer-QSV.mp4?dl=0

As you can see, intel has progressed quite a bit, the biggest problem is coming back from a fade to black scene.

[vhelp]

I wish I can answer your questions, but at this time, I can't. I am still in the testing phases with QS myself. I do this as a hobby. QS is still new and changing.

In my opinion, Skylake and Kabylake both the same level of encoding expectations or efficiency, despite the Graphics No level (or, GNL), 520..580 vs 615..620, ... and Canonlake will be coming out some time next year, but I don't know what the GNL will be like by then, through probably in the 700 range. The current top of the line GNL is the 620, those you can now see in today's current laptops. I saw a whole slew of them at my local Bestbuy. But they were very pricey. So, the higher Graphics No, the greater (or improved) encoding efficiency.

The only advice I can give you is to try various scenarios. Read other peoples process. { google search for that, for things like "x264 encoding" etc } And then try their suggestions or examples and then try your own variation and see what works best for you. Also, search the guides on this forum board. See if you can find a few that you can try and see how far you get with a couple of them. Test the viewing on your devices and try to determine if they are what you are looking for to do, and go with it if they satisfy your requirements. That is how we all learned. I'm still learning all this stuff.

To get an idea of how long something will take, using QS, when you set up QS to encode, look at the status output and see what it tells you. Look for something like "time remaining".

Also, bare in mind that bluray is not pristine. It has compression artifact in them as well, but remember from earlier, they use a very high bitrate (25Mbps) to mask or hide all that, so you don't see them during playback. The only time you will begin to see them (the artifacts, etc) is when you begin re-encoding them to a lower less efficient (or improperly used) encoder.

I will post a couple of new sample "test" videos I made to review QS performance, etc. I like to test with my older Dell Inspiron laptop. It has an Intel i3-2370M cpu and is maxed out at API v1.4 though the latest media sdk api is 1.19 currently. The maximum hardware encoder it has is AVC and MPEG2. GNL is 3000. It has very limited parameter features and usage but even at its low and limited API capability, it does produce pretty good video, as you will see in the next follow-up video samples.

Oh, and one more thing. If you tell me what cpu you have in each of your tablets and laptops, I can tell you if you have Intel Quicksync or not. The chances are though, that you do but you don't know it. And, if you do have QS, you can start experimenting with it right away and update your decisions on an upgrade afterwards. Until then, do the following to get the cpu info:

1. under windows, click the Start button, and type "device manager" and select it.
2. select processors, and read me what each Tablet and Laptop cpu name each report.
3. ie, on my it will report an "i3-2370M cpu @ 2.40Ghz" -- give me that info for each of your devices.
4. hint: if you have a 2370M or higher, chances are you have quicksync. but some chips still don't have it.

[jagabo]

In your opinion...... for h.264. More cores and up to how many OR more Ghz and what is reasonable....ie, 4Ghz base clock speed monster or 2.4Ghz average CPU ?

The range of CPU speeds is pretty small, from about 1.6 GHZ to 4. GHz. Whereas the range of logical cores is much larger, from 1 to 24 or more. So you can scale more with cores if you can afford them.

For a given file, say;

Fifth Element..... using h.264 slow/QF 18......takes how long approx ?

Fifth Element..... using QS max quality ......takes how long approx ? (using Kaby Lake CPU)

That's not really a fair comparison because the x264 encode will be better quality or much smaller.

But for what it's worth: here's example of encoding speeds on my i5 2500K (a 2.35:1 blu-ray source cropped to 1920x816):

x264, veryfast, 40 fps
x264, slow, 10 fps
qsvenc, best, 90 fps

But the x264 veryfast encode will be better quality than the qs encode (at the same file size) and the slow encode will be much better. With Kaby Lake I think everything will be a little faster and the qs encode will be close in quality to the x264 veryfast encode.