Testing NVENC with the GTX 960

[poisondeathray]

@ValenNC - Sorry, I don't understand your logic


Your screenshot doesn't indicate if it's a I vs. P or B frame in the x265 encode

71% difference in size - wouldn't you say that's significant difference?

On typical content - lack of b-frames within the same encoder makes it about 40-50% less efficient - basically it makes it useless for compression efficiency. It nullifies any potential advantage

So why don't you use AVC? b-frames work with NVEnc using AVC. AVC with NVCenc on the same card should be even faster (probably 3-4x faster with the same low CPU usage), higher quality, smaller filesize, better compatibility - at least for SD or HD resolutions. The larger the dimensions the greater the potential HEVC advantage over AVC. Basically no benefit to use HEVC with NVenc right now, unless it's for >HD resolutions, and even then it's debatable.

[veronesiumb]

yes i want use avc.

as the plan vps+encoding is more expensive than the plan with only vps. I don't have problem with the cloud storage because it's offers unlimited space(1fichier.com)

Yes I will use avc in future. "b-frames work with NVEnc using AVC"

you are so good compared to me. I apologize for the trouble. maybe I'll bother you.

[ValenNC]

About 10 minutes for 1080p footage in the standard movie time range. The above sequence was a 720p episode that ran 42m and did have one processing job to downsize to 480p. That another thing, if you start to do a lot of avisynth processing which for standard BluRay conversions you won't need but for poor footage if you run deblocker, noise reduction, levels, ect... Avisynth can drop your FPS down to 15fps and in this case I use x.265 which only adds a few FPS hit and take advantage of greater compression since I"m going to have to wait forever anyway.

[poisondeathray]

yes i want use avc.

as the plan vps+encoding is more expensive than the plan with only vps. I don't have problem with the cloud storage because it's offers unlimited space(1fichier.com)

Yes I will use avc in future. "b-frames work with NVEnc using AVC"

you are so good compared to me. I apologize for the trouble. maybe I'll bother you.

What is your question ?

You have to decide where you want to make trade offs. Right now , GPU encoders can't match the compression efficiency of CPU encoders like x265 and x264 . "Compression efficiency" implies a certain quality level at a given filesize. i.e at equivalent filesizes, x265 and x264 will yield higher quality (higher compression) . Proper comparisons are always done at the same bitrate (thus same filesize). If you 're using quality or cqp based rate control, you do serial encodes adjusting the values until they become the same bitrate - otherwise the results are non comparable, both in terms of quality and speed. It's a lot of work to make proper comparisons

If you don't care about compression efficiency, and pure speed or low cpu usage is your main concern, then GPU encoders are faster in general and use much less CPU. Intel quicksync is probably the best in terms of speed and quality tradeoff for GPU encoders, if you have haswell or newer .

[ValenNC]

@ValenNC - Sorry, I don't understand your logic

Your screenshot doesn't indicate if it's a I vs. P or B frame in the x265 encode

Good point, I've only found one app that would even load h.265 to create a screen shot, staxrip and it didn't indicate frame.

Nvec h.265 is twice as fast as Nvenc h.264, 252fps vs 132fps with this video and with better compression using CQ and the same settings, although with VBR h.264 could produce better compression but not by much. And then lastly looking at the resulting video, the h.265 was slightly sharper with more detail.

Here's the results of two Nvenc h.264 runs, the first is CQ with the same settings as h.265, the second VBR.

NVEnc 1.10 (x64), using NVENC API v5.0
OS Version Unknown (x64)
CPU Intel Core i7 950 @ 3.07GHz [TB: 3.11GHz] (4C/8T)
GPU GeForce GTX 970 (13 EU) @ 1177 MHz (355.98)
Input Buffers CUDA, 16 frames
Input Info y4m (yv12) -> nv12 [SSE2], 854x480, 959/40 fps
Output Info H.264/AVC high
854x480p 1:1 23.975fps (959/40fps)
Rate Control CQP
CQP I:20 P:23 B:25
GOP length 240 frames
B frames 4 frames
Ref frames 3 frames
MV Quality Q-pel
CABAC/deblock cabac / on


encoded 61653 frames, 132.98 fps, 1658.22 kbps, 508.33 MB
encode time 0:07:44 / CPU Usage: 0.97%

