GPU Transcoding (Intel QuickSync and nVidia NVENC)

[Wireratt 0]

quicksync makes transcoding 1080p and 720p content en a 2000 series dual core celeron viable, but in your case with an i7 (i have an i7 with no quicksync on my main pc), you will get less cpu stressing, and not much more (i guess).

I have a 4670k in my server. I noticed cpu usage drop from 60% to below 30% turning on quik sync.

 

My server rarely needs to transcode though. I set the max upload to 10mb and it direct streams 95% of the time.

Edited March 4, 2016 by Wireratt

[Cobra 6]

Does QuickSync have the same 2 simultaneous transcoding stream limit that Nvidia NVEC has? I have tested NVEC with mcebuddy (ffmpeg) transcoding from .ts to .mp4 h.265. and it is sure nice to see the space it saves. A single stream session I could see GPU only use about 3% load on a GTX 970, but it was working. I was surprised it does not use more GPU during the process. Is QuickSync similar and minimal GPU use during this process? I saw the wiki on how to enable nvec in emby but really want to stick with stable branch and did not want to go to the trouble of swapping ffmpeg around.

 

I am waiting for a few parts to arrive but will be running i7-4790k devils canyon, unraid, emby docker and plan to utilize quick sync here, fingers crossed on it working inside docker.

[MSattler 390]

Does QuickSync have the same 2 simultaneous transcoding stream limit that Nvidia NVEC has? I have tested NVEC with mcebuddy (ffmpeg) transcoding from .ts to .mp4 h.265. and it is sure nice to see the space it saves. A single stream session I could see GPU only use about 3% load on a GTX 970, but it was working. I was surprised it does not use more GPU during the process. Is QuickSync similar and minimal GPU use during this process? I saw the wiki on how to enable nvec in emby but really want to stick with stable branch and did not want to go to the trouble of swapping ffmpeg around.

 

I am waiting for a few parts to arrive but will be running i7-4790k devils canyon, unraid, emby docker and plan to utilize quick sync here, fingers crossed on it working inside docker.

 

So once you hit the 2 stream max does Emby then just continue to use ffmpeg without QS?

[babgvant 143]

Does QuickSync have the same 2 simultaneous transcoding stream limit that Nvidia NVEC has? .

 

No, not the last time I tested. It works like a CPU when it comes to utilization.

[MSattler 390]

No, not the last time I tested. It works like a CPU when it comes to utilization.

 

Interesting, so if you have multiple transcodes going on that could present a problem if the quality is too high right?  For instance 4 transcodes going at once, with throttling enabled, if its encoding stream 3 and 4, while stream 1 and 2 are throttled, and it cannot transcode fast enough then stream 1 and 2 would hang?  

[babgvant 143]

Interesting, so if you have multiple transcodes going on that could present a problem if the quality is too high right?  For instance 4 transcodes going at once, with throttling enabled, if its encoding stream 3 and 4, while stream 1 and 2 are throttled, and it cannot transcode fast enough then stream 1 and 2 would hang?  

 

Every limited resource has a constraint somewhere. Just as it is possible to hit the point with your CPU where you can't serve more clients, the same is true of QS. That said, QS is many, many X faster than real time so it's much less likely that you will hit that point unless you put some effort into it.

[MSattler 390]

Every limited resource has a constraint somewhere. Just as it is possible to hit the point with your CPU where you can't serve more clients, the same is true of QS. That said, QS is many, many X faster than real time so it's much less likely that you will hit that point unless you put some effort into it.

 

Totally understood, just trying to figure out if an i7 with enough streams is better off without QS than with.

 

thanks!

[babgvant 143]

Totally understood, just trying to figure out if an i7 with enough streams is better off without QS than with.

 

thanks!

 

Generally you will be better off using QS than CPU.

[rcocchiararo 1]

I decided to try and convert my media so that i need no transcoding, and found some automation and whatnot to combine with sickrage and coachpotato.

 

Long story short, i ended up with an error when running:

 

