GPU Transcoding (Intel QuickSync and nVidia NVENC)

[witteschnitte 7]

Hi,

i will thank you for this great software it´s amazing.

Now i have one little question. Will it be possible to use the GPU for transcoding (like Intel Quicksync) in the Webplayer?

I know Mediabrowser Server 3 uses ffmpeg. I test with ffmpeg standalone at it can use quicksync to transcode.

How could i turn this on in the MBS 3?

It will be greate for all having a smal HTPC mit a CPU that allows this feature.

 

I look forward to your response :-)

[Beardyname 197]

Are you sure ffmpg can do hardware trans-coding? (just asking since last time it was kinda a mess different support for different things and only for certain codecs).

[witteschnitte 7]

Thanks for your reply. You are right. Not all codecs will be supported. (egg. H.264 / AVC / MPEG4 ) But H.264 will take a lot auf CPU Power. The other Codecs will load only 30%. So it will be great to get H264 to the GPU.

[mjb2000 47]

January 2015 update

 

GPU Transcoding is now possible. We are in the early stages and still being tweaked to improve stability and performance. If you'd like to try it out, find out how in the Wiki

 

-----

 

There is a 32-bit Windows binary of ffmpeg which includes QuickSync support available:

https://github.com/drocon11/ffmpeg-qsv/releases

 

I have tried it out and it works great, instead of encoding around 23 fps @ 97% CPU I am now getting over 60 fps @ 95% CPU on my small J1900 board (a great, low-power 10W board btw).

 

The problem is, you can't just drop this .exe in as a replacement for the existing ffmpeg.exe that comes with mediabrowser, if you do you'll see errors in your transcode logs. It seems that MB requires ffmpeg to be built with quite a few libraries and codecs (not sure where I can get the list, can someone point me in the right direction?).

 

Another issue we'll need to address is that at present the MB command line for ffmpeg won't include the necessary parameters to request QuickSync encoding ( -c:v h264_qsv ) - so we'll either need a way to change this in the UI, or tweak the commands BaseStreamingService.cs and re-build MB.

 

As has been pointed out, QuickSync does not support all codecs. I'm particularly interested in streaming to web clients. This is currently done by encoding to WEBM (which I understand has VP8 as a video codec) - So can any MB guys explain if it would be possible to change things around a little and deliver h264 to web clients (although not HTML5 standard, a lot of browsers play h264 natively and it seems that h264 playback performance is better than WEBM for the client machine).

 

Just to finish up, QuickSync offers a real chance to provide a fantastic MB experience from low-power, fanless and inexpensive hardware. The proof-of-concept of ffmpeg with QS encoding has been achieved and I believe we are not far away from cracking this nut!

 

Matt

Edited January 13, 2015 by mjb2000

[dark_slayer 103]

This would be a fantastic improvement for media servers in general

[mjb2000 47]

I said I didn't think we were far away from cracking this nut, and I'm please to say that I think we are there...

 

I have now tweaked a script that allows the building of an ffmpeg.exe within Windows which includes the option to encode to h264 using Intel QuickSync GPU transcoding.

 

If you'd like to try it out you can either follow the usage instructions for the build script and build the .exe yourself, or download a pre-compiled ffmpeg.exe from the releases section.

 

If you'd like to try it out, you need to specify the video codec h264_qsv in order to use QuickSync rather than x264, for example:

ffmpeg -i "input.mp4" -b:v 4000k -vcodec h264_qsv "output.mp4"

You should be able to replace the existing ffmpeg.exe within the MediaBrowser Server installation and everything should just continue to work as before (since I have tried to compile ffmpeg with all the libraries that MediaBrowser needs to use).

 

Because MediaBrowser currently runs ffmpeg with -vcodec libx264 a change will need to be made to the MediaBrowser code to switch this to -vcodec h264_qsv

 

Another issue is that MediaBrowser also favours WEBM for web browser streaming which does not use the h264 codec, as a result it will never be possible to use QuickSync to improve performance. However, it should be possible to tweak MediaBrowser so that rather than WEBM, we use h264 MP4's instead. Technically this isn't as HTML5 friendly as WEBM, but most browsers do support MP4 video natively, so this might be a sacrifice worth making to take advantage of GPU transcoing.

 