frame type IDR 257
frame type I 257, avgQP 20.00, total size 7.92 MB
frame type P 12331, avgQP 23.00, total size 142.80 MB
frame type B 49065, avgQP 25.00, total size 357.61 MB

finished after 00:07:45.517
Created C:\test.x264 (508.332 MB)
-----------------------------------------------------------------------------
NVEnc 1.10 (x64), using NVENC API v5.0
OS Version Unknown (x64)
CPU Intel Core i7 950 @ 3.07GHz [TB: 3.11GHz] (4C/8T)
GPU GeForce GTX 970 (13 EU) @ 1177 MHz (355.98)
Input Buffers CUDA, 16 frames
Input Info y4m (yv12) -> nv12 [SSE2], 854x480, 959/40 fps
Output Info H.264/AVC high
854x480p 1:1 23.975fps (959/40fps)
Rate Control VBR
Bitrate 1100 kbps (Max: 2000 kbps)
Initial QP I:20 P:23 B:25
VBV buffer size auto
GOP length 240 frames
B frames 4 frames
Ref frames 3 frames
MV Quality Q-pel
CABAC/deblock cabac / on


encoded 61653 frames, 135.75 fps, 1108.96 kbps, 339.96 MB
encode time 0:07:34 / CPU Usage: 0.80%

frame type IDR 257
frame type I 257, avgQP 22.44, total size 6.14 MB
frame type P 12331, avgQP 24.09, total size 111.96 MB
frame type B 49065, avgQP 27.49, total size 221.86 MB

finished after 00:07:36.695
Created C:\test.x264 (339.956 MB)

[poisondeathray]

@ValenNC -

I wonder if something is misconfigured for your AVC runs ? Are you performing other operations ?

You should be getting 400-800 FPS at SD . You get ~200 FPS at 1920x1080. You're testing 854x480 only - that suggests something is wrong with 130-135 FPS

To put things into perspective x264 using --preset superfast is even faster - you should get about 350-450 FPS at that resolution on a modern quad core . There is no way NVEnc should be slower than CPU encoding

[ValenNC]

The content is x264 720p HD being resized to 480p, the original file size was 1.478GB hammered down to 533KB in 4 minutes counting the 5.1 audio. The performance has been unchanged across Win7->win10 fresh install. Video is a hobby, I am a 30yr IT pro by trade.

This is an X58 system with a fairly old Quad core. The reason for the speed difference I suspect is because Nvenc h.265 doesn't use B-frames, if it did I'd bet Nvenc h.264 would be faster as is the norm. Even without B-frames the quality, speed and compression it offers makes it a great choice for this particular application since I'd prefer to spend more time watching an episode than encoding it.

[poisondeathray]

The content is x264 720p HD being resized to 480p, the original file size was 1.478GB hammered down to 533KB in 4 minutes counting the 5.1 audio. The performance has been unchanged across Win7->win10 fresh install. Video is a hobby, I am a 30yr IT pro by trade.

This is an X58 system with a fairly old Quad core. The reason for the speed difference I suspect is because Nvenc h.265 doesn't use B-frames, if it did I'd bet Nvenc h.264 would be faster as is the norm. Even without B-frames the quality, speed and compression it offers makes it a great choice for this particular application since I'd prefer to spend more time watching an episode than encoding it.

Yes, no b-frames makes HEVC encoding faster, but it shouldn't make AVC slower. AVC encoding isn't affected. It's all done on the same ASIC. Something is definitely wrong with your posted AVC FPS . If you're in IT this should problem be bugging you like crazy...

[ValenNC]

Yes, no b-frames makes HEVC encoding faster, but it shouldn't make AVC slower. AVC encoding isn't affected. It's all done on the same ASIC. Something is definitely wrong with your posted AVC FPS . If you're in IT this should problem be bugging you like crazy...

I have seen 450fps Nvenc h.265 encoding, I'm just not spending a lot of time messing with h.264 these days to be honest. Considering they both use the same command line tool and API, it's kind of hard for there to be a misconfiguration, although Selur and I have come across a few issues with Hybrid and NVENC which he's resolved with incredible speed as usual. I guess we'll have to wait to hear from someone else with a Nvenc card.