ffmpeg.exe -fix_sub_duration -i in.mkv -vcodec h264_qsv -preset:v faster -map 0:0 -vb 673k -c:a:0 copy -map 0:1 -bsf:a:0 aac_adtstoasc -metadata:s:a:0 language=eng -f mp4 -threads auto -y out.mp4

 

 

I tried other presets, and also simplified the command to the bare minimun, always with the same error, which i was able to correct by the magic of google, and ending up in earlier pages of this thread:

 

 

ffmpeg.exe -fix_sub_duration -i in.mkv -vcodec h264_qsv -preset:v faster -look_ahead 0 -map 0:0 -vb 673k -c:a:0 copy -map 0:1 -bsf:a:0 aac_adtstoasc -metadata:s:a:0 language=eng -f mp4 -threads auto -y out.mp4

 

 

Now my question... if i am not wrong, the quality i get from emby's TRANSCODING is kicking what i get from converting it... it is HORRIBLE when i convert.

 

Any chance i can get an example of what emby is running?

 

I might end up running the conversion from my main pc to my server

 

PS: i also noticed, that with no QSV, conversion is slower, uses no GPU, but CPU is almos maxed, and quality is better. If i do use QSV, cpu is a bit less maxed, gpu is taxed to at least 70%, and conversion is faster and uglier. The CPU is not that good, of course, it is an intel celeron N2807 (baytrail generation).

[MSattler 390]

So just to ensure I understand the current status of this:

 

1)  Install the latest video driver on Windows

2)  Install Emby Server

3)  Enable QuickSync within Emby

4)  Transcoding will start using the GPU

 

Is that it or are other steps required?  My new i7-6700 pc shipped today and I'm looking to get QuickSync working on it.

 

Thanks! 

[babgvant 143]

 

PS: i also noticed, that with no QSV, conversion is slower, uses no GPU, but CPU is almos maxed, and quality is better. If i do use QSV, cpu is a bit less maxed, gpu is taxed to at least 70%, and conversion is faster and uglier. The CPU is not that good, of course, it is an intel celeron N2807 (baytrail generation).

 

It's worth playing with the cmdline args.

 

I'm not sure what -vb does, but if that's the target bitrate, 673k is both low and odd.

 

Also, if the QPU supports lookahead, you will get better results using that.

 

Don't use the "faster" profile when doing async transcoding. Try quality instead (assuming ffmpeg implements QS's targets).

[Latchmor 584]

...

Any chance i can get an example of what emby is running?

...

 

If I've read that correctly, you want to see the ffmpeg commands that emby uses? If so, have a look at your log files and the transcoding logs will show you all the commands being used.

[dark_slayer 103]

So just to ensure I understand the current status of this:

 

1)  Install the latest video driver on Windows

2)  Install Emby Server

3)  Enable QuickSync within Emby

4)  Transcoding will start using the GPU

 

Is that it or are other steps required?  My new i7-6700 pc shipped today and I'm looking to get QuickSync working on it.

 

Thanks! 

 

I'd also like to understand the status

 

I've done the above steps but cannot get any output. The ffmpeg process kicks off (I can see it in task manager) but no video is produced. Testing over wan on Android. It just spins the emby logo with no playback. If I change the transcode setting back to auto then video plays again (Android) just fine.

 

I installed the latest handbrake and verified that the IntelQSV preset works and uses around 15-20% CPU utilitization vs the standard x264 which hovers up to around 70% CPU

 

Relevant logs hopefully attached (edit: failed attempt was trying to playback Kung Fu Panda, switched settings and successfully played Avengers)

Edited March 14, 2016 by dark_slayer

[MSattler 390]

I'd also like to understand the status

 

I've done the above steps but cannot get any output. The ffmpeg process kicks off (I can see it in task manager) but no video is produced. Testing over wan on Android. It just spins the emby logo with no playback. If I change the transcode setting back to auto then video plays again (Android) just fine.

 

