GPU Transcoding (Intel QuickSync and nVidia NVENC)

[sh0rty 714]

Nice one with the latest 3.2.20.2 release @@Luke @@Waldonnis ! Proper Nvidia en- + decoding and no device errors in my ffmpeg log. Streams run buttery silk, fps are pretty good for my card, not much CPU usage.

 

Happy Camper, thanks!!!

[Luke 42077]

Thanks for the feedback.

[lifespeed 42]

I tried NVENC hardware acceleration a couple months back, and it didn't seem to work.  I tried it again today, transcoding to an Android phone on LTE, and it worked!  CPU utilization on my i7-6800K w. nVidia GTX770 went from 90% to 15% (I use slow and 22 for transcode quality settings).  Yay!

 

But then I tried seeking using the scrub bar, which seems to be the acid test.  Sadly, Emby for Anroid mobile closed.  When I restarted the video it had lost it's place in the movie.

 

So it seems progress is being made, but it is still not that reliable when you ask it to seek.  Keep up the good work,  hope the logs are helpful.  It started out resuming from the correct location, but then when I tried to seek it all fell apart.

server-63633815487.txt

ffmpeg-transcode-fdedc0c7-a71d-4828-980c-2040033653ae.txt

ffmpeg-transcode-1a3881e3-f53c-4793-915a-9a8ca8080206.txt

ffmpeg-transcode-78113993-b5e3-450a-af4e-d0d8ecbcda8c.txt

ffmpeg-transcode-b721147f-3939-44b2-a2a7-1a265c91d24f.txt

ffmpeg-transcode-4775e090-ecee-478c-8b96-237147a41ab8.txt

ffmpeg-transcode-0f6f9b6a-c035-4334-9cdc-e9f664fe67e3.txt

[Luke 42077]

@@lifespeed what version of the android app is installed? make sure you are on the latest version. thanks !

[lifespeed 42]

@@lifespeed what version of the android app is installed? make sure you are on the latest version. thanks !

Two day old beta, I'll update to today.  I am not sure where to find the version number in the app, Google Play is claiming yesterday's version is 3.8.34.

 