[poisondeathray]

I just did a quick 10000 frame test. I'm getting 400-450 FPS for AVC on a Maxwell 1 card; 1280x720 AVC source ffmpeg decoded and scaled to 854x480 in CPU by ffmpeg , piped to NVEncC64

I think it's more likely something is misconfigured than Maxwell 2 is slower than Maxwell 1. At minimum, it should be similar in speed. Maybe try another GUI or the commandline . or maybe driver issue.

I don't think audio should affect the FPS, since it's mostly GPU encoding.

I do notice your YV12 => NV12 is using SSE2, not AVX2 , but that shouldn't matter since you're getting higher FPS with NVEnc HEVC (ie. it's not the bottleneck)

Just do a quick search. Your FPS results for AVC are atypical

[ValenNC]

Interesting, h264 is running better with StaxRip. This is with the Lanczos resize, with HW encoder resize it's in the 500fps. Both are pretty close, but this time I'm favoring the h264 image.

Results below for the same file with StaxRip.

NVEnc 1.10 (x64), using NVENC API v5.0
OS Version Unknown (x64)
CPU Intel Core i7 950 @ 3.07GHz [TB: 3.11GHz] (4C/8T)
GPU GeForce GTX 970 (13 EU) @ 1177 MHz (355.98)
Input Buffers CUDA, 16 frames
Input Info Avisynth 2.60 (yv12) -> nv12 [SSE2], 848x480, 24000/1001 fps
Output Info H.264/AVC high
848x480p 160:159 23.976fps (24000/1001fps)
Rate Control VBR
Bitrate 1834 kbps (Max: 1250 kbps)
Initial QP I:20 P:23 B:25
VBV buffer size auto
GOP length 240 frames
B frames 4 frames
Ref frames 3 frames
MV Quality Q-pel
CABAC/deblock cabac / on
encoded 61653 frames, 237.94 fps, 1199.22 kbps, 367.61 MB
encode time 0:04:19 / CPU Usage: 35.64%
frame type IDR 257
frame type I 257, avgQP 22.44, total size 6.05 MB
frame type P 12331, avgQP 24.27, total size 111.67 MB
frame type B 49065, avgQP 26.68, total size 249.89 MB

Start: 12:40:40 AM
End: 12:45:01 AM
Duration: 00:04:21
-----------------------------------------------------------------------------
NVEnc 1.10 (x64), using NVENC API v5.0
OS Version Unknown (x64)
CPU Intel Core i7 950 @ 3.07GHz [TB: 3.11GHz] (4C/8T)
GPU GeForce GTX 970 (13 EU) @ 1177 MHz (355.98)
Input Buffers CUDA, 16 frames
Input Info Avisynth 2.60 (yv12) -> nv12 [SSE2], 848x480, 24000/1001 fps
Output Info H.265/HEVC main
848x480p 160:159 23.976fps (24000/1001fps)
Rate Control VBR
Bitrate 1834 kbps (Max: 1250 kbps)
Initial QP I:20 P:23 B:25
VBV buffer size auto
GOP length 240 frames
B frames 0 frames
Ref frames 3 frames
MV Quality Q-pel
encoded 61653 frames, 240.03 fps, 1243.85 kbps, 381.29 MB
encode time 0:04:17 / CPU Usage: 35.68%
frame type IDR 257
frame type I 257, avgQP 21.45, total size 5.86 MB
frame type P 61396, avgQP 23.22, total size 375.43 MB

Start: 12:50:57 AM
End: 12:55:16 AM
Duration: 00:04:18

[poisondeathray]

You should report it to Selur if you used hybrid for the tests before. Clearly those results are different FPS wise. You might have had a decoding bottleneck, maybe post the log files if you can find them

The CPU usage is much higher on these last two 35% - that can't be resize alone, it must be CPU decoding plus other stuff. And resize shouldn't be a bottleneck (you should decode and resize at least at 500+ FPS) . Unless your script is set to threads=1 . If you can find a log file for those recent two it would help too (the last 2 used avisynth , the previous ones used a pipe but it's not clear what was decoding)

Its 848, not 854, but that shouldn't make a difference (mod16 is better , but the speed for NVEnc won't be statistically different - I tested it)

AVC is still slower than it should be.

Quality comparisons of a single frame isn't very useful. For example an I vs. P frame, or B frame. No temporal characteristics are demonstrated. For example, both Nvidia is known for temporal fluctations in quality or IPB "pulsing" . (Or don't listen - because you'll start analyzing shows and movies instead of enjoying them True story. )

[poisondeathray]

This is with the Lanczos resize, with HW encoder resize it's in the 500fps.

oops I missed that part - then that suggests the resize is indeed your bottleneck if everything else is the same (same decoding pathway, etc..)

The GUI should have an avs script somewhere in a temp folder. You can test the speed with avsmeter (this will test the theoretical maximum of using that script because it's everything, all operations before feeding into NVEnc)

You can also take the resizing out of equation by creating an intermediate already resized , and using that as input

e.g. using GPU decode on pre-resized 854x480 input video, I get about 900-950FPS

If you have GPU-z active when doing this, take a look at "video engine load" in the sensors tab. If it's something low - it suggests bottleneck. I bet your runs on hybrid were only 20-30 %. You probably could have done 3 simultaneous encodes

[ValenNC]

It looks like Hybrid's not using AviSynth for resizing unless you pick a specific AviSynth filter and then it will use AviSynth and show up in the script. Will let Selur know that's a ~70fps performance hit assuming the quality is the same.

Removing all the extraneous operation bottlenecks and just doing a straight encode of the resized 480p, both encoders run at about the same performance level in Hybrid. I would think B-frames should give h.264 the compression advantage but apparently not by much, on the other hand the lack of B frames should give h.265 a quality advantage.

NVEnc 1.10 (x64), using NVENC API v5.0
OS Version Unknown (x64)
CPU Intel Core i7 950 @ 3.07GHz [TB: 3.11GHz] (4C/8T)
GPU GeForce GTX 970 (13 EU) @ 1177 MHz (355.98)
Input Buffers CUDA, 16 frames
Input Info y4m (yv12) -> nv12 [SSE2], 854x480, 959/40 fps
Output Info H.264/AVC high
854x480p 1:1 23.975fps (959/40fps)
Rate Control VBR
Bitrate 1200 kbps (Max: 2000 kbps)
Initial QP I:20 P:23 B:25
VBV buffer size auto
GOP length 240 frames
B frames 4 frames
Ref frames 3 frames
MV Quality Q-pel
CABAC/deblock cabac / on


encoded 61653 frames, 834.90 fps, 1183.95 kbps, 362.94 MB
encode time 0:01:14 / CPU Usage: 4.43%

frame type IDR 257
frame type I 257, avgQP 17.34, total size 6.49 MB
frame type P 12331, avgQP 18.52, total size 121.20 MB
frame type B 49065, avgQP 21.55, total size 235.25 MB

finished after 00:01:16.233
Created C:\Hybrid_10_13_40_4510_05.264 (362.942 MB)
----------------------------------------------------------------------------------
NVEnc 1.10 (x64), using NVENC API v5.0
OS Version Unknown (x64)
CPU Intel Core i7 950 @ 3.07GHz [TB: 3.11GHz] (4C/8T)
GPU GeForce GTX 970 (13 EU) @ 1177 MHz (355.98)
Input Buffers CUDA, 16 frames
Input Info y4m (yv12) -> nv12 [SSE2], 854x480, 959/40 fps
Output Info H.265/HEVC main
854x480p 1:1 23.975fps (959/40fps)
Rate Control VBR
Bitrate 1200 kbps (Max: 2000 kbps)
Initial QP I:20 P:23 B:25
VBV buffer size auto
GOP length 240 frames
B frames 0 frames
Ref frames 3 frames
MV Quality Q-pel


encoded 61653 frames, 833.61 fps, 1185.93 kbps, 363.55 MB
encode time 0:01:14 / CPU Usage: 3.65%

frame type IDR 257
frame type I 257, avgQP 21.53, total size 5.81 MB
frame type P 61396, avgQP 23.59, total size 357.74 MB

finished after 00:01:15.825
Created C:\Hybrid_10_17_09_8510_05.265 (363.551 MB)

[ValenNC]

in the vast array of check boxes that is Hybrid there is an option to "Always use AviSynth" along with options to use LibavVideoSource over FFMpegVideosource which allowed me to replicate StaxRip's very basic AviScript of loadsource and resize. Hybrid adds the use of AviSynth MT which can also be disabled and really didn't seem to make a difference performance wise with just a resize. Making them as similar as possible Hybrid was now doing 212FPS, not quite the 232 of StaxRip but there are more parameters set in hybrids x.264 command line. Either way the lesson here is to enable always use Avisynth.

[poisondeathray]

That's a bit more representative of the encoder itself at least in terms of speed. It's not NVEnc's fault if you can't feed it frames fast enough.

But it still seems to be a bit slower than expected. GPU-z probably doesn't report 100% (ie. you have idle, wasted cycles). You should get be getting closer to 900-950 FPS. I just ran a quick test and got 938FPS. How is it being decoded ? That might be your next bottleneck. The other thing it could be YV12=>NV12 using SSE2, not AVX. I heard the conversion using SSE2 routine is "very fast", whatever that means - but no actual quantification of numbers.

If you set out to test the effect of resizing on encoding speed, then sure include the resize. Some algorithms are significantly faster than others. If you were set on a specfiic algorithm (e.g. lanczos 3taps) , you can test different setups using lanczos3. Intel has a lanczos3 based AVX resize, but it's not implemented yet in any encoding solutions yet AFAIK, but in theory that would be the fastest. Usually vapoursynth will be the fastest for certain simple CPU operations like resizing. For NVEnc encoding speeds I get about 310-320 FPS with ffmpeg lanczos3, 345-355 FPS with avisynth lanczos3, 385-395FPS with vpy lanczos3 using the same resizing parameters earlier. I think staxrip has vapoursynth as one of the options, you can explore that. But that means your GPU is only partly loaded and you could do 2 or more simultaneous encodes. It's almost additive (a bit of overhead), but the total I'm seeing is about 1000-1050 FPS for 100% load across multiple instances for 1 GPU

In terms of quality, if you want to contribute and do proper testing, you should upload a source test sample, and both encodes. It doesn't have to be a full length movie or show. You should include all the information how you got from "A to B" - that would mean the commandlines or at least a description of settings (ie. enough for someone to reproduce your results) . This could help identify problems and perhaps feedback for Nvidia to improve (HAHA - unlikely, they are pretty unresponsive to these sorts of things, but hey you can hope)

[ValenNC]

All good, no my initial point was in answer to a user on another thread that complained about x.265 encoding times and to show how GPU h.265 encoding can remedy that time concern. Does it compress as good as x.265, no, but it can make the difference between using h.265 and not and still get good quality and good compression. Could you also use GPU h.264 encoding, yes but other than compatibility and a few extra KB/FPS, not worth the quality hit, minimal it may be at least for NVENC.

[hello_hello]

You still use your CPU with NVENC encoding but less of it in comparison to x.265 so you can multi-task with no apparent load while your streaming 100+FPS. Here's an example of the difference between NVENC and x.265.

Yea, 4 minutes vs 2 hours... to encode, however x.265 chopped an extra 160 Mb in file size thanks to use of 4 b-frames compared to NVEnc which doesn't even support B-Frames. Quality wise however at least for me on my 80" I can't tell the difference.

x265 [info]: HEVC encoder version 1.7+478-365f7ed4d896
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 1 threads
x265 [info]: frame threads / pool features : 4 / wpp(8 rows)+pmode
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 signhide tmvp strong-intra-smoothing deblock sao
x265 [info]: frame I: 247, Avg QP:21.03 kb/s: 4836.68
x265 [info]: frame P: 16276, Avg QP:22.54 kb/s: 1827.82
x265 [info]: frame B: 45130, Avg QP:27.19 kb/s: 310.45
x265 [info]: Weighted P-Frames: Y:3.1% UV:2.6%
x265 [info]: consecutive B-frames: 5.9% 5.7% 10.2% 65.6% 12.6%
encoded 61653 frames in 7310.58s (8.43 fps), 729.16 kb/s, Avg QP:25.94

To me the top pick looks a little less detailed than the bottom one (referring to post #29 and NVEnc vs x265), but at 480p it's possibly nitpicking considering the difference in encoding speed.
Your x265 encoding seems slow. I haven't read through the last half a dozen posts thoroughly to see if it's been mentioned, but it seems not.
I haven't run any x265 encodes for quite a while (last time I did it was very slow) so I tried a couple using the default x265 settings with CRF20 and an old Q9450 CPU running XP. Aside from being surprised that x265 seems to encode a bit faster than I remembered, I was also surprised that I'm encoding faster than you. I took a 1920x816, x264 encoded video I had handy, cropped it to 16:9, and re-encoded at 480p, with Trim() in the script to encode 1000 frames from somewhere in the middle.

[Information] Log for job1 (video, 480p test CRF20.avs -> 480p test CRF20.hevc)
-[Information] [07/10/15 1:23:04 PM] Started handling job
-[Information] [07/10/15 1:23:04 PM] Preprocessing
-[Information] [07/10/15 1:23:04 PM] Avisynth input script
--[NoImage] LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
--[NoImage] FFVideoSource("D:\Video Unsaved\Mum's drive\Movies\test.mkv", cachefile="D:\test.mkv.ffindex")
--[NoImage] crop(236, 0, -234, 0)
--[NoImage] Spline36Resize(854,480)
--[NoImage] Trim(5500,6499)
-[Information] [07/10/15 1:23:05 PM] resolution: 854x480
-[Information] [07/10/15 1:23:05 PM] frame rate: 24000/1001
-[Information] [07/10/15 1:23:05 PM] aspect ratio: 427:240 (1.779)
-[Information] [07/10/15 1:23:05 PM] Job command line: "C:\Program Files\MeGUI\tools\x265\avs4x265.exe" --x265-binary "C:\Program Files\MeGUI\tools\x265\x86\x265.exe" --crf 20.0 --output "D:\480p test CRF20.hevc" "D:\480p test CRF20.avs"
-[Information] [07/10/15 1:23:05 PM] Process started
-[Information] [07/10/15 1:23:05 PM] Standard output stream
--[Information] [07/10/15 1:24:08 PM] avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
--[Information] [07/10/15 1:24:08 PM] avs [info]: Video colorspace: YV12
--[Information] [07/10/15 1:24:08 PM] avs [info]: Video resolution: 854x480
--[Information] [07/10/15 1:24:08 PM] avs [info]: Video framerate: 24000/1001
--[Information] [07/10/15 1:24:08 PM] avs [info]: Video framecount: 1000
--[Information] [07/10/15 1:24:08 PM] avs4x265 [info]: "C:\Program Files\MeGUI\tools\x265\x86\x265.exe" - --frames 1000 --fps 24000/1001 --input-res 854x480 --input-csp i420 --crf 20.0 --output "D:\480p test CRF20.hevc"
-[Information] [07/10/15 1:23:05 PM] Standard error stream
--[Information] [07/10/15 1:23:05 PM] yuv [info]: 854x480 fps 24000/1001 i420p8 unknown frame count
--[Information] [07/10/15 1:23:05 PM] raw [info]: output file: D:\480p test CRF20.hevc
--[Information] [07/10/15 1:23:05 PM] x265 [info]: HEVC encoder version 1.7+266-68d089360477
--[Information] [07/10/15 1:23:05 PM] x265 [info]: build info [Windows][GCC 4.9.2][32 bit] 8bit
--[Information] [07/10/15 1:23:05 PM] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
--[Information] [07/10/15 1:23:05 PM] x265 [info]: Main profile, Level-3 (Main tier)
--[Information] [07/10/15 1:23:05 PM] x265 [info]: Thread pool created using 4 threads
--[Information] [07/10/15 1:23:05 PM] x265 [info]: frame threads / pool features : 2 / wpp(8 rows)
--[Information] [07/10/15 1:23:05 PM] x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
--[Information] [07/10/15 1:23:05 PM] x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
--[Information] [07/10/15 1:23:05 PM] x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
--[Information] [07/10/15 1:23:05 PM] x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
--[Information] [07/10/15 1:23:05 PM] x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
--[Information] [07/10/15 1:23:05 PM] x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
--[Information] [07/10/15 1:23:05 PM] x265 [info]: References / ref-limit cu / depth : 3 / 0 / 0
--[Information] [07/10/15 1:23:05 PM] x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 1
--[Information] [07/10/15 1:23:05 PM] x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
--[Information] [07/10/15 1:23:05 PM] x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
--[Information] [07/10/15 1:23:05 PM] x265 [info]: tools: deblock sao
--[Information] [07/10/15 1:24:08 PM] x265 [info]: frame I: 10, Avg QP:18.91 kb/s: 12066.04
--[Information] [07/10/15 1:24:08 PM] x265 [info]: frame P: 259, Avg QP:21.13 kb/s: 2182.79
--[Information] [07/10/15 1:24:08 PM] x265 [info]: frame B: 731, Avg QP:27.03 kb/s: 261.35
--[Information] [07/10/15 1:24:08 PM] x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
--[Information] [07/10/15 1:24:08 PM] x265 [info]: consecutive B-frames: 8.6% 5.6% 11.2% 55.0% 19.7%
--[Information] [07/10/15 1:24:08 PM] encoded 1000 frames in 62.34s (16.04 fps), 877.05 kb/s, Avg QP:25.42

Edit: I tried again, this time encoding 5000 frames from a different point in the video.
[Information] [07/10/15 2:00:29 PM] encoded 5000 frames in 304.36s (16.43 fps), 824.01 kb/s, Avg QP:25.03

Not that it's still anywhere near NVEnc speed, but I'd have thought your CPU would be capable of encoding at 2x to 4x the speed of mine. Instead, I seem to be encoding at around twice your speed. Maybe I'm missing something....

[ValenNC]

In the testing we found that Hybrid uses ffmpeg/mencoder apparently for resizing if you didn't have any AVISynth filters engaged or the Always use AviSynth check box ticked which results in a substantial performance hit. I've since moved over to using Spline36resize over Lanczos which also solves the problem since it requires AviSynth.

[ЦъберТод]

I tried to find information, but I don't find it anywhere :

The lack of support of b-frames in hevc nvenc - is it a hardware limitation of Maxwell cards or is it something that nvidia needs to do in their sdk/drivers so they can be used ?

[bidomo]

Enter Adobe Media Encoder and a user over at the Adobe forums known as "nvenc4everyone". This guy (or girl) coded a full featured plugin that supports, near as I can tell, all the nvenc parameters, including 2 pass, AQ (yes, nvenc features hardware AQ) and lossless 4:4:4 for both avc and hevc. The plug in is available for free and works with AME and Premiere Pro, both CC and CS6.

This plug in is what shows nvenc true potential. At the highest quality settings, with 2 pass, it easily matches x264 at the medium preset, and while AME doesn't show the encoding frame rate a 2 pass HQ avc encode finished in faster than real time for the whole thing, which works out to roughly 2x real time for 1080p30 at 12000 kb/s.

Is there a plugin like this for Sony Movie Studio Platinum?

[sophisticles]

Enter Adobe Media Encoder and a user over at the Adobe forums known as "nvenc4everyone". This guy (or girl) coded a full featured plugin that supports, near as I can tell, all the nvenc parameters, including 2 pass, AQ (yes, nvenc features hardware AQ) and lossless 4:4:4 for both avc and hevc. The plug in is available for free and works with AME and Premiere Pro, both CC and CS6.

This plug in is what shows nvenc true potential. At the highest quality settings, with 2 pass, it easily matches x264 at the medium preset, and while AME doesn't show the encoding frame rate a 2 pass HQ avc encode finished in faster than real time for the whole thing, which works out to roughly 2x real time for 1080p30 at 12000 kb/s.

Is there a plugin like this for Sony Movie Studio Platinum?

Not the the best of my knowledge and worse Sony sold the Vegas rights to Magix (iirc), so the future of the Vegas family of video editing apps is up in the air.

For Windows nvenc I would look at Staxrip which recently updated their app and added encoding options to all hardware encoders.

[ezcapper]

looking at your samples, one pass nvenc hevc is better than x264 medium, this was a pleasant surprise. Gtx 1050 came out today if anyone wants to test:
http://www.newegg.com/Product/Product.aspx?Item=N82E16814487296&cm_re=gtx_1050-_-14-48...-296-_-Product