GPU Transcoding (Intel QuickSync and nVidia NVENC)

[Waldonnis 148]

Those jellyfish samples are great for general testing of h.264 and HEVC, and short enough that it's not a big deal to use them even for software encoding/decoding testing.  You'll need additional samples for other codecs (mpeg2, vpx, etc), if you want to test those as well.  There's a page of samples used for Kodi testing that should contain a lot of other files/links, but I don't have the link handy at this moment (easy to search for).  I doubt you'd see the same type of issue with other codecs, personally, but testing new hardware is always a good exercise (and fun).

 

This case is a bit odd, though. I could probably create a sample for testing an mpeg2 transport stream that doesn't begin with an I-frame to check that issue locally on IB (and maybe against nvenc) if needed, but it won't really help without an upstream fix to test against.

[denz 501]

I put the three jellyfish to a new library and out of the three jeelyfish-30-mbps-hd-h264 when I play it on ipad 2 it is hardly using any cpu but all the others cpu is 100%. 

 

I have also noticed when I enable hardware encoding/decoding the dashboard is reporting direct playing but nothing plays but it shouldn't be able to play 1080 video on ipad 2 maybe I am wrong probable am. 

 

I attached some ffmpeg logs so maybe someone can have a look. 

 

Intel® Core™ i5-7200U Processor is my cpu

 

In this example when I play 4k file it says direct playing but on the ipad there is only a static photo and once the bottom bar goes to 100% after couple of minutes it goes to transcoding and the video plays. Scrap that disabled hardware acceleration and it is still the same starts with direct playing and then it is transcoding.

 

Thank you 

ffmpeg-20170722-134036.log

ffmpeg-20170722-134110.log

ffmpeg-20170722-134350.log

Edited July 22, 2017 by denz

[denz 501]

Few other interesting things I discovered installed handbrake and selected a wtv file with selected video codec h.264 Intel qsv and handbrake encoded a mpeg2 5gb file very quickly in 13 minutes but even then the cpu was at 100%  then I selected h264 codec and it has taken 37 minute to encode the file. 

 

If I try to watch the same wtv file in ipad and I have set hardware acceleration to intel quick sync it is not working same error as before so it is interesting how come it qsv works in handbrake but not in emby.

[Waldonnis 148]

In the ffmpeg reports, it looks like it's not being told to use hardware decoding, so those will use software decoding and you should see a lot of load with that particular command line (especially with the HEVC file).  You would have to add the proper decoder option prior to the input file (-i) for it to decode with hardware (-c:v h264_qsv or -c:v hevc_qsv).  That command line also is more for benchmarking/checking the chosen decoder since it just dumps the raw uncompressed video to null rather than re-encoding it (just FYI).  That's pretty good performance for an i5 doing a software decode of HEVC, though 

 

Handbrake may actually be failing to decode with hardware, but not letting you know and just software decoding it silently.  I haven't looked at their code in quite some time and don't know just how much detail their logging provides regarding that stuff, so I can't be sure of what it's really doing.  I suppose it's possible too that their code is based on a revision of libav prior to the commit/regression mentioned in the bug report, so it wouldn't run into the same issue.

 

Can you attach the server and transcode logs from the iPad playback testing?  Sounds like an unrelated issue, but I'm sure Luke/ebr would like more detail there and might need its own thread.  I'm pretty sure you're right about it being unable to handle a 1080p h.264 file (specs claim 720p30 profile 3.1; iOS also doesn't like mkv containers).  The client may be misreporting the limitations of the device, leading it to try direct playing first.

 

I have a few mpeg2 samples somewhere locally.  I'll try to create a sample with odd initial I-frame placement and check it with my local ffmpeg build.  I compile my own and pull upstream changes weekly.  I doubt I'll see anything different, but it's worth a shot to see if any more recent commits have fixed it.

Edited July 22, 2017 by Waldonnis

[Waldonnis 148]

Grabbed a sample reported to have the same problem and it still errors out with the ffmpeg that I compiled yesterday.  Interestingly, mpeg2_cuvid doesn't have any issues with the file, so it seems like it's only mpeg2_qsv that does.  Looks like something that will have to be solved upstream (ffmpeg folks).  I'll look at the file a bit and see if I can come up with something in the meantime.

[denz 501]

Thanks Waldonnis with your comments i will grab logs of handbrake and the other logs of emby it is saying that is using it but I can't be sure apart that there is a big difference between the time it takes to encode when i select qsv and when not selected.