I installed the latest handbrake and verified that the IntelQSV preset works and uses around 15-20% CPU utilitization vs the standard x264 which hovers up to around 70% CPU

 

Relevant logs hopefully attached (edit: failed attempt was trying to playback Kung Fu Panda, switched settings and successfully played Avengers)

 

I'll have my i7 box on Wednesday so I may be able to tell you what happens for me.  What OS are you using?  Trying to figure out if I can still get GPU transcoding to work with Server 2k12R2 instead of using Win10.

[Happy2Play 9780]

I'll have my i7 box on Wednesday so I may be able to tell you what happens for me.  What OS are you using?  Trying to figure out if I can still get GPU transcoding to work with Server 2k12R2 instead of using Win10.

 

Quick sync is using the CPU.  Just not as processor intensive.

 

 

Intel Quick Sync Video is the name given to Intel's hardware video encoding and decoding technology integrated into some of its CPUs

 

Haven't had any problems on my old I5 3450 pc or my Xeon x3450 WHS 2011 server.

[jmgriffes 6]

Quick sync is using the CPU.  Just not as processor intensive.

Intel Quick Sync Video is the name given to Intel's hardware video encoding and decoding technology integrated into some of its CPUs

Haven't had any problems on my old I5 3450 pc or my Xeon x3450 WHS 2011 server.

 

To be more correct, QuickSync is using the GPU integrated into the CPU, the CPU is still used for some tasks on the encode, but if you've ever benchmarked them side-by-side, it's not even close on speed (quality is more questionable), and the CPU is hardly touched compared to encodes that would max out your processor otherwise.

[dark_slayer 103]

What OS are you using?

W8.1 pro w/ i7-3370k

 

 

Quick sync is using the CPU. Just not as processor intensive

Quick sync specifically uses the GPU, it just happens to be integrated into the same package as the CPU. Usually referred to as the iGPU short for integrated. It's not just harnessing gpu power though, Intel built the low level instruction set with encoding video specifically in mind ... essentially an asic

 

It's fun to see it actually used

[dark_slayer 103]

This is a bummer, feels so close. Handbrake is using QSV no sweat. Looking through the logs I couldn't make out any particular failure area, but at the client end I'm getting no audio or video

[MSattler 390]

Running Win2k12R2 on a i7-6700 and QuickSync is working.  One thing I just ran into is I had 2 streams going, a third stream started, and even though one of the streams was pretty far ahead, it did not seem to pause to allow the other stream to catch up.

 

I believe that the Intel GPU's are limited to 2 simultaneous streams, is that right?

 

If so, with throtteling on, should ffmpeg still be pausing once it is far enough ahead of playback?  Or should streams beyond the first two that use QS use just plain ffmpeg?

 

Thanks! 

[MSattler 390]

Running Win2k12R2 on a i7-6700 and QuickSync is working.  One thing I just ran into is I had 2 streams going, a third stream started, and even though one of the streams was pretty far ahead, it did not seem to pause to allow the other stream to catch up.

 

I believe that the Intel GPU's are limited to 2 simultaneous streams, is that right?

 

If so, with throtteling on, should ffmpeg still be pausing once it is far enough ahead of playback?  Or should streams beyond the first two that use QS use just plain ffmpeg?

 

Thanks! 

 

So it looks like if GPU transcoding is selected, all the ffmpeg instances will use GPU transcoding.  If there is a limit of simultaneous streams than this could be a potential problem.  

 

I ran some manual ffmpeg's, I took them from what Emby is calling for the same file with GPU transcoding, and without.  As far as I can tell the i7-6700 is much faster than the GPU transcoding?  Which seems odd because I see the direct opposite in Handbrake.  With a handbrake conversion I was seeing 120fps with GPU Transcoding.  Now the speed test I am listing were shown after 1-2 minutes of transcoding.  Is there a better way to compare numbers?

 

 

With GPU Transcoding

 

