Jump to content

GPU Transcoding (Intel QuickSync and nVidia NVENC)


witteschnitte

Recommended Posts

No, too much overhead, and too much additional work for all of our package maintainers for the various operating systems.

Link to comment
Share on other sites

HW encoding in the core will happen when ffmpeg supports it natively and it can be done with all of our operating systems. Until then it will have to be limited to something like a plugin or community guide to setup. I'll give you guys all you need in terms of making it possible to do via plugin or adding hidden config switches, things of that nature. But I wouldn't integrate it and call it a supported feature until it can be done universally.

 

gstreamer looks interesting but I'm not familiar with it. i think we would need someone who's an expert to come on and analyze all of our command lines and design some gstreamer equivalents. Then we can start to look at whether it's feasible or not.

  • Like 1
Link to comment
Share on other sites

mjb2000

HW encoding in the core will happen when ffmpeg supports it natively and it can be done with all of our operating systems. 

 

I agree with what Luke is saying about all operating systems, but to be fair ffmpeg doesn't support libvpx or libx264 "natively" - These technologies are built in to ffmpeg as a custom build by Zeranoe, much in the same way I am building in h264_qsv and libnvenc.

 

 

@@ebr or @@Luke,  Do you feel that adding the encoders QS & NVENC to the FFMPEG build script is feasible so MediaBrowser updates don't have potential overwrite in future?

 

I have actually found another way to achieve what you are looking for using a hidden feature the MB has already got built-in. Essentially, MB allows you to specify the ffmpeg.exe you would like to use on the command line used to launch MB. Go and take a look at point 6 in the wiki - I have outlined the steps you can take to 'lock-in' your GPU enabled ffmpeg.exe

 

Let me know how you get on with the steps outlined in the Wiki

  • Like 1
Link to comment
Share on other sites

I've got a pretty simple question on this, does enabling hardware coding limit or increase the number of simultaneous streams you could have?

i'm looking from a desktop core i5 (haswell) pov...

i'd assume this is only REALLY needed for lightweight systems? (atoms, Celerons etc..?)

Link to comment
Share on other sites

Indypendence

I've got a pretty simple question on this, does enabling hardware coding limit or increase the number of simultaneous streams you could have?

i'm looking from a desktop core i5 (haswell) pov...

i'd assume this is only REALLY needed for lightweight systems? (atoms, Celerons etc..?)

My GTX970 can only do 2 simultaneous streams. I tried 3 and it will then claim the hardware is not available.

So for the NVENC: 2 streams max.

Will test it with Quicksync as soon as possible (I ordered a celeron to test it with, should be delivered today).

Link to comment
Share on other sites

mjb2000

I've got a pretty simple question on this, does enabling hardware coding limit or increase the number of simultaneous streams you could have?

i'm looking from a desktop core i5 (haswell) pov...

i'd assume this is only REALLY needed for lightweight systems? (atoms, Celerons etc..?)

 

It will all depend on the source file and the bitrate settings for the streaming clients. But you might find that you are able to do more once you enable GPU encoding. I guess the only way to find out is by trying it for yourself.

 

My gut feeling is that this should allow you to transcode more, since some of the grunt work will be offloaded to the GPU. As has been mentioned, there is a hard limit on GeForce encodes (not of the higher-end nVidia cards). As far as I have seen with QuickSync, the fps you can achieve with a single encode task is split amongst other tasks. For me, I can achieve around 90fps with a single stream, and 29fps with three. This may not sound amazing, but keep in mind I can only achieve 14fps with a single encode task using libx264.

Link to comment
Share on other sites

Tranquil

New setup, new tests.

 

Running your ffmpeg build in a command prompt without any problems. The latest build of MBS does not work unfortunately with your .dll and ffmpeg fork.

 

My notebook setup is: 

 

Windows 8.1 64 Bit, 8GB RAM

Intel Core I7 4710 HQ, embedded HD4600 graphics, Driver: 10.18.10.3960 Win 8.1, 64 bit

2nd GPU: NVidia Geforce GTX 860M, 2GB dedicated RAM, Driver: 9.8.13.4725 (Forceware 347.25)

 

Both methods run at around 150fps at 1280x720. NVENC seems to be slightly faster and brings a better result, so far what I saw yet.

Link to comment
Share on other sites