[Waldonnis 148]

I'd be curious to know if hardware transcoding is working for you in Emby on something other than mpeg2 transport stream files.  If you turn on hardware encoding/decoding and force a transcode by lowering the max bitrate of your iPad client, do the jellyfish files transcode and play back properly?  I'm guessing that you will probably have some issues with hardware decoding your recorded television files if they're all mpeg2 transport streams, but the jellyfish samples are encoded differently and you shouldn't see the same decoder problem crop up with them (fingers crossed).

 

If everything works fine with non-mpeg2 files, I'm thinking the best way to handle it in the meantime is to omit hardware decoding for mpeg2 when using QuickSync until the problem is addressed upstream.  mpeg2 shouldn't be too hard to decode for most processors anyway, so it shouldn't really increase the load too much and it's better failing entirely in situations like this.  It would also allow hardware decoding for more difficult codecs like HEVC rather than having to disable the use of the whole block because of a problem with decoding mpeg2 in certain situations.  Another option would be to implement a "fall back to software decoding" solution, but that's a bit more complex to implement.

 

I don't deal with many mpeg2ts files so I'm not sure how common it is for these files to have this type of issue...and it's proving difficult to detect which files may trip up the decoder.  Given what I've seen in this sample, it would likely require a deeper analysis of each file to even spot a situation like this.  I could probably come up with a way, but it's more analysis than I'd expect Emby to do for every file in a library (short-duration frame dump followed by some output parsing is the "easiest" way).  I'm still looking to see if there are any options that might get around this, but I'm not too hopeful, given how ffmpeg handles decoding and seeking.

[denz 501]

Many transcode files are being generated and all the jellyfish videos work the 4k one does take 3 minutes to start. I have attached logs. 

 

All the recordings that have been auto converted work with quicksync or at least I think it does since the gpu core clock goes from 300 to 1000 but don't understand why does ffmpeg still uses such a high percentage of cpu, with hardware acceleration enabled or disabled it is the same. 

 

As you have mentioned it seems to be only an issue with mpeg2 none of them work so it is an upstream issue. 

ffmpeg-transcode-37c518e6-145a-4716-a68b-cbb583376ff9.zip

ffmpeg-transcode-05027e87-ea83-4533-afef-990e578256ee.txt

ffmpeg-transcode-aee41bd5-2417-4d89-8b28-946d1ec22c07.txt

ffmpeg-transcode-livetv recording with automatic conversion to mkv.txt

server-63636418366.txt

Edited July 23, 2017 by denz

[Waldonnis 148]

Okay, something wacky is going on in those logs.  Running some tests locally against the same jellyfish sample (on Ivy Bridge, so I can only check the h.264 file), I'm seeing the same high CPU use and ffmpeg is claiming that it's only using partial hardware acceleration for some odd reason.  In fact, I'm doubting that it's using the hardware at all.  I'm looking over ffmpeg commits now to see what might be going on here.

 

Even stranger, I just ran a test with a build of ffmpeg that I did in April and it's obviously using the hardware (significantly faster, less processor load, and the report claims that it's using MFX unlike the newer build)....

 

Update: Found the source of my problem, but not yours yet.  Can you try this ffmpeg build and see if it helps (pick 32 or 64 depending on your OS): 32bit / 64bit.  Using versions compiled after 13 June will just cause the same issue that I'm running into, and versions prior to March don't include a few changes that might help your HEVC/h.264 situation (not the mpeg2 stuff, unfortunately).

Edited July 23, 2017 by Waldonnis

[denz 501]

That build made a difference when I have hardware acceleration off ffmpeg goes over 90% while it is on it stays around  72% than it disappears and it starts again maybe that is why there are so many ffmpeg files but the video plays perfectly.

 

MPEG2 videos still produce blank screen and I have to force close ipad app. 

 

server-63636619049.txt

ffmpeg-transcode-96d55c56-ba78-497c-a150-75d757239685.txt

ffmpeg-transcode-161e40ab-3610-435c-ae21-ad0e32f427c5.txt

ffmpeg-transcode-29521fc2-1085-4ec5-942b-e48cddc5d034.txt

ffmpeg-transcode-32466a55-2104-48e4-ae9a-b2e6ff508dd6.txt

ffmpeg-transcode-2bb194fb-2fef-4b46-b569-99a15ddca21c.txt

