Jump to content


Photo

GPU Transcoding (Intel QuickSync and nVidia NVENC)

GPU quicksync transcoding hardware acceleration

  • Please log in to reply
1453 replies to this topic

#1 witteschnitte OFFLINE  

witteschnitte

    Advanced Member

  • Members
  • 61 posts
  • Local time: 04:15 AM

Posted 23 September 2014 - 04:07 AM

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 :-)


  • Southernbeastz71 likes this

#2 Beardyname OFFLINE  

Beardyname

    Advanced Member

  • Alpha Testers
  • 950 posts
  • Local time: 03:15 AM

Posted 23 September 2014 - 03:54 PM

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).


  • Southernbeastz71 likes this

#3 witteschnitte OFFLINE  

witteschnitte

    Advanced Member

  • Members
  • 61 posts
  • Local time: 04:15 AM

Posted 23 September 2014 - 05:44 PM

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.



#4 mjb2000 OFFLINE  

mjb2000

    Advanced Member

  • Members
  • 98 posts
  • Local time: 02:15 AM
  • LocationUnited Kingdom

Posted 07 October 2014 - 05:08 AM

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/d...eg-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 by mjb2000, 13 January 2015 - 12:00 PM.

  • swhitmore, techywarrior, snazy2000 and 4 others like this

#5 dark_slayer OFFLINE  

dark_slayer

    Advanced Member

  • Developers
  • 721 posts
  • Local time: 02:15 AM

Posted 13 November 2014 - 08:21 AM

This would be a fantastic improvement for media servers in general


  • breezytm likes this

#6 mjb2000 OFFLINE  

mjb2000

    Advanced Member

  • Members
  • 98 posts
  • Local time: 02:15 AM
  • LocationUnited Kingdom

Posted 17 December 2014 - 04:30 PM

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).


  • Spaceboy, Tranquil, dark_slayer and 2 others like this

#7 Beardyname OFFLINE  

Beardyname

    Advanced Member

  • Alpha Testers
  • 950 posts
  • Local time: 03:15 AM

Posted 17 December 2014 - 05:29 PM

you should really talk to the devs about this :P



#8 mjb2000 OFFLINE  

mjb2000

    Advanced Member

  • Members
  • 98 posts
  • Local time: 02:15 AM
  • LocationUnited Kingdom

Posted 17 December 2014 - 06:03 PM

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

#9 techywarrior OFFLINE  

techywarrior

    Advanced Member

  • Moderators
  • 2411 posts
  • Local time: 06:15 PM

Posted 17 December 2014 - 06:15 PM

@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.


  • Olywa123 likes this

#10 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 134451 posts
  • Local time: 10:15 PM

Posted 17 December 2014 - 07:58 PM

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


  • swhitmore likes this

#11 mjb2000 OFFLINE  

mjb2000

    Advanced Member

  • Members
  • 98 posts
  • Local time: 02:15 AM
  • LocationUnited Kingdom

Posted 17 December 2014 - 08:14 PM

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.

#12 techywarrior OFFLINE  

techywarrior

    Advanced Member

  • Moderators
  • 2411 posts
  • Local time: 06:15 PM

Posted 17 December 2014 - 08:33 PM

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.



#13 ebr ONLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 46041 posts
  • Local time: 10:15 PM

Posted 17 December 2014 - 09:10 PM

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.



#14 dark_slayer OFFLINE  

dark_slayer

    Advanced Member

  • Developers
  • 721 posts
  • Local time: 02:15 AM

Posted 17 December 2014 - 10:13 PM

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

#15 dark_slayer OFFLINE  

dark_slayer

    Advanced Member

  • Developers
  • 721 posts
  • Local time: 02:15 AM

Posted 17 December 2014 - 10:14 PM

How will this handle simultaneous requests?

#16 techywarrior OFFLINE  

techywarrior

    Advanced Member

  • Moderators
  • 2411 posts
  • Local time: 06:15 PM

Posted 17 December 2014 - 10:22 PM

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)



#17 mjb2000 OFFLINE  

mjb2000

    Advanced Member

  • Members
  • 98 posts
  • Local time: 02:15 AM
  • LocationUnited Kingdom

Posted 17 December 2014 - 10:29 PM

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 by mjb2000, 17 December 2014 - 10:36 PM.

  • dark_slayer likes this

#18 dark_slayer OFFLINE  

dark_slayer

    Advanced Member

  • Developers
  • 721 posts
  • Local time: 02:15 AM

Posted 18 December 2014 - 01:29 AM

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

#19 dark_slayer OFFLINE  

dark_slayer

    Advanced Member

  • Developers
  • 721 posts
  • Local time: 02:15 AM

Posted 18 December 2014 - 02:45 AM

Transcoded full bitrate vc1 w/ trueHD audio no problems yet
  • mjb2000 likes this

#20 jluce50 OFFLINE  

jluce50

    Advanced Member

  • Alpha Testers
  • 559 posts
  • Local time: 09:15 PM
  • LocationOKC

Posted 18 December 2014 - 12:37 PM

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







Also tagged with one or more of these keywords: GPU, quicksync, transcoding, hardware acceleration

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users