Nvidia NVENC

[bmoses 9]

I decided to play around with this setting yesterday to see if i could transfer some of the load off of my CPU. I have an AMD FX-8310 CPU and a geforce 660 TI video card. I enabled the settings on the server page and tested out a few things forcing them to transcode (by setting a max bitrate below the video bitrate) playing to my nexus player.

 

I confirmed through some GPU utilities that the video card was doing the transcoding, but my issue is the playback on the nexus player was not smooth. i don't know how best to describe it, choppy? the audio never cut out, it was only the video that was having issues. If i turned off NVENC and went back to the CPU transcoding everything played perfectly.

 

Are there any other settings i need to setup within the nvidia control panel? is there a certain version of ffmpeg i need to use? this was on server version 3.2.29.0, thanks!

[csadoian 36]

Hi, I have also been experimenting with Nvidia NVENC.  I bought a cheap Nvidia card (a Gforce 710, uses Kepler microarchitecture) and did some tests.  I also found the playback to be somewhat choppy, like it's either dropping frames or momentarily freezing every few seconds.

 

I installed the latest version of FFMPEG and it seemed to help a bit, but it hasn't eliminated it completely.

 

What utility do you use to verify the GPU is doing the transcoding?

[bmoses 9]

Hi, I have also been experimenting with Nvidia NVENC.  I bought a cheap Nvidia card (a Gforce 710, uses Kepler microarchitecture) and did some tests.  I also found the playback to be somewhat choppy, like it's either dropping frames or momentarily freezing every few seconds.

 

I installed the latest version of FFMPEG and it seemed to help a bit, but it hasn't eliminated it completely.

 

What utility do you use to verify the GPU is doing the transcoding?

 

its an EVGA card so i installed their utility suite for overclocking which also shows card usage.

[csadoian 36]

MSI makes the Geforce 710 I am using, but I didn't like their utility software.

 

I found GPU-Z and it works pretty good.  When my system is transcoding the GPU load averages 7%, while the Video Engine load is around 28%.  Don't see much reduction in CPU load, which disappoints me.  I thought the whole idea of using hardware acceleration was to make the GPU do most of the work and reduce the computer's CPU load

 

Of course, it could be because I'm using a low end card, but I expected to see SOME reduction in CPU load.

[csadoian 36]

Geez, while I was running a transcoding test prior to sending the last message I failed to notice the server began eating memory again.  After I wrote the message I looked up at the TV and the video was frozen, so I looked at the server and the memory had ballooned from 1.2GB to 7.9GB (out of 8GB in the machine).  Prior to this situation this memory runaway condition only happened to me when I used an external player to view the Live TV channel.  Not this time, I was using the internal player on an Android TV box and it still went crazy.  If you're interested, see my thread on this problem:

 

https://emby.media/community/index.php?/topic/50429-memory-issue-with-external-player/

[Waldonnis 148]

Both the 660Ti and 710 use the first iteration of the video block and both have more limited h.264 support compared to their successors, but performance shouldn't be that bad for a single stream.  I'd need to see a trancoding log to see what options are being used by ffmpeg with either before commenting on what may be causing stuttering/buffering on playback.  IIRC, even though Emby can specify a hardware decoder/encoder pair, it's likely still copying frames to/from system memory which will impact system load a bit.  I seem to recall that some filters couldn't be used without doing this, but it's something I'd have to look up again to be sure.  It is possible to keep the decoded frames in the card's memory to feed the encoder directly, but there may be drawbacks to enabling something like that due to Emby using complex filters pretty often (it's just one more command line option to do so; I use it for simple preview or temporary transcodes since it lets me do other stuff while it's churning through 2hr+ videos).  Also, if the hardware decoder and encoder aren't used together, then it'll end up using system memory anyway.

Edited August 28, 2017 by Waldonnis

[csadoian 36]

Attached is a transcode log from an OTA 1080i local station.  While I was watching it I saw some "breakups" (might have been an OTA signal problem), but none of the stuttering I had seen before.  I am using the most current ffmpeg 64 bit program.

 

 

ffmpeg-transcode-6fe8c234-961b-44ba-978a-6061227b66b1.txt

[csadoian 36]

By the way, I should mention I am using a 240GB SSD for my transcode temporary path.

[bmoses 9]

