GPU Transcoding (Intel QuickSync and nVidia NVENC)

[tp90254 0]

It's possible that the hardware decoder (or really, the driver for it) didn't have any issues with the SD stream, so it succeeded.  Bear in mind that the decoder issues that both Luke and I have mentioned don't imply anything is wrong with the input file/stream - quite the contrary, actually, as I'm pretty convinced based on my own experience that it's a driver issue that just pops up at times for no discernible reason.  I tried to encode one of my files three different times and it crashed at a different point each time... *shrugs*  Other times, it succeeded without issue.  Others have reported similar issues in various tool-related threads, so we're not alone there.

 

I just disable hardware decoding now (or just omit the option to use it) when encoding or working with video files lately.  Granted, most of what I transcode/re-encode are static files and I rarely need to output a stream, but outside of HEVC/VP9, software decoding of MPEG-2 and h.264 is often fast enough on modern processors for it not to make much of a difference.

 

Back on topic, though, from the successful log, nothing different is being done there, or at least nothing unexpected compared to the HD log.  Definitely check back when you get a chance to run manual tests and let us know how that went without the hardware decoding.

 

Thanks again -- I ran tests, and definitely got some interesting results:

1. I recorded a 10 minute segment into a .ts stream (using my other DVR software)
2. I copy/pasted the ffmpeg command line from the logfile and only changed the filenames to match what I recorded

Results:

• Whilst using h264_qsv encoder, it Initially got stuck at the "Press [q] to stop..." line. However, after I re-ran, it actually worked with an encode speed of 1.4x! Sometimes it worked, other times it did not, so it lends credence to your hypothesis that there is a "quirk" with the driver.
• I tried the libx264 encoder, and it always worked with an encode speed of 0.3x, so the GPU gets a significant improvement.
• I then installed the Intel Driver Update utility, and updated the graphics driver. I got similar results with h264_qsv as with the old driver, and sometimes it worked, others it did not.
• I saw your and Luke's comment on the hardware decoder, and removed the "-c:v mpeg2_qsv" from the command line, and not only did things get more reliable, the speed IMPROVED to 2.0x!

 

So -- based on Luke's comment, there doesn't seem to be a way to remove the QSV decoder from the command line? Are there any workarounds?

Lastly, if I plan to use the DVR feature of Emby, is there a way to perform the transcode as a post-processed task after the recording is completed?

 

Thanks so much -- it's nice to get meaningful feedback!

[Luke 42077]

In a future release, we'll separate the encoding/decoding settings.

[tp90254 0]

In a future release, we'll separate the encoding/decoding settings.

Thanks -- in the interim, is there any solution at all  (i.e. changing a config file) given that it seems that I have to use the h264_qsv encoder in order to watch live TV?

[Waldonnis 148]

Thanks again -- I ran tests, and definitely got some interesting results:

1. I recorded a 10 minute segment into a .ts stream (using my other DVR software)
2. I copy/pasted the ffmpeg command line from the logfile and only changed the filenames to match what I recorded

Results:

• Whilst using h264_qsv encoder, it Initially got stuck at the "Press [q] to stop..." line. However, after I re-ran, it actually worked with an encode speed of 1.4x! Sometimes it worked, other times it did not, so it lends credence to your hypothesis that there is a "quirk" with the driver.
• I tried the libx264 encoder, and it always worked with an encode speed of 0.3x, so the GPU gets a significant improvement.
• I then installed the Intel Driver Update utility, and updated the graphics driver. I got similar results with h264_qsv as with the old driver, and sometimes it worked, others it did not.
• I saw your and Luke's comment on the hardware decoder, and removed the "-c:v mpeg2_qsv" from the command line, and not only did things get more reliable, the speed IMPROVED to 2.0x!

 

So -- based on Luke's comment, there doesn't seem to be a way to remove the QSV decoder from the command line? Are there any workarounds?

Lastly, if I plan to use the DVR feature of Emby, is there a way to perform the transcode as a post-processed task after the recording is completed?

 

Thanks so much -- it's nice to get meaningful feedback!

 

Excellent news and results    I wish I could remember which driver version I had before I updated it last month, as I never ran into any problems with hardware decoding back then.  Oh well, maybe Intel will fix it in a future release.  Hopefully, Luke can get the separated encoder/decoder options implemented soonish as well to make it possible to work around driver issues like this.

 