It seems that it is BaseStreamingService.cs (and possibly other front-end files) that will need to be updated to enable QuickSync support from within MediaBrowser. Having spent so long trying to get ffmpeg working with QuickSync I now realise that making these changes to MediaBrowser is a little bit beyond me, so I was wondering if any of the MediaBrowser team are able to take this on?

 

I guess we'd need to add two checkboxes to the MediaBrowser server GUI...

• [  ] Use Intel QuickSync when transcoding to h264 video 
• [  ] Use h264 (MP4) instead of VP8 (WEBM) for web streaming clients

It would be great if you could try out this ffmpeg build and let me know how it works for you and if any of the MediaBrowser guys could provide feedback on the possibility of making this alterations to the ffmpeg command line.

 

Notes:

I need to thank the drocon11/ffmpeg-qsv, lu-zero/mfx_dispatch and jb-alvarado/media-autobuild_suite projects which are essentially the projects I have combined to get the build script working.

 

All of the code that goes in to generating the ffmpeg.exe is GPL, so the compiled .exe can be distributed without any problems - so it should be possible for it to truly be a drop-in replacement.

 

This all works only on Windows. Linux support is probably not far away, but there are a couple of additional hardware acceleration libraries which are required and I don't have the Linux skills to make this work (so the changes to the server GUI would have to be for Windows users only).

[Beardyname 197]

you should really talk to the devs about this

[mjb2000 47]

How do I go about that? I have sent a message to Luke?

[techywarrior 689]

@@Luke is this something that can easily be added in or will Linux support be required first?

 

The mp4 for web may not be as worthwhile/useful but enabling QS for h264 encoding will be a big benefit for Roku, Android, WP, etc.

 

It may also help people asking what sort of server they should build. And if Plex doesn't have QS support then it will be even better since MB will have much better multi client transcoding performance.

[Luke 38811]

the second part isn't going to happen. the client device decides whether it wants webm or h264. we have most of the browsers set to prefer webm because they don't handle fragmented mp4 very well. I do monitor chrome for improvements in this area though.

 

but for any scenario where h264 is used, this can help.

 

step 1 before i do any work is to give your ffmpeg build to some users here, have them replace the server's copy with yours, and then verify that nothing is negatively impacted.

 

once that is done i can look at a hidden config change so that people can test out h264_qsv

[mjb2000 47]

This sounds sensible. Who is interested in testing this new ffmpeg and reporting back their experiences?

 

As Luke says, for now we're not looking to test GPU success. Instead were looking to check that everything continues to work as usual.

[techywarrior 689]

I've replaced the default ffmpeg version with the pre-compiled version you created. I don't do a lot of transcoding tho but what little I do will test out the build.

[ebr 15429]

I have replaced it on my dev server.  Since I'm working on a 100% streaming client right now, it should get a bit of a workout with different formats.

[dark_slayer 103]

I'm happy to do this. This is awesome. I've got two full time dedicated fire tv gifts going out this Christmas

 

After I replace the file, what do I need to do for testing

[dark_slayer 103]

How will this handle simultaneous requests?

[techywarrior 689]

At the moment all we are doing is replacing the file and making sure that everything works like it did before. Once that has been established Luke will add an option or some automatic way that quicksync acceleration will be enabled. (and then more testing will be needed)

[mjb2000 47]

I must admit I have not tested simultaneous requests thoroughly, but I have run three instances of ffmpeg using h264_qsv simultaneously and everything seemed to work well.

 

I am a little confused by the results, with a single instance the file transcodes 70fps @ 70% CPU but with all three instances running I achieved an overall rate of around 75 fps @ 85% CPU. So there might be some additional benefits of GPU transcoding going on here which I hadn't anticipated.

 

My J1900 CPU is a very low-performance/power chip, so 75fps between three streams is pushing the limit of 25fps smooth video, but I'd imagine that others running better i3, 5 or 7's will probably see some pretty good results.

 

EDIT: Having seen techywarrior's last post - let me just point out that these three simultaneous transcodes were initiated manually, purely for testing purposes by running commands such as these in three separate command prompt windows in quick succession:

ffmpeg -i "TestVideo.mp4" -b:v 4000k -vcodec h264_qsv "Output-1.mp4"
ffmpeg -i "TestVideo.mp4" -b:v 4000k -vcodec h264_qsv "Output-2.mp4"
ffmpeg -i "TestVideo.mp4" -b:v 4000k -vcodec h264_qsv "Output-3.mp4"

Don't forget you'll need to specify different output file names so that each instance is not overwriting each-other!

 

Commands such as these will allow you to anticipate the performance you will be able achieve once the changes to MB are made to allow the use of the h264_qsv encoder.

Edited December 18, 2014 by mjb2000

[dark_slayer 103]

Okay then. I've replace my beta server ffmpeg with your precompiled one. I'll let you know

[dark_slayer 103]

Transcoded full bitrate vc1 w/ trueHD audio no problems yet

[jluce50 122]

Just to be clear, you must be using an Intel CPU to take advantage of this, correct?

[Tranquil 93]

Yes. You need an Intel CPU which support quicksync.

[mjb2000 47]

You can see all QuickSync compatible CPU's here

 

There is an interesting range from the high-end i7 to the low-end Atom (obviously performance will vary according to chip performance).

 

You'll see from some of my earlier posts I'm quite a fan of the Intel J1900  - It's a low-power consumption (10W) quad-core 2Ghz chip which supports QuickSync. It's never going to support many simultaneous transcoding clients, but as a fanless, silent solution for a home server / HTPC and transcoder for a small number of devices, it should work well.

 

M

[Tranquil 93]

Nice link mjb2000!

I'm wondering that there is currently no CPU for socket 2011 or 2011-3 which is supporting quick sync. Is it going to be obsolete in future? 

[mjb2000 47]

Cheers Tranquil. I've not come across Socket 2011 and 2011-3 but these seem like pretty high-end CPU intensive sockets. These chips contain don't contain GPU whatsoever and I think that they are probably aimed more towards datacenter servers. The latest batch of mainstream i3, i5 and i7's all seem to support QuickSync. It seems to be something that they are including alongside all chips that contain GPUs.

 

There is also development under way to use QuickSync to power h265 (HEVC) processing, so with h265 probably being the future, but currently a little CPU intensive, my guess would be the QuickSync in some form or another will be here to stay.

 

I should also say that if you have a dedicated GPU (AMD or NVIDIA for example) then it is still possible to use the Intel GPU even when your display is only attached to the dedicated graphics card - you'll need to search around for it, but essentially it involves forcing Windows to clone you display to your existing dedicated graphics display and a non-existent display 'waiting to be attached' to the Intel GPU. This trick works on most chipsets apart from the earliest Sandybridge chipsets which completely disabled the GPU on boards with a PCI Express slot of dedicated graphics.

 

Have you had a chance to test the new ffmpeg.exe yet Tranquil?

 

NOTE TO ALL READERS:

Have you tried replacing you existing ffmpeg.exe with my pre-compiled version yet?

 

Luke needs to see that using this new ffmpeg does not damage any existing functionality. Once this has been established he will tweak the MB code to allow us to start testing QuickSync functionality. Therefore please report all success and failures in this thread so Luke can judge when to proceed.

 

In order to test the new ffmpeg you will need to download it from the releases section here and then replace the original ffmpeg.exe which you can find in:

%USERPROFILE%\AppData\Roaming\MediaBrowser-Server\ffmpeg\20141111\ffmpeg.exe

TIP: Rather than overwriting the exisitng ffmpeg.exe, consider renaming it to ffmpeg.exe.original and then if there are any issues with the new version you can easily roll-back to the previous version.

[Guest]

Sad to hear that it only works with Intel GPU's

My Server is made of an old HTPC with a AMD A6 APU and an old ATI Radeon 5000 GPU.

 

I hoped that my dedicated ATI Graphics Card can do the transcoding job, because the AMD CPU/APU sometimes has it's problems with it.

 

Anyway...Thanks for you effort and you great work.

Maybe I will benefit from it someday if I switch back to a Intel CPU/GPU again 

Edited December 19, 2014 by CM000n