dark_slayer

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

I'm wondering the same thing

 

New setup, new tests.

 

Running your ffmpeg build in a command prompt without any problems. The latest build of MBS does not work unfortunately with your .dll and ffmpeg fork.

Doh . . . waited too long. I tried about 6 days ago and it broke payback for my android phone so I reverted changes and waited for a fix. @@mjb2000 looks like you had just fixed it a couple days ago :D in trying to stay semi stable, so I'm running the Dev release with updates off . . . when someone says it's working again hopefully I can pull that version and turn updates back off

 

My server will primarily do QS, since I'm using NVENC for either limelight or steam IHS when gaming. @@Luke, @@ebr, et. al . . . It would be amazing to see a day where it could prioritize one to nvenc (I really only need 1 of the 2 encodes for games) then pass the others over to QS and even let one fall back to libx264 software if necessary. Luke/Eric who would be a go to for considering that kind of logic and learning what MBS uses now. Currently the basic x264 transcoder runs "pedal to the metal" which a lot of people will see and compare to Plex not understanding that Plex is just throttling the speed based on the client options of bitrate and cache size. Plex will just hit a more minimum fps target and work the whole time while MBS will finish up and let go of the ffmpeg process altogether. Plex doesn't have QS or NVENC at all, so not only could throttling make MBS look the same as Plex on resources . . . with QS and NVENC it would demolish it on a side by side comparison

Link to comment
Share on other sites

mjb2000

Doh . . . waited too long. I tried about 6 days ago and it broke payback for my android phone so I reverted changes and waited for a fix. @@mjb2000 looks like you had just fixed it a couple days ago :D in trying to stay semi stable, so I'm running the Dev release with updates off . . . when someone says it's working again hopefully I can pull that version and turn updates back off

 

I have updated my api.dll again - Update to the latest dev build and download the api.dll from the wiki. From now on, I will indicate the server version that my api.dll matches.

 

 

My server will primarily do QS, since I'm using NVENC for either limelight or steam IHS when gaming. @@Luke, @@ebr, et. al . . . It would be amazing to see a day where it could prioritize one to nvenc (I really only need 1 of the 2 encodes for games) then pass the others over to QS and even let one fall back to libx264 software if necessary. Luke/Eric who would be a go to for considering that kind of logic and learning what MBS uses now. Currently the basic x264 transcoder runs "pedal to the metal" which a lot of people will see and compare to Plex not understanding that Plex is just throttling the speed based on the client options of bitrate and cache size. Plex will just hit a more minimum fps target and work the whole time while MBS will finish up and let go of the ffmpeg process altogether. Plex doesn't have QS or NVENC at all, so not only could throttling make MBS look the same as Plex on resources . . . with QS and NVENC it would demolish it on a side by side comparison

 

The "pedal to the metal" approach can actually be turned on and off pretty easily using the -re option for on the ffmpeg command line. This forces ffmpeg to transcode in realtime, although at present MB does not appear to use this option. This is a good option since it means you can fast forward (play a 8x for example) - with realtime encoding this wouldn't be possible. As far as I can work out, jumping/skipping ahead would still work with realtime encoding since a new encoding job would be started at the new seek point requested.

 

M

Link to comment
Share on other sites

mjb2000

New setup, new tests.

 

Running your ffmpeg build in a command prompt without any problems. The latest build of MBS does not work unfortunately with your .dll and ffmpeg fork.

 

My notebook setup is: 

 

Windows 8.1 64 Bit, 8GB RAM

Intel Core I7 4710 HQ, embedded HD4600 graphics, Driver: 10.18.10.3960 Win 8.1, 64 bit

2nd GPU: NVidia Geforce GTX 860M, 2GB dedicated RAM, Driver: 9.8.13.4725 (Forceware 347.25)

 

Both methods run at around 150fps at 1280x720. NVENC seems to be slightly faster and brings a better result, so far what I saw yet.

 

Great to hear. Take a look at the updated api.dll I've added to the Wiki and you should be able to get MB running now

 

What sort of speed to you get with libx264 superfast? - To be honest, it might also be around 150fps, but I imagine you CPU usage is much lower when using GPU encoding :)

Link to comment
Share on other sites

dark_slayer