B:\Users\Administrator\AppData\Roaming\Emby-Server\ffmpeg\20160131\ffmpeg.exe -c:v h264_qsv  -i file:"\\tower\kids\The Lion King\Lion King.mkv" -map_metadata -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_qsv -pix_fmt yuv420p -preset 7 -look_ahead 0 -b:v 10680000 -maxrate 10680000 -bufsize 21360000 -vsync vfr -profile:v high -level 4.1 -force_key_frames "expr:gte(t,n_forced*3)" -flags -global_header -sc_threshold 0 -codec:a:0 libmp3lame -ac 2 -ab 320000 -af "adelay=1,aresample=async=1,volume=2" -hls_time 3 -start_number 0 -hls_list_size 0 -y "B:\Users\Administrator\AppData\Roaming\Emby-Server\transcoding-temp\Marcus.m3u8"

 

45fps speed 1.9

 

On driver 20.19.15.4300

 

49fps speed 2.0

 

Without GPU Transcoding

 

B:\Users\Administrator\AppData\Roaming\Emby-Server\ffmpeg\20160131\ffmpeg.exe -i file:"\\tower\kids\The Lion King\Lion King.mkv" -map_metadata -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 libx264 -pix_fmt yuv420p -preset superfast -crf 23 -b:v 10680000 -maxrate 10680000 -bufsize 21360000 -vsync vfr -profile:v high -level 41 -force_key_frames "expr:gte(t,n_forced*3)" -flags -global_header -sc_threshold 0 -codec:a:0 libmp3lame -ac 2 -ab 320000 -af "adelay=1,aresample=async=1,volume=2" -hls_time 3 -start_number 0 -hls_list_size 0 -y "B:\Users\Administrator\AppData\Roaming\Emby-Server\transcoding-temp\marcuswithoutgpu.m3u8"

 

138fps speed 5.7

Edited March 11, 2016 by MSattler

[dark_slayer 103]

Did you do anything special to get everything going? I'm at a loss for why it won't work at all for me in Emby but chugs along just fine with handbrake

[MSattler 390]

Did you do anything special to get everything going? I'm at a loss for why it won't work at all for me in Emby but chugs along just fine with handbrake

 

Not really, I installed Windows Server 2012 R2, upgraded the video driver and then installed Emby.  

 

Not using it right now, I need to do some more testing.  When using it and keeping throttling enabled I kept getting freezes.

[dark_slayer 103]

After running a few updates and a reboot I'm happily using QS instead of Auto in transcode settings, I removed my logs from above. Not sure what was changed, but I had one issue resuming a video after starting up (h264, nothing special). The ffmpeg vampire was left behind afterwards. I played a few others from the beginning no issue. Then went to reproduce the issue and my next two videos that I tried to resume played just fine. I'll keep an eye out and post the logs if it happens again

[MSattler 390]

After running a few updates and a reboot I'm happily using QS instead of Auto in transcode settings, I removed my logs from above. Not sure what was changed, but I had one issue resuming a video after starting up (h264, nothing special). The ffmpeg vampire was left behind afterwards. I played a few others from the beginning no issue. Then went to reproduce the issue and my next two videos that I tried to resume played just fine. I'll keep an eye out and post the logs if it happens again

 

Do me a favor, can you try having like 3-4 transcodes going and seeing how it behaves?

 

Just curious is the 3rd/4th transcodes end up having playback freeze because of inability to keep up.

 

I am playing around with using QS and disabling throttling to see if that works better. 

[MSattler 390]

@@Luke

 

Did someone hardcode webm to be limited to 7 threads?  I'm doing some GPU transcoding testing, and with throttling disabled, and transcoding threadcount set to max I am seeing really good performance so far with 2-3 threads.

 

However, I'm noticing that only webm is being limited to 7 threads, versus all other transcodes show threads set to 0.  By setting threads to 0, ffmpeg will relinquish CPU time if required, and helps with multiple transcodes.  This is working much better for me than the throttling I had been using for standard cpu transcoding.

 

Thanks!