GPU Transcoding (Intel QuickSync and nVidia NVENC)

[mjb2000 47]

I've followed the steps in the wiki but cannot get ffmpeg working on my laptop i3 3217u but have successfully used q264 with the script mentioned earlier 

Confusingly while testing your dll got overwritten by automatic updates a couple of times.

 

Manually running the command: ffmpeg -t 30 -i "D:\MyVideo.avi" -map 0:0 -c:v h264_qsv -b: 800000 -s 640x480 -report -loglevel debug QSV-Test.mkv

Results in this error (log attached), I've googled for similar errors with no success: 

 

[h264_qsv @ 051f21a0] MFXVideoCORE_SyncOperation(): -17

Video encoding failed

 

http://pastebin.com/embed_js.php?i=rj7X6nPU

 

 

Thanks for the info and the checks you have already completed. I noticed that in the log it says "Intel Media SDK API version 1.4" - This is quite old, I'm not sure if this is due to an old driver or the fact that this is an old chip (perhaps the latest version of the API this chip supports is 1.4) - Either way, I would have hoped that the code within h264_qsv could cope with these older chips (like q264 is able to do) - but perhaps this is the problem?

 

Another thought, can you try adding -r 25 to the ffmpeg test command line - perhaps the issue is that it doesn't like the native frame rate of the source video? The -r 25 isn't a long term solution, but it might help point us in the right direction.

 

Oh, and can you confirm OS and if you are running from the console or via remote desktop?

[Indypendence 1]

Hi there mjb2000 and first of all, thanks for all the hard work!

 

I have actually bought a GTX970 to use for transcoding, and even though I know things are still heavily under development, it's a big interest of mine to get it running.

I got your latest release of ffmpeg.exe (ffmpeg + h264_qsv + libnvenc) and when I launch ffmpeg it tells me that it's built with libnvenc, as it should.

 

Now, I'm trying to get it to encode something, but it always returns me:

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

I have the latest nvidia drivers installed and I'm running windows 7 on an AMD A8-3850 cpu with 16gb memory. (And as said a GeForce GTX970 which has nvenc support).

 

The input command I used was:

ffmpeg -i input.mp4 -b: 10000k -s 1980x1080 -r 30 -c:v libnvenc output.mp4

am I doing something wrong? I've tried to look for solutions, but I'm lost here.

[mjb2000 47]

Try -b:v (this specifies the video bitrate in a similar way that -c:v specifies the video codec).

 

Hopefully this will solve it. I'm guessing your are running the latest nVidia drivers if you have only just got the card? (My old January 2014 drivers didn't work, but the latest ones did).

 

I've also not tried a 10mbit stream (which you've requested here) - maybe just try 1000k (1mbps) at least for testing purposes, and we can take it from there.

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[Indypendence 1]

Okayy... thanks for the help so far.

The suggestions you had, about reducing the bitrate and how to call them didn't help.

I did check my drivers, and I had the drivers from December 2014, but there was an update, because they just released the GTX960, so I updated my drivers, and what do you know, it works!

So, good for reference: My 347.25 drivers work.

 

I'm a bit saddened about it's performance though. It encodes at 54 fps. As I read before in this thread: a simple celeron j1900 can outperform that. So my next question: are there already presets included? The traditional libx264 encoder had a preset ultrafast. Is such a thing available for libnvenc?

Edited January 26, 2015 by Indypendence

[mjb2000 47]

Okayy... thanks for the help so far.

The suggestions you had, about reducing the bitrate and how to call them didn't help.

I did check my drivers, and I had the drivers from December 2014, but there was an update, because they just released the GTX960, so I updated my drivers, and what do you know, it works!

So, good for reference: My 347.25 drivers work.

 

I'm a bit saddened about it's performance though. It encodes at 54 fps. As I read before in this thread: a simple celeron j1900 can outperform that. So my next question: are there already presets included? The traditional libx264 encoder had a preset ultrafast. Is such a thing available for libnvenc?

 

54fps doesn't sound any good at all. My GTX660 did +200fps. Can you post a debug logfile and also add -map 0:0 to the command line (to process video only). Also take a look at your CPU usage during the encode - Hopefully it remains really low.

 

 

One question (and sorry if you answered it already), will I need to update the mediabrowser.api.dll every time I update to a new Dev build?

 

 

Cheers John, for now... yes, you'll need to keep replacing the .dll. But hopefully the changes will be included with future dev builds.

 

You can disable the update check under scheduled tasks if you want to prevent MB updating without your intervention.

Edited January 26, 2015 by mjb2000

[Indypendence 1]