Still no luck for me with latest Dev, ffmpeg patch and api. I also went ahead and replaced ffprobe after the first attempt (still no luck). I left all the files modified and changed the XML back to preferring libx264 for now and it's working fine

 

Here are the server and transcode logs, I made several attempts

server-63558239661.txt

transcode-64a102c0-6e3d-437c-8206-25d5b2665cd4.txt

transcode-64a5671c-47c0-42f7-9e81-e7f9fd340687.txt

transcode-710884b9-c709-4db8-9d48-b6f76f0047fc.txt

transcode-a7611915-f6c8-4244-a2a7-51403fb2f372.txt

transcode-cd4152de-1811-41b7-9c00-05b6d96385b4.txt

Link to comment
Share on other sites

dark_slayer

Hey @@mjb2000

 

Something's definitely wrong, but I can't tell what. I did some tests like you told mylle to do in this post             #103            

 

It's only running at like 0.5 fps, so both tests I just killed the ffmpeg process as it was literally ticking off frame by frame in CMD

 

Here is an HEVC and non-HEVC test

 

hevc-ffmpeg-20150130-222921.log

non-hevc-ffmpeg-20150130-223559.log

Link to comment
Share on other sites

dark_slayer

Lol, I think I figured some of it out @@mjb2000

 

I had "Put the display to sleep" enabled in power options. When I disabled that it seems the GPU "woke up" :D

 

I also went ahead and changed link state power management and intel graphics power options to maximum performance

 

Here's another log, 327 fps non-HEVC

 

However, I'm still getting some kind of issue with the HEVC test. It seems to have some issue and slows way down before coming to a crawl

 

Attached the successful non-HEVC and HEVC logs

ffmpeg-20150130-225029.log

HEVC-ffmpeg-20150130-225623.log

Link to comment
Share on other sites

dark_slayer

To do those tests I just copied ffmpeg, an hevc video, and an h264 video to a test folder and ran the commands from cmd

 

@@mjb2000, is your ffprobe already looking for HEVC and running that over to regular libx264 instead?

Link to comment
Share on other sites

dark_slayer

Hmm, I'm also at a strange place now. I can edit the \MediabBrowser-Server\config\encoding.xml and restart the server and nothing changes ??

 

Also, @@Luke or anyone who would know. Is there a way to pick and stick with a dev release. I have a UPS on my server and don't really ever intend to restart it, but I noticed that even with the "auto-restart-to-apply-updates" feature disabled I found that I have to be logged into the web client and manually "x" out of the automatic update that it tries to install. Is there a way to turn that off?

Edited by dark_slayer
Link to comment
Share on other sites

Happy2Play

Is there a way to pick and stick with a dev release. I have a UPS on my server and don't really ever intend to restart it, but I noticed that even with the "auto-restart-to-apply-updates" feature disabled I found that I have to be logged into the web client and manually "x" out of the automatic update that it tries to install. Is there a way to turn that off?

 Are you talking about preventing updates?  If so you need to remove the scheduled task triggers for application updates.

  • Like 1
Link to comment
Share on other sites

Tranquil

The guys of MBS pushing out dev versions so fast, I couldn't avoid the last update as "automatic updates" are always enabled.

Now I dont know if my following problems are cause of a wrong dll version or if there is something wrong with your ffmpeg.

 

Running on QuickSync-Preset the stream starts within internet explorer on my local host but stops after some seconds. (mostly around 50 seconds). Seeking within the stream is not possible for me.

 

The generated transcode logfile:

http://pastebin.com/zhqtqgpj

 

Server:

http://pastebin.com/rj85Vjtk

 

Nvidia support does not work within MBS but work in command line.

 

Logfiles for NVENC:

 

Transcode:

http://pastebin.com/tiKY6Dw3

 

Server:

http://pastebin.com/3B27MS0H

Link to comment
Share on other sites

Tranquil

What sort of speed to you get with libx264 superfast? - To be honest, it might also be around 150fps, but I imagine you CPU usage is much lower when using GPU encoding :)

 

I tested a bit with handbrake, cause its easier then a console prompt. With fastest possible encode on quicksync I get somewhat around 200fps with a cpu load around 15-20%. Input material was 1080p, output also at 8Mbit avg bitrate. Thats quite good I think! :-)

Link to comment
Share on other sites

Indypendence