here are some logs with several tests. from what i could see anything that was 720p played fine. anything that was 1080p had the choppy playback issue. I tried several different 1080p and 720p movies as well as a 1080i live TV stream. only issue with that one was after about 5 seconds of playing it stopped. i had to pause the stream, wait about 5 seconds and then start it again and it played fine after that. seemed like a buffer or something needed to build up first.

 

CPU usage for all tests was averaging 8% for ffmpeg. without NVENC turned on its 70%+ initially. i'm also using a SSD for my transcode temp directory.

ffmpeg-transcode-4748f8df-e3b2-44dc-ae2a-d7ad1c2edbb0.txt

server-63639536767.txt

ffmpeg-remux-650b28d8-d188-42eb-bdbe-cac216fef1cc.txt

ffmpeg-transcode-70c03e25-c936-4f26-821b-00076c52d20e.txt

ffmpeg-remux-b81507d2-10f6-4aec-a1bb-d6458f82cf72.txt

ffmpeg-transcode-1b95d14e-bf3e-4bb4-9936-3b98267a3d21.txt

[csadoian 36]

You have an 8 core AMD processor running at 3.4Ghz, I wouldn't think FFMPEG would suck up 70% CPU.  You said initially, without the hardware assist what does it average out at?

 

With hardware decoding turned on, when transcoding a 1080i stream it generally runs around 20% CPU, GPU 7% and Video Engine 25%.

 

With hardware decoding turned off the CPU runs around 30%, GPU 2% and Video Engine 0%.  So it makes a difference, but not as much as I would have thought (or hoped).

[Waldonnis 148]

Attached is a transcode log from an OTA 1080i local station.  While I was watching it I saw some "breakups" (might have been an OTA signal problem), but none of the stuttering I had seen before.  I am using the most current ffmpeg 64 bit program.

 

If this is a live stream, you may partially be at the mercy of I/O.  Once the card gets past the already-written parts, it'll slow down drastically until it matches or falls slightly below framerate of the original stream (what I'd give to transcode into the future   ).  It's likely that it'll encode a lot faster, but the demuxer and decoder can only feed the encoder as they get the data and decode it.  Interlacing probably isn't helping either.  I think there's hardware deinterlacing support in ffmpeg with nvenc, but I've never used/tried it and would have to look it up...and who knows how well it works.  Also, it looks like you're using software decoding for the mpeg2 stream (just FYI).

 

Is the performance similarly slow for static progressive content (like a non-interlaced movie file)?  If so, I may have an idea you can try to see if it helps, but only if hardware decoding is used as well.

[csadoian 36]

If this is a live stream, you may partially be at the mercy of I/O.  Once the card gets past the already-written parts, it'll slow down drastically until it matches or falls slightly below framerate of the original stream (what I'd give to transcode into the future   ).  It's likely that it'll encode a lot faster, but the demuxer and decoder can only feed the encoder as they get the data and decode it.  Interlacing probably isn't helping either.  I think there's hardware deinterlacing support in ffmpeg with nvenc, but I've never used/tried it and would have to look it up...and who knows how well it works.  Also, it looks like you're using software decoding for the mpeg2 stream (just FYI).

 

Is the performance similarly slow for static progressive content (like a non-interlaced movie file)?  If so, I may have an idea you can try to see if it helps, but only if hardware decoding is used as well.

 

Yes, performance is slow for non-interlaced content as well.

 

Regarding the software decoding for MPEG2, the only ones I have checked off in Emby are H264 and VC1 (the defaults).  I think I tried clicking off MPEG2 but when I played back a recording it didn't have any video, only audio.  That might have been when I was testing a different Nvidia card (one that I discovered did NOT support hardware decoding), so maybe I should test it again, to be sure.

 

For a card such as mine (Geforce 710 based on Kepler), what formats should it be able to decode?  Emby lists H264, HEVC, MPEG2, MPEG4 and VC1.  Again, at the present time I only have H264 and VC1 clicked off.

[Waldonnis 148]

Yes, performance is slow for non-interlaced content as well.

 

Regarding the software decoding for MPEG2, the only ones I have checked off in Emby are H264 and VC1 (the defaults).  I think I tried clicking off MPEG2 but when I played back a recording it didn't have any video, only audio.  That might have been when I was testing a different Nvidia card (one that I discovered did NOT support hardware decoding), so maybe I should test it again, to be sure.

 