I know you fixed the Android mobile client seek problems with a recent beta, and I do have this version.  This particular seek problem seems to be associated with using NVENC transcoding on the server (doesn't work with seek), vs CPU transcoding (works with seek).

 

Also, please see this thread regarding orphan ffmpeg processes, which may or many not have anything to do with this problem.

 

Edit:  tried today's Android mobile beta, and it stopped playing when I tried to seek with the server set to NVENC transcoding.  It did start a second ffmpeg process, this may be related.  The fact that it works for the client when CPU transcoding and not when NVENC transcoding may not be that significant.  I would think that second ffmpeg process is a problem.

Edited June 23, 2017 by lifespeed

[Luke 42077]

Got it, thanks.

[nague 5]

In some very occasional situation, ffmpeg failed with nvenc:

 

[h264_nvenc @ 0x3ff9be0] InitializeEncoder failed: invalid param (8)

Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

 

This situation appears when emby doesn’t have any media information for the mkv file, so I guess emby is always transcoding, without max bit rate if no max bandwidth needed.

 

Off course we could/should investigate the root cause of this situation, but in the other hand, I’m still thinking that a “CPU fallback” will really help… This situation could be handle as well as the two streams limitation on nvidia consumer card.

 

Sorry to insist: is the “CPU fallback” a possible feature ?

emby.log

Edited June 27, 2017 by nague

[Luke 42077]

Automatic CPU fallback is something we plan to add in a future update. thanks !

[lifespeed 42]

Two day old beta, I'll update to today.  I am not sure where to find the version number in the app, Google Play is claiming yesterday's version is 3.8.34.

 

I know you fixed the Android mobile client seek problems with a recent beta, and I do have this version.  This particular seek problem seems to be associated with using NVENC transcoding on the server (doesn't work with seek), vs CPU transcoding (works with seek).

 

Also, please see this thread regarding orphan ffmpeg processes, which may or many not have anything to do with this problem.

 

Edit:  tried today's Android mobile beta, and it stopped playing when I tried to seek with the server set to NVENC transcoding.  It did start a second ffmpeg process, this may be related.  The fact that it works for the client when CPU transcoding and not when NVENC transcoding may not be that significant.  I would think that second ffmpeg process is a problem.

 

 

In some very occasional situation, ffmpeg failed with nvenc:

 

[h264_nvenc @ 0x3ff9be0] InitializeEncoder failed: invalid param (8)

Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

 

This situation appears when emby doesn’t have any media information for the mkv file, so I guess emby is always transcoding, without max bit rate if no max bandwidth needed.

 

Off course we could/should investigate the root cause of this situation, but in the other hand, I’m still thinking that a “CPU fallback” will really help… This situation could be handle as well as the two streams limitation on nvidia consumer card.

 

Sorry to insist: is the “CPU fallback” a possible feature ?

 

Is it possible these two issues are related?

[nague 5]

From my understanding, it's two different issues with the same consequence: it's working with cpu decoding and not with nvenc decoding.

 

 

 

- orphan ffmpeg process rapidly reach the 2 threads limit on nvidia consumer card

 

- some decoding parameters are not supported with nvenc decoding

 

[lifespeed 42]

From my understanding, it's two different issues with the same consequence: it's working with cpu decoding and not with nvenc decoding.

 

 

 

- orphan ffmpeg process rapidly reach the 2 threads limit on nvidia consumer card

 

- some decoding parameters are not supported with nvenc decoding

 

Maybe that is why I can sometimes seek once using transcoded Android mobile client (second ffmpeg process), but a second seek attempt causes playback to stop.

 

Devilishly complicated stuff, I can see why this is so difficult to get working perfectly.

[nague 5]

Maybe that is why I can sometimes seek once using transcoded Android mobile client (second ffmpeg process), but a second seek attempt causes playback to stop.

I have the exact same problem when transcoding with nvenc decoding.

[wsramahi 7]

Hi all, i am glad i found this post about NVENC transcoding, i was tring to explain the issue im having in a different thread and found you guys, my setup is like this

 

server: win 8.1

emby server: 3.2.20.0

nvidia: quadro M2000 Maxwell (GM206)

nividia Driver: 22.21.13.8205

CUDA: 5.2

CPU: Intel i7 6700

RAM: 16Gb DDR3

HDD: 2xSSD Evo 850 raid 0

Emby for Android TV: 1.4.17g

FFmpeg: 20170613 today i updated it to 20170628

 

i am monitoring this setup since 13, June, and initially was perfectly alright, but i noticed only on emby for android tv app hangs after around 10 minutes (nexus player stb,amazon fire tv ), web browser on any device and emby for IOS is ok, logs saying error with aac and mux overhead, i thought maybe the emby for android tv internal player needs updating!? hope this issue can be resolved.

 

 

here is the logs: movie play back time exactly at 2017-06-30 17:53:00.0178

ffmpeg-transcode-80963b35-70a6-4d7b-bfa3-fffc9c02b1d5.txt

server-63634377600.txt

Edited June 30, 2017 by wsramahi

[Luke 42077]

and you're saying that does not happen with nvenc disabled?

[wsramahi 7]

and you're saying that does not happen with nvenc disabled?

 

i just tested my setup, and yes disabling NVENC every thing works just fine, only a very high cpu usage (50%~75%), i also tested seeking on my setup when nvenc is enabled and it works great only on Quadro New Feature Driver (QNF), i have only an hanging issue with emby for android tv (nexus player and amazon fire tv).

[lifespeed 42]

Not sure how much is common between Android mobile and Android TV, but seeking with NVENC fails while seeking with CPU works fine.  Also, seeking with Android mobile results in extra ffmpeg processes as the original ffmpeg process from the last location in the video does not close in a timely fashion.  Given the two-thread limit on nVidia consumer cards, this could result in failure after the first seek.

[wsramahi 7]

Not sure how much is common between Android mobile and Android TV, but seeking with NVENC fails while seeking with CPU works fine. Also, seeking with Android mobile results in extra ffmpeg processes as the original ffmpeg process from the last location in the video does not close in a timely fashion. Given the two-thread limit on nVidia consumer cards, this could result in failure after the first seek.

I didnt try the consumer cards, actually the limited streams on the consumer cards made me seek different solution.

 

based on nvidia developers website, we can get a decent Maxwell card like the Quadro M2000 with unlimited streams exactly what i have, this card can not transcode 4k/8k.

 

seeking i tested was more than 6 times without any issue, cpu utilization was max of 60% with 2 full HD blueray movies and 5 full HD tvhead live tv streams, and performance was unbelievable on total of 7 streams and still i can have more streams to use, i only didnt know how to resolve nexus tv/amazon fire tv issue!

 

Sent from my ONEPLUS A3000 using Tapatalk

[bradford 9]

Hi all, i am glad i found this post about NVENC transcoding, i was tring to explain the issue im having in a different thread and found you guys, my setup is like this

 

server: win 8.1

emby server: 3.2.20.0

nvidia: quadro M2000 Maxwell (GM206)

nividia Driver: 22.21.13.8205

CUDA: 5.2

CPU: Intel i7 6700

RAM: 16Gb DDR3

HDD: 2xSSD Evo 850 raid 0

Emby for Android TV: 1.4.17g

FFmpeg: 20170613 today i updated it to 20170628

 

i am monitoring this setup since 13, June, and initially was perfectly alright, but i noticed only on emby for android tv app hangs after around 10 minutes (nexus player stb,amazon fire tv ), web browser on any device and emby for IOS is ok, logs saying error with aac and mux overhead, i thought maybe the emby for android tv internal player needs updating!? hope this issue can be resolved.

 

 

here is the logs: movie play back time exactly at 2017-06-30 17:53:00.0178

 

Does this thread sound like the issue you're having?

Edited July 2, 2017 by bradford

[wsramahi 7]

Does this thread sound like the issue you're having?

 

Well, yes! looks the same issue, i did test lots of IOS devices with emby app and web stream on windows, IOS and android and there is no issues i noticed, maybe the player on emby app for android TV is outdated or something! hope this can be resolved.

[denz 501]

I recently purchased a kaby lake pc and tried intelquick sync but it doesn't seem to be working when I try to watch a tv recording on ipad I get immediately two log files attached below I tried other videos and the same but picture is always blank and no sound. I have installed the recent intel mediapack 2017 is there anything I am missing. Thanks 

Log1.txt

Log2.txt

[Luke 42077]

I recently purchased a kaby lake pc and tried intelquick sync but it doesn't seem to be working when I try to watch a tv recording on ipad I get immediately two log files attached below I tried other videos and the same but picture is always blank and no sound. I have installed the recent intel mediapack 2017 is there anything I am missing. Thanks 

 

Looks like it is not supported for that particular file so we'll need to figure out how to detect that and just use the cpu.

[Waldonnis 148]

Looks like it is not supported for that particular file so we'll need to figure out how to detect that and just use the cpu.

Might be related to this report on the ffmpeg tracker, but it's hard to know without looking at a sample.  Barring deeper analysis of the file, I'm not sure there is a way to detect it if the situation is the same (first I-frame located further into the stream).

 

Does turning off hardware decoding result in a successful transcode with video present?  If so, a short-term work-around may be to disable hardware decoding for mpeg2 until there's a disposition on that bug report (at least QSV...not sure if mpeg2_cuvid shows the same issue).

Edited July 16, 2017 by Waldonnis

[denz 501]

Everything works when I turn off hardware decoding. I just wanted to be sure that I have enabled correct settings is there a sample video on the internet that I can test when I enable hardware decoding that it is decoding that file in hardware. 

[lorac 118]

@@denz you can download the files below to test HW Accel.

Excellent and thank you!  Sorry for the delay in replying...despite my friends' beliefs, I do sleep every so often 

 

I've been using three jellyfish video samples for my tests (http://jell.yfish.us/), so we may as well continue that trend so the results can be reproduced easily by anyone interested.  They're only 30secs long and are relaxing to look at too  . We'll be testing three files in particular, so go ahead and download these:

• jellyfish-30-mbps-hd-h264.mkv (h.264 30Mbit)
• jellyfish-30-mbps-hd-hevc.mkv (HEVC Main 30Mbit)
• jellyfish-140-mbps-4k-uhd-hevc-10bit.mkv (HEVC Main10 140Mbit - a bit over the average UHD BD bitrate; overkill for this particular test, but it's nice to keep around for encoding tests/experiments)

Since Skylake supports HEVC Main and h.264, we know that the first two videos can be decoded by your hardware.  The third is HEVC Main10 which is not supported by hardware on Skylake, so I expect it to decode using the CPU.  At any rate, once the videos are downloaded, run the following command for each of them (substituting the filename for FILE....and the one L in NUL is not a typo):

ffmpeg -hwaccel auto -i FILE -map 0:0 -c:v rawvideo -hide_banner -stats -report -loglevel 56 -f null NUL

This command tries to automatically detect the hardware acceleration method to use for decoding, then "transcodes" the file to raw video with the output going to...well, nowhere - it won't leave a file on the drive since we're not interested in viewing it (using null output is great for benchmarking as well).  I've purposely mapped only the video stream since audio isn't important for this case.  I'm also increasing the loglevel to trace to see everything possible so we can verify how it's making its hardware decoding decisions and what ends up being used.  Actual performance isn't being measured here, so ignore the framerates you see in the report files that each run generates (loglevels that high combined with reporting overhead can skew the results anyway).

 

To give you an idea of what I'm looking for in the output: I'm expecting to see auto using dxva2 for decoding for the files it can decode with hardware (you'll find things like "Using D3D9Ex device" and a reference to a pixel format called "dxva2_vld" in the output).  It may mention "MFX" in there instead, but that's what we're trying to find out (MFX refers to Intel's QuickSync en/decoding library, libmfx).  On the Main10 file, it should try to do the same thing, but can't so you'll probably find a line like "Error creating the DXVA2 decoder" in the output.  It should still decode, though, but will be using the CPU instead so you'll see it complete successfully.

 

Also, please run the command below to just do a CPU decode of the HEVC Main file.  I know roughly what the report will look like, but it will help answer an outstanding question I had about that generation of processor but could never test...and it's always nice to have a "control" testcase/dataset available for comparison:

ffmpeg -i jellyfish-30-mbps-hd-hevc.mkv -map 0:0 -c:v rawvideo -hide_banner -stats -report -loglevel 56 -f null NUL

You should now have four files named something like ffmpeg-20170421-001322.log in the directory.  Just zip those up together and attach that to a reply and we should be all set.  Thanks so much for testing this!  And apologies for any typos or crazy wording...I just woke up 

[denz 501]

That is a perfect I will do a test this weekend.