I've got a pretty simple question on this, does enabling hardware coding limit or increase the number of simultaneous streams you could have?

i'm looking from a desktop core i5 (haswell) pov...

i'd assume this is only REALLY needed for lightweight systems? (atoms, Celerons etc..?)

I just installed my celeron machine and it seems to be limited by it's CPU computing power when launchign multiple streams at the same time. I could easily launch 3 or more ffmpeg streams, but the fps just drops depending on the amount of streams. But even with one stream the CPU maxes out at 100% already. It could be that the celeron is just too slow to even decode everything in time.

I will test the same settings monday on a same generation i7, see if that makes a difference. Will keep you informed.

  • Like 1
Link to comment
Share on other sites

Indypendence

I have a question again myself. This time, it's for h264_qsv encoding:

When I set a bitrate with: -b:v 1000k  there's no problem, but when I change this into -crf 20 I get a notice:

Codec AVOption crf (Ignored.) specified for output file #0 (output.mp4) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.

And then it errors out with MFXVideoENCODE_Init(): -15

 

My input command:

ffmpeg.exe -i input.mp4 -t 30 -map 0:0 -crf 20 -y -preset 1 -c:v h264_qsv output.mp4

Any ideas?

Link to comment
Share on other sites

mjb2000

However, I'm still getting some kind of issue with the HEVC test. It seems to have some issue and slows way down before coming to a crawl

 

When you are talking about HEVC, you are referring to an HEVC input yes? I have been using the Big Bunny 1080p test video from here to run some tests. For me, I struggle to get more than 21fps but this is due to the heavy decode process required for HEVC. FFmpeg should be handling the HEVC input in the same way it would without QuickSync - It is built with libx265 so I am guessing it will be passing off the decoding to this?

 

To nail down the problem here, can you try and encode HEVC > libx264 and HEVC > h264_qsv so we can see the difference, if any h264_qsv is causing.

 

 

Running on QuickSync-Preset the stream starts within internet explorer on my local host but stops after some seconds. (mostly around 50 seconds). Seeking within the stream is not possible for me.

 

The generated transcode logfile:

http://pastebin.com/zhqtqgpj

 

Server:

http://pastebin.com/rj85Vjtk

 

Nvidia support does not work within MBS but work in command line.

 

Logfiles for NVENC:

 

Transcode:

http://pastebin.com/tiKY6Dw3

 

Server:

http://pastebin.com/3B27MS0H

 

It looks as if I also need to make some updates to a couple of other files within the MediaEncoder section of the MB project. The changes I have made so far seem to be working for devices such as the Roku, but when MB streams to IE it is using some different code. I'll update you once I have made these changes

 

 

I have a question again myself. This time, it's for h264_qsv encoding:

When I set a bitrate with: -b:v 1000k  there's no problem, but when I change this into -crf 20

 

-crf is a libx264 specific command. h264_qsv allows you to specify the quality of p, i and b frames separately, more info is available here. The commands you would need are:

ffmpeg -i in.mkv -map 0:0 -c:v h264_qsv -qpi 20 -qpb 20 -qpp 20 out.mkv
  • Like 1
Link to comment
Share on other sites

dark_slayer

 

 

When you are talking about HEVC, you are referring to an HEVC input yes? I have been using the Big Bunny 1080p test video from here to run some tests. For me, I struggle to get more than 21fps but this is due to the heavy decode process required for HEVC. FFmpeg should be handling the HEVC input in the same way it would without QuickSync - It is built with libx265 so I am guessing it will be passing off the decoding to this?

 

To nail down the problem here, can you try and encode HEVC > libx264 and HEVC > h264_qsv so we can see the difference, if any h264_qsv is causing.

Yeah I have a few videos already encoded to hevc. It's one of my most recent videos, so I was playing it to test after I switched all the settings and files around. I got video can't be played a few times and didn't try other videos, but later I realized two things. 1) the GPU was off because of the power settings but also 2) I had only been trying the hevc video

 

I think it was still trying to pass this off to h264_qsv looking at the log so I was wondering if there was a way to avoid that for now since it probably needs an h265_qsv instead or something. I thought I recalled qsv making a 265 encoder as well?

 

However yes, I will try a libx264 and h264_qsv test with hevc input and give you something to compare. I started getting less then 20fps for a while before I killed it

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...