For a card such as mine (Geforce 710 based on Kepler), what formats should it be able to decode?  Emby lists H264, HEVC, MPEG2, MPEG4 and VC1.  Again, at the present time I only have H264 and VC1 clicked off.

 

That card should support complete (fixed function) acceleration for h.264, VC1, mpeg1, mpeg2, and mpeg4 (ASP).  In fact, both the 710 and 660Ti share the same feature set and probably the same physical video block circuitry, so the same goes for bmoses' card on the decoding/encoding front.

 

I also quickly looked at filtering and it looks like it's pretty basic on the hardware front (scalers and deinterlacers, mostly; stuff that's easy for a GPU), so copying the frames into system memory is probably the only way to go barring a more complex "mixed" approach (e.g. hardware scaling, but the rest using the usual software filter chain)...which looks to be a pain.  I may look into it when I get more time, but it's low on my "curious about this" list.  Basically, a full hardware transcode is probably not in the cards for something like Emby, since employing filters and filter_complex is commonplace.

[csadoian 36]

After I wrote the message to you I did some searching and found this page:

 

https://en.wikipedia.org/wiki/Nvidia_PureVideo

 

which gave the the same info you gave me.  So I turned on hardware decoding for MPEG2 and MPEG4 as well as H264 and VC1.  The only one my card does not support is HEVC, which was not introduced into Nvidia cards until January of 2015 (according to the article).

 

I tested various live channels and didn't see any blank video like I was seeing before I changed to the GT 710.

 

Thanks for the info.

Edited August 29, 2017 by csadoian

[Waldonnis 148]

No prob     VP8 and VP9 are also in the mix of codecs out there with some hardware support, but I never remember which cards support them fully....and I doubt most here have anything encoded with either (aside from a few samples and tests that I keep *grins*).

[Waldonnis 148]

here are some logs with several tests. from what i could see anything that was 720p played fine. anything that was 1080p had the choppy playback issue. I tried several different 1080p and 720p movies as well as a 1080i live TV stream. only issue with that one was after about 5 seconds of playing it stopped. i had to pause the stream, wait about 5 seconds and then start it again and it played fine after that. seemed like a buffer or something needed to build up first.

 

CPU usage for all tests was averaging 8% for ffmpeg. without NVENC turned on its 70%+ initially. i'm also using a SSD for my transcode temp directory.

 

I'm not sure why you'd get choppy or stuttering playback with 1080p content, given the rate of transcode the logs you posted indicate.  ~4x native framerate is pretty respectable, especially considering it's not too far from the performance of my 970 (Maxwell).  There may be other factors at work in your case.  Does the quality degrade mostly after seeking?  Any particular scenes in Guardians Vol. 2 that show it most often?  I have both movies here, but still have a full BD copy of GotGv2 handy on the drive that I can play with since I haven't finished my 3D encodings of it.

 

If you're seeing this a lot after seeking, Luke's going to be introducing some changes to when keyframes are generated in the next server version that should help.  It would show up as some artifacting/macroblocking that persists for a bit after seeking.  Also, what device/client are you using for playback?  I know it's in the server log, but I haven't gotten to it yet and figured I'd ask 

[bmoses 9]

I'm not sure why you'd get choppy or stuttering playback with 1080p content, given the rate of transcode the logs you posted indicate.  ~4x native framerate is pretty respectable, especially considering it's not too far from the performance of my 970 (Maxwell).  There may be other factors at work in your case.  Does the quality degrade mostly after seeking?  Any particular scenes in Guardians Vol. 2 that show it most often?  I have both movies here, but still have a full BD copy of GotGv2 handy on the drive that I can play with since I haven't finished my 3D encodings of it.

 

If you're seeing this a lot after seeking, Luke's going to be introducing some changes to when keyframes are generated in the next server version that should help.  It would show up as some artifacting/macroblocking that persists for a bit after seeking.  Also, what device/client are you using for playback?  I know it's in the server log, but I haven't gotten to it yet and figured I'd ask 

 

hey thanks for taking a look! in all tests i started playing each video from the beginning and had the choppiness within the first 10-15 seconds. i didn't play them for very long so i don't know if it would have cleared up, but i'm guessing it wouldn't. also i didn't do any seeking so that didn't cause it. i saw no degradation in quality either, they all looked good minus the choppy playback. all playback was tested using a nexus player.

 