Alright, I left out the -s 1920x1080 and -r 30 settings, so it's no longer scaling that, which resulted in a framerate of 80. Which is as you said still not good enough.

 

I looked at some processing data. During encoding:

- My CPU use jumped up to 50% used by ffmpeg

- GPU-Z reported that my GPU Load went from 0% to 5-6% while processing

 

I added "-threads 4" to make ffmpeg use all my CPU cores. GPU load went up a little bit: 5-7% but framerate stayed the same.

 

I added the ffmpeg log as an attachment here.

 

The map0:0 command didn't work. It said: Unrecognised optionh 'map0:0'. Error splitting the argument list: Option not found.

 

The GPU is definately doing something, if I use the normal libx264 encoder, I only get 15 fps on the CPU

ffmpeg-20150126-012436.log

Edited January 26, 2015 by Indypendence

[Latchmor 584]

Just in case it's not a typo, you need a space between -map and 0:0

;-)

 

Sent from my Xperia Z3 Compact

[Indypendence 1]

Thanks, that did make a change, and that worked (well, I needed to use -map 0:1 but alright)

It boosted the speed up to about 90fps. I attached that log as well.

 

 

ffmpeg-20150126-015602.log

Edited January 26, 2015 by Indypendence

[mjb2000 47]

The map command is selecting the stream to use, nearly always the video stream is the first (0) and the audio and other subtitles are subsequent streams. Just in case this is an issue related to ffmpeg reading this source file, could you try encoding a different source. if you add -t 30 is will only encode the first 30 seconds of the video.

 

M

 

PS - Yep, there was a typo in the map command I originally asked you to try!

Edited January 26, 2015 by mjb2000

[Indypendence 1]

Ha, you read my mind! I already re-encoded the source video with handbrake with the 'fast decode' option checked. And the framerate jumped up again to 115 fps now.

Could it actually be that my CPU is too slow to decode the video stream?

Is there a way to use some kind of dummy file that doesn't take time to decode? And can the GPU be used to accelerate decoding as well?

Edited January 26, 2015 by Indypendence

[mjb2000 47]

I suppose that could be the case. What CPU do you have? 

 

A low-end CPU would explain why you were only getting 54fps within MB when it is also encoing audio and processing subtitles. But in this case, I would expect your performance using libx264 (superfast) would be very very slow.

[Indypendence 1]

I have an AMD A8-3850 (quadcore with cores running at 2.90Ghz)

It's not really a slow machine, but it won't hold up against an i5 or i7 for sure.

 

A friend of mine has a 6-core AMD with higher core speeds, he also has a GTX970, I can ask him to run the same ffmpeg command, but that will have to wait until tomorrow. I will keep  you updated about it.

So far, thanks for all the help so far!

[Indypendence 1]

Some extra information:

I launched 2 ffmpeg jobs at the same time, both run around 100fps, slightly slower compared to when I have 1 job running, but combined output is still 200fps.

 

Could still be related to the CPU, because now instead of one ffmpeg thread running at 50% cpu power, I have 2 ffmpeg threads running at 50% cpu power, equalling to 100%.

Let's wait and see what happens on a faster machine. I will know more tomorrow.

[2plane 1]

Thanks for the info and the checks you have already completed. I noticed that in the log it says "Intel Media SDK API version 1.4" - This is quite old, I'm not sure if this is due to an old driver or the fact that this is an old chip (perhaps the latest version of the API this chip supports is 1.4) - Either way, I would have hoped that the code within h264_qsv could cope with these older chips (like q264 is able to do) - but perhaps this is the problem?

 

Another thought, can you try adding -r 25 to the ffmpeg test command line - perhaps the issue is that it doesn't like the native frame rate of the source video? The -r 25 isn't a long term solution, but it might help point us in the right direction.

 

Oh, and can you confirm OS and if you are running from the console or via remote desktop?

Thanks for the assistance, No further success yet unfortunately.

 

I started with trying the -r 25 code and get the same error as above.

 

I've updated the API to version 1.8 (via this installer https://software.intel.com/sites/default/files/MediaSDK2014R2Clients.zip ).

When running the mediasdk_system_analyzer_64.exe it states that all hardware and software is all good up to version 1.7. Apparently version 1.8 requires a broadwell chip.

Strangely when reissuing the command ffmpeg command it states that I'm still on version 1.4 and provides the same error message with a -17 error code.

 

Any idea how I can force ffmpeg to run v1.7 or are there other ways to verify which API version I'm actually running?

 

OS is Windows 8.1 64 bit, and I'm running from the actual machine (console). 

 

Anyone know if it's possible to access quicksync features through a virtual machine (my google search says nope.), I'd be out the door looking for a qnap ts-453 right now if it did.

 