For Luke: Is there a case for using hardware decoding for codecs other than HEVC from a "server calling ffmpeg" perspective?  Perhaps to help reduce the load in the case of multiple simultaneous transcoded streams?  I'm just curious since all of this falls way outside of my use cases.

[Luke 42077]

Excellent news and results    I wish I could remember which driver version I had before I updated it last month, as I never ran into any problems with hardware decoding back then.  Oh well, maybe Intel will fix it in a future release.  Hopefully, Luke can get the separated encoder/decoder options implemented soonish as well to make it possible to work around driver issues like this.

 

For Luke: Is there a case for using hardware decoding for codecs other than HEVC from a "server calling ffmpeg" perspective?  Perhaps to help reduce the load in the case of multiple simultaneous transcoded streams?  I'm just curious since all of this falls way outside of my use cases.

 

Can you clarify that a little more? i'm not sure what you mean.

[Waldonnis 148]

Can you clarify that a little more? i'm not sure what you mean.

 

Sure!  I'm mostly just wondering why use the hardware decoding in any case at all (basically, why even bother adding that to the ffmpeg command line)?  I'm just trying to understand what the benefit is or what it's there to help with...and if that command line switch is even needed.  If it helps ease the system load measurably during multiple simultaneous transcodes or something like that, I could definitely understand it.  I'm just curious, since I rarely transcode anything during playback and only have a small client count, so those kinds of benefits are things I wouldn't know a lot about (for educational purposes on my part, not criticism at all  ).

 

In the case of HEVC, I can definitely see the use, since software decoding is much harder CPU/load-wise, so there's no need to clarify there.

[Luke 42077]

Well that's what i said but go back 10 pages or so to see the response the last time i tried to take it away

[Waldonnis 148]

Well that's what i said but go back 10 pages or so to see the response the last time i tried to take it away

 