ffmpeg-transcode-f7d53f5f-2751-486a-b195-5009f80c35a6.txt

[Waldonnis 148]

That build made a difference when I have hardware acceleration off ffmpeg goes over 90% while it is on it stays around  72% than it disappears and it starts again maybe that is why there are so many ffmpeg files but the video plays perfectly.

 

MPEG2 videos still produce blank screen and I have to force close ipad app. 

 

Sorry for the delay.  Looking over the logs, it definitely looks a little better and the system load sounds like it's more in line with what I'd expect.  I did notice that one of the transcode logs indicate a failure (log ending with ca21c) and I'm not sure why.  Another indicated that it didn't encode any frames (log ending with 9685), but that transcode started at the very end of the file so that didn't surprise me.  Is it handling the HEVC test file equally well?  In previous logs, it seemed to not be using the hevc_qsv decoder, so I'm curious to see if that's still the case.

 

There are still some issues with ffmpeg builds later than that one, but I'm watching the commits to see if anything gets changed.  I think I have it narrowed down to one or two specific changes, but I haven't had time to properly read through and understand them yet.  From what I can tell, my issue seems to happen because there is a discrete GPU installed as well (nVidia card, which is my primary) and, without getting into too much boring detail, it's just not auto-detecting the right GPU to use for the QSV encoder.

[Gerrit507 24]

Same here. It's only using qsv for encoding but not for decoding.

Nevertheless, you made great improvements on hardware acceleration. If only ffmpeg would work like it should...

[Gerrit507 24]

I've just tested nvidia acceleration. Here are my results:

h264 -> h264 works fine

h265 8bit -> h264 works fine

h265 10bit -> h265 video stops every 10 seconds and gives artifacts  

 

 

I've got a 1050Ti. It should be able to decode h265 10bit. I think it's an issue with ffmpeg. I still got much better results than with my J3455 and QS enabled.

 

EDIT:

 

I've found the solution:

https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNvDecode

 

For 10bit video partial accelerated decoding is needed. I think we need an if condition that checks if 10 bit video is processed when using cuvid. 

 

EDIT2:

Emby actually doesn't even set the "-hwaccel cuvid" flag that according to the ffmpeg wiki shouldn't be set and it's still choking. Strange...

Edited July 30, 2017 by Gerrit507

[denz 501]

I played the hevc and it plays but what is curious why are there so many ffmpeg logs and in the task manager I can see it disappear and appear so that is probable why and the gpu clock keeps switching between 300 and 1000.

 

For mpeg2 it is a bug since there is an open ticket https://trac.ffmpeg.org/ticket/6418

however it says for live streams but it is a same error as I get for recordings.  

 

 

ffmpeg-transcode-81d259f4-5e3c-43f2-9a57-ab82712fb184.txt

ffmpeg-transcode-5e4104d9-02a6-4264-9c47-ad55c834db48.txt

ffmpeg-transcode-a75c8611-e466-4a42-9f44-5220f5273b96.txt

ffmpeg-transcode-0c1654bd-ba1b-4820-9e26-fbeb41b1684a.txt

ffmpeg-transcode-8da3ca85-bac2-4d9a-a7fe-32548d432b4e.txt

ffmpeg-transcode-553cecf3-fc1b-4837-b181-7666b33f7e46.txt

[Gerrit507 24]

I played the hevc and it plays but what is curious why are there so many ffmpeg logs and in the task manager I can see it disappear and appear so that is probable why and the gpu clock keeps switching between 300 and 1000.

 

For mpeg2 it is a bug since there is an open ticket https://trac.ffmpeg.org/ticket/6418

however it says for live streams but it is a same error as I get for recordings.

 

Maybe it's because of multiple threads?

 

Yes, hevc plays fine as long it is 8bit.

[Waldonnis 148]

I've just tested nvidia acceleration. Here are my results:

h264 -> h264 works fine

h265 8bit -> h264 works fine

h265 10bit -> h265 video stops every 10 seconds and gives artifacts  

 

 

I've got a 1050Ti. It should be able to decode h265 10bit. I think it's an issue with ffmpeg. I still got much better results than with my J3455 and QS enabled.

 

EDIT:

 

I've found the solution:

https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNvDecode

 

For 10bit video partial accelerated decoding is needed. I think we need an if condition that checks if 10 bit video is processed when using cuvid. 

 