Oh and subsequently I've installed the Intel INDE (Integrated Native Developer Experience), no further improvements here either.

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[2plane 1]

Right click the patched API DLL in Windows and the click details tab.  The version number of the API for the DLL is listed in details.

Thanks, I'm after the QuickSync version though i.e v1.4-1.8

[mjb2000 47]

I've updated the API to version 1.8 (via this installer https://software.intel.com/sites/default/files/MediaSDK2014R2Clients.zip ).

When running the mediasdk_system_analyzer_64.exe it states that all hardware and software is all good up to version 1.7. Apparently version 1.8 requires a broadwell chip.

Strangely when reissuing the command ffmpeg command it states that I'm still on version 1.4 and provides the same error message with a -17 error code.

 

Hmmm - You shouldn't need the Intel SDK - That's only required if you're writing software to use QuickSync. I think the 1.8 you are referring to might be the version that you could use if you were to write software on your machine. AFAIK the API version that is reported when you run ffmpeg is the version of the API that your current Intel driver supports. So the only way to change that would be to upgrade your driver. With laptops this can be more difficult since Intel don't release the drivers directly, the laptop manufacturer has to release them, so there might not be an updated version.

 

I guess all of this is a little redundant, since q264 works with QuickSync there shouldn't be any reason that ffmpeg doesn't. Unfortunately I'm not sure where to start in diagnosing what could be going wrong here. There are still some issues the LibAV people are working through with QS support, so perhaps once that is completed it might fix things for you?

 

M

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[mjb2000 47]

@mjb2000 The current patched DLL in your WIKI will break the WebGUI and apps for server dev version 3.0.5504.31778.

 

Should the wiki be updated to hold at a specific version of server matched to your patched DLL?

 

Cheers - I have now updated the DLL linked on the Wiki, so if you have the most recent Dev version, this should now be working again. I have submitted a pull request to allow @@Luke & co. to integrate these changes in to the Dev build.

 

M

Edited January 27, 2015 by mjb2000

[AgileHumor 123]

delete me, pii cleanup

Edited April 17, 2015 by AgileHumor

[mjb2000 47]

The risk really should be minimal. I have built an ffmpeg binary which includes the same libraries and codecs as the Zeranoe builds (which are currently used by MB). The only changes is a few extra files in the libacvcodec directory to provide support for additional encoders (QS & NVENC) - These new encoders are only ever used when the h264 codec is changed from libx264, so although there may be issues with actually using GPU transcoding, the use of the new ffmpeg.exe for non-GPU transcoding does not seem to present any problems.

 

M

[2plane 1]

Hmmm - You shouldn't need the Intel SDK - That's only required if you're writing software to use QuickSync. I think the 1.8 you are referring to might be the version that you could use if you were to write software on your machine. AFAIK the API version that is reported when you run ffmpeg is the version of the API that your current Intel driver supports. So the only way to change that would be to upgrade your driver. With laptops this can be more difficult since Intel don't release the drivers directly, the laptop manufacturer has to release them, so there might not be an updated version.

 

I guess all of this is a little redundant, since q264 works with QuickSync there shouldn't be any reason that ffmpeg doesn't. Unfortunately I'm not sure where to start in diagnosing what could be going wrong here. There are still some issues the LibAV people are working through with QS support, so perhaps once that is completed it might fix things for you?

 

M

Great news, I'm up and running with QuickSync transcoding!

 

M, you were spot on, an upgrade to my drivers located on the Laptop manufacturers website has done the trick. I wrongly thought that using the intel update utility would have had me up to date,clearly not....

Thanks so my for your guidance, I really appreciate it.

 

The log files now indicate usage of the v1.7 API with the fps hovering around 130 on lower bitrate files.

 

I've successfully used transcoding on my iPad 3 and my HTC one M7 (had to lift from the lowest bitrate to avoid a transcoding error) and somewhat successfully on my chromecast which freezes for a couple seconds every 20-30 seconds on higher bitrate files when forcing transcoding, my test was with a 3825kb/s file.

The log does not indicate a failure to transcode fast enough (was moving between 35-60 fps on this file - See link)

 

http://pastebin.com/embed_js.php?i=2v1RwrQ5

Edited January 28, 2015 by 2plane

[mjb2000 47]

Really pleased to hear that it is all working for you.

 

Not sure why the ChromeCast is having issues, like you say, it seems the the fps should be high enough. Perhaps the MediaBrowser people can give more tips on why some devices occasionally freeze.

 

I have added a note on the wiki regarding the importance of latest drivers, and the fact laptop drivers need to comes from the manufacturer.

 

M

Edited January 28, 2015 by mjb2000