the guardians vol 2 was a high bitrate 1080p rip with DTS-MA 7.1. the avengers one was the other 1080p but it was normal DTS 5.1 audio. the 720p ones all had DTS 5.1 audio too.

[csadoian 36]

hey thanks for taking a look! in all tests i started playing each video from the beginning and had the choppiness within the first 10-15 seconds. i didn't play them for very long so i don't know if it would have cleared up, but i'm guessing it wouldn't. also i didn't do any seeking so that didn't cause it. i saw no degradation in quality either, they all looked good minus the choppy playback. all playback was tested using a nexus player.

 

the guardians vol 2 was a high bitrate 1080p rip with DTS-MA 7.1. the avengers one was the other 1080p but it was normal DTS 5.1 audio. the 720p ones all had DTS 5.1 audio too.

 

I asked this before but I think the question got lost in the shuffle ... are you using the "stock" ffmpeg.exe that comes with Emby?  If so, try going to ffmpeg.org and get the latest version.  As I mentioned previously, when I first started playing with NVENC I experienced choppiness but after I switched to the latest version of ffmpeq it seems to have cleared up for the most part.

[bmoses 9]

I asked this before but I think the question got lost in the shuffle ... are you using the "stock" ffmpeg.exe that comes with Emby?  If so, try going to ffmpeg.org and get the latest version.  As I mentioned previously, when I first started playing with NVENC I experienced choppiness but after I switched to the latest version of ffmpeq it seems to have cleared up for the most part.

 

i'm not using the one that comes with emby. i can't remember right now which one it is, but it was from a may or june release this year. i'll find the most recent one and give it another go tomorrow and report back.

[csadoian 36]

I'm using ffmpeg v3.3.3 x64 (release version)

[PrincessClevage 175]

I also have a 710 over clocked 300 CPU and 200memory I think, plays everything fine except for high bit rate 4K video. I have open gl enabled in ET. I have server and client on the same htpc and I found that all of my live tv channels are transcoded and for some reason the audio is presented as ac3 (DD) but it only plays in 2channel stereo, if you have ac3 audio pass through disabled in ET client (this give volume control back to audio control in ET client) then this forces the ET client to perform a decode of the ac3 stream so my htpc is performing an encode and decode which presents itself as choppy playback etc, as soon as you enable ac3 pass through and let the amp handle audio, picture is fine again.

Not sure if this is relevant to your setups

Sorry for the original typos, I have to turn off auto correct on itap phone app:-/

Edited September 1, 2017 by PrincessClevage

[bmoses 9]

I'm using ffmpeg v3.3.3 x64 (release version)

 

i'm using ffmpeg-3.3.1-win64-static i'll find the one you are on or newer and retest.

[bmoses 9]

nope, still having issues

[bmoses 9]

ok, here is some more testing to help narrow it down. I tested on 2 different nexus players, the web player, and android mobile (my phone). The only devices that had issues with using NVENC to do the transcoding were the nexus players. android mobile and the web player played it perfectly. so i'm guessing something with the way NVENC is transcoding something the nexus player doesn't like/can't handle?

 

also a side note, switching quality mid-stream when it was already transcoding left an orphaned ffmpeg process still transcoding. when i tested my phone it was set to 720p-3mbps. after it played a few seconds i switched it to 1080p-5mbps. a new ffmpeg process was launched and the original one stayed running/processing.

[csadoian 36]

ok, here is some more testing to help narrow it down. I tested on 2 different nexus players, the web player, and android mobile (my phone). The only devices that had issues with using NVENC to do the transcoding were the nexus players. android mobile and the web player played it perfectly. so i'm guessing something with the way NVENC is transcoding something the nexus player doesn't like/can't handle?

 

also a side note, switching quality mid-stream when it was already transcoding left an orphaned ffmpeg process still transcoding. when i tested my phone it was set to 720p-3mbps. after it played a few seconds i switched it to 1080p-5mbps. a new ffmpeg process was launched and the original one stayed running/processing.

 

What version of Android are the Nexus players running?

 

The Nexus players, they are wireless only, right?  Are they 2.4Ghz only or 2.4/5Ghz?