EDIT2:

Emby actually doesn't even set the "-hwaccel cuvid" flag that according to the ffmpeg wiki shouldn't be set and it's still choking. Strange...

 

Emby doesn't use a hwaccel, so that's not the issue.  They tried it before at my behest and there was some odd problem that cropped up on Windows that none of us could figure out (DXVA context issue that didn't happen when run manually).  Can you post the transcode log of a 10-bit HEVC file that's showing those issues with NVENC?  As for partial acceleration, I have no idea why that's noted as being required for 10-bit and haven't looked at the source (seems strange, but there are probably reasons for it...or the docs are outdated).

 

Emby should be using hardware decoding for hevc_qsv transcodes if it's enabled (should see a -c:v hevc_qsv prior to the -i).  If it's not, that's something for Luke to look at 

[Luke 42077]

we do use hevc_qsv .

[Luke 42077]

Actually, sorry, it's disabled because it will have limited hardware support compared to h264 decoding. So we can add it back but we'll probably need to make it an option so that you can indicate your hardware supports it.

[Waldonnis 148]

Actually, sorry, it's disabled because it will have limited hardware support compared to h264 decoding. So we can add it back but we'll probably need to make it an option so that you can indicate your hardware supports it.

 

Makes sense, since there's no reliable way to detect it with ffmpeg alone short of trying to use it.

[Gerrit507 24]

Ok, now it's getting really strange. Like I said I wasn't able to play any of my 10 bit media. I downloaded some jellyfish samples and they played perfectly fine, even though the framerate and the quality was much higher than my media. I compared the samples with the tool MediaInfo to my media. I saw that the samples doesn't have sound, but jellyfish also provides a 10bit sample with sound, so I downloaded it. Transcoding speed went down to about x0.3-x0.5 and it stuttered like crazy exactly like my media, sometimes the video stucks and loops the first few frames. I went into transcoding settings and put "audio amplification when downmixing" down to 1 and transcoding speed was doubled! Nevertheless, playing the video still wasn't possible.

 

I'm almost sure that it have to be related to the combination of transcoding audio and 10bit hevc video. Is there a way to disable audio transcoding entirely?

 

EDIT: I rebooted my whole pc. The jellyfish videos now play fine, with and without sound. My media gives me the same results that I was used to. It stucks exactly every 10 seconds and sometimes produces artifacts or a green screen. Another thing I noticed is that movies with DTS audio are transcoded 3-5 times slower than with AC3 and comparable video quality. Furthermore, I've found two 10bit videos that only have ac3 stereo and they play perfectly fine.

downmixing1-log.txt

downmixing2-log.txt

no-sound-log.txt

Edited July 31, 2017 by Gerrit507

[Waldonnis 148]

DTS tracks have a higher bitrate compared to AC3, as well as other technical differences, so it will take more effort to decode/transcode.  I won't get into the other differences between the two codecs or which is subjectively "better", since that's been argued around the net for over a decade     Once you get into lossless codec comparisons, things get even more complicated.

 

Looking at the logs, two of them are using hevc_cuvid for decoding (which is good).  FPS is on the low "barely keeping up" side, but without being able to test locally, I'm not sure what may be going on there (could be I/O-related since the source files were on a network share, but maybe not).  The downmixing2 log is obviously the worst performer, but it's not using hardware decoding so the FPS numbers are around what I would expect.  Both downmixing1 and 2 are also converting TrueHD, which is a bit harder on the CPU compared to lossy AC3.

 

Reminds me, I need to play with hardware scaling one of these days to see how good/bad it is and what it does to performance, but that's another matter.

 

Side note: 140Mbit is a tad over the highest you'll ever see even on a 4k disc (spec maxes out at 128Mbit, but you'll often find lower).  Streaming 4k content is usually signifficantly lower bitrates than that for bandwidth reasons - highest I've seen so far was 30Mbit, and even that was somewhat rare (Netflix/Amazon/VUDU are usually in the 15Mbit-ish range).  I initially chose the 140Mbit file because it was the closest I could get to disc bitrates, and trying the 250Mbit sample is WAY overkill unless you just want to really put your hardware to the test (and network, since you stored it on a SMB share) 

[Gerrit507 24]