LOL, fair enough.  I admit I hadn't followed this thread too closely and didn't see those posts (big d'oh to me for not searching before asking).  Thanks for pointing me in the right direction there     I guess it makes sense, given what the other users posted about the loads on their systems.  I'm so used to not needing transcoding that I just didn't know what kind of impact it might have if it was omitted.

[tp90254 0]

LOL, fair enough.  I admit I hadn't followed this thread too closely and didn't see those posts (big d'oh to me for not searching before asking).  Thanks for pointing me in the right direction there     I guess it makes sense, given what the other users posted about the loads on their systems.  I'm so used to not needing transcoding that I just didn't know what kind of impact it might have if it was omitted.

Wouldn't my situation be a valid use case? I have a low power server, and would like to occasionally watch live TV from my SiliconDust tuner on my Roku. Given that the Roku cannot directly decode MPEG2, a transcode must take place on the server. My Celeron J1900 would not be able to transcode the live TV feed, and I could not then watch it on my Roku. 

[Waldonnis 148]

Wouldn't my situation be a valid use case? I have a low power server, and would like to occasionally watch live TV from my SiliconDust tuner on my Roku. Given that the Roku cannot directly decode MPEG2, a transcode must take place on the server. My Celeron J1900 would not be able to transcode the live TV feed, and I could not then watch it on my Roku. 

 

It's the decoding part that I was asking about specifically.  You're correct that the encoding part of the process would be very intensive on a J1900 if it were using software encoding (e.g. the x264 encoder or ffmpeg's libx264).  Prior to encoding, though, the video stream has to be decoded. Hardware can handle this, but as we've seen here, the driver for the hardware decoder can have some bugs/issues.

 

Think of it as if you were playing the file directly on your J1900's monitor.  During playback, the file is decoded/uncompressed, then passed to the video/sound cards for you to see (it's a tad more complicated than this in reality, but it's not important for this discussion).  Many video cards and modern CPUs have built-in hardware decoders that support certain codecs so they can do these operations without impacting the regular CPU or GPU load (aside from some very minor overhead).  Even without hardware decoding, though, decoding h.264 or MPEG-2 isn't too difficult for a CPU to do and, while it does add some load to the system, it's not normally too bad if you're only decoding one file at a time.

 

When transcoding, the same process happens, but rather than the decoded video/audio streams being passed to the video/audio cards, they are fed into an encoder (hardware or software) so they can re-encode the streams into the desired format(s).  Software encoders are notoriously processor-intensive and accounts for almost all of the load you see on a system when transcoding a file.  With your J1900, software encoding would be prohibitively taxing on the system in many cases, as you well know, but it can likely handle software decoding a single video stream without much issue (even many lower-power ARM processors can handle software decoding 1080p MPEG-2 and h.264 at acceptable framerates).

 

What removing that option from ffmpeg did was tell ffmpeg to decode the video stream using the software decoder, then re-encode the uncompressed output of that using QuickSync's hardware encoder.  If the transcoding speed was acceptable in that test, then the processor is capable of software decoding at sufficient rate for one transcoding task.  You'd have to try multiple simultaneous streams to know just how many it could handle before framerates dip low enough to be unwatchable.

 

FYI, the HEVC codec is much harder for processors to decode without dedicated hardware decoders, which is why I mentioned that in my question to Luke, but we're not dealing with that in your case.

Edited October 19, 2016 by Waldonnis

[tp90254 0]

It's the decoding part that I was asking about specifically.  You're correct that the encoding part of the process would be very intensive on a J1900 if it were using software encoding (e.g. the x264 encoder or ffmpeg's libx264).  Prior to encoding, though, the video stream has to be decoded. Hardware can handle this, but as we've seen here, the driver for the hardware decoder can have some bugs/issues.

 

 

Sorry -- I missed the decoding part in your post. I fully get the asymmetrical nature of some codecs and why they're designed like that. Anyways, the good news is that even with the hardware decoder enabled, I was able to get the stream working on the Roku. Once I noticed the intermittent stream failures on the test cases I ran, I just retried initiating the stream from the Roku if it failed the 1st time, and lo and behold it worked! It's very nice -- time shifting works too, so I'll likely switch over from my Plex setup over the next few days.

 

Another FYI (also related to your last comment): when I ran the tests using only hardware encoding (decoding in S/W), I tried a 2nd stream in parallel to see the effects. One stream ran at 2.0x, adding a 2nd stream still worked with both streams running around 1.5x. Each ffmpeg instance took about 40% of the CPU (with the other 20% going to MS AntiMalware Service -- that needs to be looked into).

 

If I can add my 2c to the discussion feature discussion (after less than 24 hrs. of experience with Emby -- The reason I'm switching to Emby is exactly because of the added flexibility of configuration options. The FFMPEG "enhancements" are clearly marked as "use at your own risk". I would advocate for even more flexibility and allow the user to a spot to arbitrarily add their own command line string for FFMPEG settings.

 

In any case -- thanks for the feedback, looks like I'm good to go for the near term.

[tp90254 0]

In process of continuing to set up Emby, I am noticing that even though I have "quicksync" selected for Hardware Acceleration -- it doesn't seem to use the qsv_h264 coder. Here's a sample from the logfile:

 

C:\MyProgramFiles\ffmpeg\bin\ffmpeg.exe -fflags +genpts -async 1 -vsync -1 -i "http://127.0.0.1:8096/LiveTv/LiveStreamFiles/f974a3a0609047c992457ada45e9be6c/stream.ts"-t 00:29:59.699 -sn -codec:v:0 libx264 -force_key_frames "expr:gte(t,n_forced*5)" -vf "yadif=0:-1:0" -pix_fmt yuv420p -preset superfast -crf 23 -b:v 25000000 -maxrate 25000000 -bufsize (25000000*2) -vsync -1 -profile:v high -level 41 -map_metadata -1 -threads 0 -codec:a:0 aac -strict experimental -ab 320000 -y "Z:\AvaShare\video\TVDVR\Series\Dinosaur Train\Season 1\Dinosaur Train S01E11 Night Train; Fossil Fred-1.mkv"

 

Also, I requested the "veryfast" profile in the settings, but the logfile is showing "superfast".

 

Looking through the logfile, the encoding speed is consistent with the speed I noticed when testing ffpmeg with software encoding.

 

Thx

Edited October 26, 2016 by tp90254

[Luke 42077]

In process of continuing to set up Emby, I am noticing that even though I have "quicksync" selected for Hardware Acceleration -- it doesn't seem to use the qsv_h264 coder. Here's a sample from the logfile:

 

C:\MyProgramFiles\ffmpeg\bin\ffmpeg.exe -fflags +genpts -async 1 -vsync -1 -i "http://127.0.0.1:8096/LiveTv/LiveStreamFiles/f974a3a0609047c992457ada45e9be6c/stream.ts"-t 00:29:59.699 -sn -codec:v:0 libx264 -force_key_frames "expr:gte(t,n_forced*5)" -vf "yadif=0:-1:0" -pix_fmt yuv420p -preset superfast -crf 23 -b:v 25000000 -maxrate 25000000 -bufsize (25000000*2) -vsync -1 -profile:v high -level 41 -map_metadata -1 -threads 0 -codec:a:0 aac -strict experimental -ab 320000 -y "Z:\AvaShare\video\TVDVR\Series\Dinosaur Train\Season 1\Dinosaur Train S01E11 Night Train; Fossil Fred-1.mkv"

 

Also, I requested the "veryfast" profile in the settings, but the logfile is showing "superfast".

 

Looking through the logfile, the encoding speed is consistent with the speed I noticed when testing ffpmeg with software encoding.

 

Thx

 

Please always attach complete log files.  Instructions on how to do that can be found here:

 

https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/

 

Thanks.

[tp90254 0]

Please always attach complete log files.  Instructions on how to do that can be found here:

 

https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/

 

Thanks.

Thanks for the info.. Last time I posted a log, I felt guilty about all the vertical real-estate it took

 

I am attaching the logfile Log.txt, server log ServerLog.txt as well as a screengrab of the transcoding settings I am using.

 

Thanks

Edited October 26, 2016 by tp90254

[Luke 42077]

And the Emby Server log?

[tp90254 0]

And the Emby Server log?

Sorry -- it's attached on the original post now.

[Luke 42077]

Well I would need to see the log from when the server originally started, although you can check this on your own. There will be lines like these

2016-10-26 11:59:51.5078 Info MediaEncoder: Decoder available: h264_qsv
2016-10-26 11:59:51.5078 Info MediaEncoder: Decoder available: mpeg2_qsv
2016-10-26 11:59:51.5078 Info MediaEncoder: Decoder available: vc1_qsv
2016-10-26 11:59:51.5293 Info MediaEncoder: Encoder available: h264_qsv

If you dont' see those then it means your ffmpeg build does not support quick sync.

[Luke 42077]

Oh, and these settings currently only apply to playback and sync. They have not yet been applied to the recording process.

[tp90254 0]

Oh, and these settings currently only apply to playback and sync. They have not yet been applied to the recording process.

OK -- that explains it. I do see the above "Decoder available: h264_qsv" message in my logfile. But since the settings don't apply to recordings, it's moot.

 

What I am noticing, are incomplete recordings, and some duplicate filenames (i.e. the same filename with a "-1" appended) for the few recordings I have scheduled. My ideal process would be to just record and save the mpeg2, then post-process the mpeg2  into a h264 when server load is light, and lastlyt the original once the conversion is complete. Is this possible?

[Luke 42077]

We do the conversion on the fly.

[Elinombrable 0]

Does Xpenology support QuickSync?

 

I have Xpenology installed on a J1900 that should be able to do QuickSync but im getting an error (log attached). Maybe its not support in Xpenology and only for Windows.

 

Thanks in advance.

Log.txt

[Luke 42077]

Does Xpenology support QuickSync?

 

I have Xpenology installed on a J1900 that should be able to do QuickSync but im getting an error (log attached). Maybe its not support in Xpenology and only for Windows.

 

Thanks in advance.

 

Even if it does if you read the feedback in this thread it seems like VA API is the better way to go.

[Swynol 375]

for Quicksync transcoding to work is it true that i shouldnt have another graphics card installed and have specific intel drivers installed? 

 

i'm running an i3 3420 which has the Intel HD 2500. But i have a low powered ati graphics card plugged in and my HDMI from that to my AVR.

[Swynol 375]

nevermind, using a custom ffmpeg managed to get it work. now to test with roku and hopefully cure my playback issues.

[kenzo84 0]

Hello

I have i7 6700K

Ubuntu 15.04


Intel HD 530 2GB


MB ASUS H110M-K
8GB

 

Can somebody help me to install ffmpeg with gpu transcoding, I will pay for time spent on it

Edited November 15, 2016 by kenzo84