I'm now able to transcode most of my hevc 10bit movies, which is great   I don't know what the actual issue was but after a reboot it worked fine. I've tested two hevc 10 bit uhd movies transcoded to 10Mbit HD H264 at the same time and it worked perfectly. I think that one reason was that I used the same machine as server and client before, which was just overkill for it.

 

Those movies that made the most issues have HDR actually. According to mediainfo they have the BT.2020 standard, which defines stuff like color depth and space, and my other movies that are transcoded fine have BT.709, which means they are "SDR". I'm unable to play them on my machine with MPC or Windows 10 Video Player, too. It seems like this new color format is barely supported in any software. If somebody knows how to make it work with nvdec, let me know. 

[mbze430 1]

Hey Guys,

 

I've just installed emby and have issues with QS. I've a ASRock N3150 running Ubuntu 16.04, it's capable of hw-decoding H265 8 Bit at least, couldn't test 10 bit yet. If I want to play a H265 movie via browser the playback won't start. I looked in the log files and saw that ffmpeg is always started with the switch

 

"-codec:v:0 h264_qsv"

 

although it's H265 content and fails with

 

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

 

Does anybody have suggestions on that?

 

have you been able to resolve this?  I am planning to test NVENC in Ubuntu 17.04 but in a VM on an esxi host.  Just wanted to make sure that Ubuntu can transcode using a Nvidia card.

[Gerrit507 24]

have you been able to resolve this?  I am planning to test NVENC in Ubuntu 17.04 but in a VM on an esxi host.  Just wanted to make sure that Ubuntu can transcode using a Nvidia card.

 

I can tell you that NVENC and NVDEC works fine on Windows 10 as long as you don't have HDR content. I haven't tested it on Ubuntu yet. As far as I know QS refuses to decode but does encode.

 

NVENC seems to be a little bit difficult on Linux. You'll proably need to build ffmpeg with nvenc enabled first. Then you'll need a proper display driver. I don't think that the non proprietary drivers that come with the linux kernel will be able to use nvenc. Everthing is explained here: http://developer.download.nvidia.com/compute/redist/ffmpeg/1511-patch/FFMPEG-with-NVIDIA-Acceleration-on-Ubuntu_UG_v01.pdf

 

If you can, I would recommend you to use Windows. Dealing with such stuff is unfortunately always messy on Linux...

 

Are there any news on the QS side?

Edited August 2, 2017 by Gerrit507

[Waldonnis 148]

I'm now able to transcode most of my hevc 10bit movies, which is great   I don't know what the actual issue was but after a reboot it worked fine. I've tested two hevc 10 bit uhd movies transcoded to 10Mbit HD H264 at the same time and it worked perfectly. I think that one reason was that I used the same machine as server and client before, which was just overkill for it.

 

Those movies that made the most issues have HDR actually. According to mediainfo they have the BT.2020 standard, which defines stuff like color depth and space, and my other movies that are transcoded fine have BT.709, which means they are "SDR". I'm unable to play them on my machine with MPC or Windows 10 Video Player, too. It seems like this new color format is barely supported in any software. If somebody knows how to make it work with nvdec, let me know. 

 

Well, Pascal cards are reportedly capable, but I'm not sure about the ffmpeg side of things (at least for hardware en/decoding).  Can you post just the ffmpeg command line from a transcode log?  I'm curious to see how Emby is telling ffmpeg to handle the colourspace conversion.  I have a BT.2020 sample file here, so I'll poke at it when I get a chance (within the limits of my 970).  A quick-and-very-basic test transcoded the BT.2020 source to a BT.709/h.264 file just fine when specifically told to do so using the appropriate _nvenc encoder (doing the same for a BT.709/HEVC file worked fine as well).  It's not using hardware decoding during the process, though...again, due to me having a 970 *sigh*.  Easy enough to test adding hardware decoding manually if you want to, though.  You just have to specify the pix_fmt and colorspace for the output for a basic colorspace conversion test (yuv420p and bt709 are well supported by players/monitors).

 

Not sure why you're having playback issues, though, as BT.2020 isn't really that new.  MPC-HC should decode it just fine, since it uses LAV...I can't speak to whether or not it'll use hardware to decode, though, when doing so since my card can't do hardware decoding of Main10 files.  You can try installing a more recent LAV filters version and make sure that MPC-HC or -BE is using them (uncheck the internal ones if they're not getting it done).  My sample plays fine locally with MPC-HC latest and madVR/latest LAV version being used in place of MPC-HC's internal LAV (software decoded, obviously).