Jump to content

Need/Want help to make GPU transocoding useful


Carlo

Recommended Posts

Hi,

 

I definitely like the idea - this would be great. Perhaps a dumb question though - are we getting a bit off track of the topic (trying to get GPU transcoding working)?

 

I may be missing the point though ... :(.

Link to comment
Share on other sites

Hi, right now I work in this kind of things, although my sector is not multimedia but reporting.

 

If you are really going down the path of distributed encoding (which for my personal idea is overwhelming in a home situation) I personally suggest to create a "ffmpeg server" process that stays always on (maybe started trough a windows service).

Like this you can have a central management of the various queue that are offloaded to the different slave pcs.

You should also keeps a statistic for each kind of work that you are requesting to the various machine to choose in the future what to do, according to the various status of each machine.

You should implement a "state machine" in the offload server to have a better control of what it can do and when.

 

These are just the first ideas coming from my experience. Like this you should be able also to achieve something like a slave process that should be able to say to you "this machine can manage 2 nvenc queue, 10 quicksync, and [n] normal".

 

But personally, I would first implement this all in one machine.

 

Moreover, you are not forced to use just ffmpeg, with a proxy you can use whichever multimedia cli you want on the backend... the important should be that It can be streamed trough a TCP stream (but for this should be enough that thier output stream is redirectable or that they support writing to a named pipe) to and that you can translate the parameters from ffmpeg to that backend. In case of not being able to translate you can always fall back to ffmpeg, or you can also CHAIN them (if they support encoding trough their input stream) and so on.

Link to comment
Share on other sites

Hi,

 

I definitely like the idea - this would be great. Perhaps a dumb question though - are we getting a bit off track of the topic (trying to get GPU transcoding working)?

 

I may be missing the point though ... :(.

 

Maybe I should change the name of the thread.  It's not just about GPU but about transcoding improvements in general.  It was sort of a continuation of another thread where I had mentioned some of these other features.  We are still striving to do GPU improvements but hit something of a standstill as ffmpeg isn't faster nor saving GPU resources at present.

Hi, right now I work in this kind of things, although my sector is not multimedia but reporting.

 

If you are really going down the path of distributed encoding (which for my personal idea is overwhelming in a home situation) I personally suggest to create a "ffmpeg server" process that stays always on (maybe started trough a windows service).

Like this you can have a central management of the various queue that are offloaded to the different slave pcs.

You should also keeps a statistic for each kind of work that you are requesting to the various machine to choose in the future what to do, according to the various status of each machine.

You should implement a "state machine" in the offload server to have a better control of what it can do and when.

 

These are just the first ideas coming from my experience. Like this you should be able also to achieve something like a slave process that should be able to say to you "this machine can manage 2 nvenc queue, 10 quicksync, and [n] normal".

 

But personally, I would first implement this all in one machine.

 

Moreover, you are not forced to use just ffmpeg, with a proxy you can use whichever multimedia cli you want on the backend... the important should be that It can be streamed trough a TCP stream (but for this should be enough that thier output stream is redirectable or that they support writing to a named pipe) to and that you can translate the parameters from ffmpeg to that backend. In case of not being able to translate you can always fall back to ffmpeg, or you can also CHAIN them (if they support encoding trough their input stream) and so on.

Yep, I know all the little steps that will be required for a really good implementation.  Just need to work through some of the basics first to really flush things out before making it intelligent.

 

Right now without changing MB3 we are forced to use ffmpeg.  That or the proxy will have a great deal of work to do.  It's not just about changing the command line around to match a different tool and then calling it.  MB3 "reads the stderr" output from ffmpeg to watch the status of what's going on with the transcode.  So if we use a different tool than ffmpeg then it would be far easier to setup MB3 to use it properly than to hack the proxy to try and reformat (if even exists) that status into ffmpeg style.

 

If you want to get a better idea what I'm talking about.  Copy the command line from a transcode log and manually run ffmpeg with it.  Watch the stuff that comes up in the console window.  MB3 is using that info.  Now try a similar command line with QSTranscode which does GPU transcoding and see what comes up in that console.  So we would have to make the output of QSTranscode match that of ffmpeg.  Far easier to just add code to MB3 itself to use QSTranscode.

 

Carlo

Edited by cayars
Link to comment
Share on other sites

Yes, I was just imagining it. In fact there should be a better separation between MediaBrowser and the tool it is going to use to stream around the various media, but I suppose you gave a better look at the code than what I did, so you know of what you are talking about.

 

I would like to find a bit of time to enter in this adventure, but right now I don't have even a machine worth testing on it (I owns a zinohd 410 with dedicated ati).

Link to comment
Share on other sites

Hi,

 

Make sense what cayars is saying above - I was wondering exactly that, hoping that MB wasn't using (processing) the log output of ffmpeg ... as there seem to be better options for transcoding, in particular if you want to use a GPU (QSV or NVENC ... and later VCE?). My hope was to be able to use those other tools, perhaps through some sort of config files ... :(.

 

Thanks for the info!

Link to comment
Share on other sites

  • 2 weeks later...
dark_slayer

Maybe I should change the name of the thread. It's not just about GPU but about transcoding improvements in general. It was sort of a continuation of another thread where I had mentioned some of these other features. We are still striving to do GPU improvements but hit something of a standstill as ffmpeg isn't faster nor saving GPU resources at present.

Yep, I know all the little steps that will be required for a really good implementation. Just need to work through some of the basics first to really flush things out before making it intelligent.

 

Right now without changing MB3 we are forced to use ffmpeg. That or the proxy will have a great deal of work to do. It's not just about changing the command line around to match a different tool and then calling it. MB3 "reads the stderr" output from ffmpeg to watch the status of what's going on with the transcode. So if we use a different tool than ffmpeg then it would be far easier to setup MB3 to use it properly than to hack the proxy to try and reformat (if even exists) that status into ffmpeg style.

 

If you want to get a better idea what I'm talking about. Copy the command line from a transcode log and manually run ffmpeg with it. Watch the stuff that comes up in the console window. MB3 is using that info. Now try a similar command line with QSTranscode which does GPU transcoding and see what comes up in that console. So we would have to make the output of QSTranscode match that of ffmpeg. Far easier to just add code to MB3 itself to use QSTranscode.

 

Carlo

@@Luke @@mjb2000 @@cayars

 

Does this need more head-scratching time? Does anyone happen to have any recommendation at this point?

 

Luke and @@ebr

 

I'm nor sure if this is accurate or just a hunch of mine, but it seems like the focus of mediabrowser is not too set on improving this and that what exists is good enough. At the same time any improvement in the arena needs to try to stay multi platform, the more platforms the better.

 

If those are both correct I understand both completely

 

However for serious transcoding resource comparisons mb3 is still taking a back seat to plex. At the same time it seems like you guys probably want to keep expanding to nas platforms for the server. The only catch will be that nice clients won't woo people to switch if resources for reaching those clients is still brunt ffmpeg

 

At the same time I understand the server is on github and the community has to build up around this concept for mb3 server to reach the popularity and prowess of open source projects like the kodi.

 

A solution that would allow the server to reach out to NAS devices but more efficiently handle transcoding on the plethora of quicksync ready severs (including many higher end NAS devices) may be to decouple transcoding from streaming then work the requirements for a suitable "transcode proxy" into place so that more customizable, hw accelerated, and fps throttled transcoders could be introduced and maintained almost as a plugin or branch without needing so much in the core

Link to comment
Share on other sites

Improving transcoding in general is very important to us but there are a lot of things that are very important so it all takes time.  Projects like this one where you guys took on trying this out yourselves are very helpful because it allows this type of proof of concept (or proof of not working) to happen without the core team having to stop doing something else that is also important.  

 

Using GPU transcoding specifically, may or may not be that important because, as you've found, it may not really add that much and it is so specific to certain hardware environments.

 

So, yes, we agree that improvements in transcoding will be required moving forward and we will get there.

  • Like 1
Link to comment
Share on other sites

dark_slayer

So, yes, we agree that improvements in transcoding will be required moving forward and we will get there.

Thanks, but I was trying to ask a lot of vague questions pointing to the mediabrowser "directive" ;) Anyway, good to know it's definitely on the radar

 

 

Using GPU transcoding specifically, may or may not be that important because, as you've found, it may not really add that much and it is so specific to certain hardware environments

Under the right environments QS and NVENC will add a crap-ton, but maybe not within ffmpeg right away (hence what might be the need for the possibility of other tools and a transcoding "framework" that ffmpeg can plug into alongside the other stuff)

 

Like you were alluding to, pure GPU offloading doesn't offer much without the hardware encoders ~ hence it probably won't end up multiplatform . . . maybe ever. This is where something like a proxy or framework usually works since that can certainly be multiplatform. The way you have added PVR, but the preference would be a little different on this where the ffmpeg default would need to ship with the install like it does now. Adding another transcode engine to use that same framework or api would just be something you could tuck away in an advanced setting

Link to comment
Share on other sites

Personally, based on the changelog for the upcoming release of ffmpeg, I think it's best to wait.

- DXVA2-accelerated HEVC decoding
- Intel QSV-accelerated H.264 decoding

If they're working on accelerated decoding, then I would guess accelerated encoding is sure to follow in the coming months.

Link to comment
Share on other sites

From everything I've seen we have a ways to go for GPU encoding to be really useful for us in MB3 land.  This is based on the builds available at present.  There are other 3rd party software we could possibly use such as HandBrake and QSEncoder but this would take a lot of changes in MB3 itself. These are possible but maybe not worth it (right now) considering some of the other improvements in the works.

 

dark_slayer, there are other things going on with transcoding at present (in other threads) that will level the playing field of MB3 to Plex and then surpass it.  For example Luke has just implemented and is fixing any little bugs showing themselves with concern to being able to pause and resume transcode sessions.  This will allow MB3 on the surface to work similar to Plex in that it can "throttle" encodes as needed and be able to support more encoding streams at one time.

 

I must say transcoding on Plex is one of the very strong features that generally just works. However, with that said, as you probably know by now, when the MB3 team takes on such projects it's done well and not half baked. Typically feature for feature what is implemented in MB3 is better than in Plex and I don't think transcoding will be any different once completed.

 

Once this pause/resume feature matures a bit more we can use the proxy technique to do distributed encoding for those with additional computers available.  This will single handedly allow MB3 to scale far further than Plex in the number of clients it can transcode to simultaneously. 

 

So the point being that there are things in the pipeline that will level the playing field then set us up to surpass what MB3 can do compared to Plex. :)

 

Carlo

  • Like 2
Link to comment
Share on other sites

vanstinator

FYI,

 

I took a change of pace to keep things moving.  I commented in another thread about this but wanted to comment here also.

 

One of the things I said I wanted to do besides the GPU transcoding was to enable distributed transcoding.  So if you have multiple computers on your network then you would have the ability to run some of the ffmpeg jobs on these computers instead of just the MB3 server.

 

I have a working proto-type of this with a 2nd computer doing all the ffmpeg jobs.  I need to ad intelligence and other stuff but just getting this to work in proto-type functionality is a very good thing.  So at some point in the near future the MB3 server will be able to wake up other computers on the LAN and send them ffmpeg transcode (or bif - rokus trick) jobs.  This will be useful for real time viewing, syncing or bif generations.  Basically anything using ffmpeg.

 

Of course once we have GPU encoding working then this will work on the MB3 server or any other LAN computer too!

 

Good stuff,

 

Carlo 

 

So I've been following you on the Plex forums too, and if you get a stable enough implementation into a beta type stage I'd be all over this. This could quite possibly get me to switch from Plex. Half baked features and lack of scalability is pushing me out. I like this thread. It gives me warm fuzzies.

  • Like 4
Link to comment
Share on other sites

Happy to see you here. Your first post and you already have multiple likes :)  Since you've been following me "over there" you know I feel the same.

 

I already have the distributed encoder working but it's not intelligent yet and I haven't played with it in about 2 weeks as work was piled up.  I'm in the middle of the East coast snow storm so I'll probably have a few days to play with it as I just got caught up on work again (someone resigned and I picked up some of the backlog as it was holding me up).

 

Welcome!

Link to comment
Share on other sites

dark_slayer

dark_slayer, there are other things going on with transcoding at present (in other threads) that will level the playing field of MB3 to Plex and then surpass it.  For example Luke has just implemented and is fixing any little bugs showing themselves with concern to being able to pause and resume transcode sessions.  This will allow MB3 on the surface to work similar to Plex in that it can "throttle" encodes as needed and be able to support more encoding streams at one time

 
This sounds good, but I don't entirely understand. I can already pause and resume what I'm transcoding. Typically my in laws pause and leave crap paused, indefinitely  :rolleyes: At least until they come back tomorrow and watch something else (stop and back are not understood). An administrative "stop-and-record-resume point-after-15-minutes-of-pause" it would go a long way for me.
 
Are you talking about a realtime "read-ahead" pause? Only 5% or so is transcoded ahead and then paused until more is needed?

 

 

I must say transcoding on Plex is one of the very strong features that generally just works. However, with that said, as you probably know by now, when the MB3 team takes on such projects it's done well and not half baked. Typically feature for feature what is implemented in MB3 is better than in Plex and I don't think transcoding will be any different once completed.

I couldn't agree more. It felt like just a month ago we'd be announcing to the world that MB3 has QS transcoding support at this point. Since my server is a steam-IHS / Limelight gaming server as well now, QS and NVENC are both at my disposal. It feels like driving a McLaren F1 through a school zone :D

 

I have my suspicions to why QS never made many waves in ffmpeg, and I don't know when they would ever tackle nvenc

 

 

These are all just my thoughts of course. Waiting on ffmpeg will be like waiting on a human Mars landing in my mind. It may happen in our life time, but hardly anyone is even talking about it and it's not "really" planned

 

A framework that other tools besides ffmpeg could plug into may be a lot of changes or too many changes, but de-coupled github projects seems to be the way to go. I don't really know anything about what's inside the server code. I've looked at some of it and maybe understand 1% of what I look at, so I'm not in any way useful to the real conversation here. I do at least know and have read about monolithic vs modular concepts as that pretty much relates to everything in life and not just software (which I know barely enough about to use ;) )

Link to comment
Share on other sites

Yes, to the first one.  Transcoding is now starting to work like Plex does where it only transcodes enough to stay ahead of the client.  Previously in MB3, once you started watching something that required transcoding it would use ffmpeg and go "balls to the walls" running in the background until it was finished.  So if the user paused the movie it wouldn't matter to the ffmpeg process. It now has some "smarts" and will get smarter as time goes on.

 

To the second part.  MB3 supports multiple different TV back ends that the user can configure.  We could do something similar for transcoding.  I believe Media Portal does transcoding like this. There is nothing in the architecture to stop us from doing this also. We're just not there yet.

 

If you go back and read the first page or two of this thread you can see we've done some testing of QuickSync and found a few programs that could be used.  We know the limitations and what would need to be done to use them in MB3.  So the research is done.  I guarantee there will be some background dev going on to try and make use of these other programs. But we need to "walk" before we "run".  :)

  • Like 1
Link to comment
Share on other sites

dark_slayer

Yes, to the first one.  Transcoding is now starting to work like Plex does where it only transcodes enough to stay ahead of the client.  Previously in MB3, once you started watching something that required transcoding it would use ffmpeg and go "balls to the walls" running in the background until it was finished.  So if the user paused the movie it wouldn't matter to the ffmpeg process. It now has some "smarts" and will get smarter as time goes on

 

Great. I gathered transcoding was working that way, but not until after I had made a few comparison tests and posts in this and other forums :(

 

I don't recall reading it anywhere, but I finally noticed ffmpeg would go away and do nothing about 3 minutes into an episode of south park whereas plex would hum along (at low resources) throughout. I posted this in the slickdeals wiki on the android app without really knowing it for sure, but with enough evidence to assume. Thanks for forthright clarification

 

I look forward to running, but walking will be welcome as well. NVENC cooks with mapp-gas ;) I'll just keep following along with updates to different encoders and new/working projects to see if any really take that power and run with it

Link to comment
Share on other sites

  • 2 weeks later...
itsrumsey

Once this pause/resume feature matures a bit more we can use the proxy technique to do distributed encoding for those with additional computers available.  This will single handedly allow MB3 to scale far further than Plex in the number of clients it can transcode to simultaneously.

 

I think you may be overestimating the ease of implementing a distributed system...

 

It is sad to see not much has happened in over a month with regards to hardware encoding since mjb2000 has gone MIA and was the only person working on a modified version of ffmpeg, however like Luke pointed out it may just be best to wait for the ffmpeg team to implement themselves, which could potentially happen any month now.

 

There are plenty of other QS and NVEnc example softwares that show there are huge gains to be made by using a hardware encoder, and I imagine popularity of this setup will flourish with the adoption of lower power Intel devices with HD graphics integrated.  Personally I am in a weird position because I need to host more transcode streams at any given time now and we are in an inbetween phase where it doesn't quite make sense for me to drop $150 on a new CPU when a $50 will do just as good when ffmpeg supports QS encoding.

 

I do think the proxy idea will be the perfect solution at that time because it can be more or less seamlessly integrated to MB3 without any changes being necessary by the MB3 development team.  It looks like for now the right choice is to continue to (unfortunately) leave MB3 running on my gaming PC instead of my media server and hope that mjb2000 or the ffmpeg team make some progress with over the next few months.

Edited by itsrumsey
Link to comment
Share on other sites

dark_slayer

however like Luke pointed out it may just be best to wait for the ffmpeg team to implement themselves, which could potentially happen any month now

 

I really don't put any faith in ffmpeg to do anything. As far as I could tell what @@Luke mentioned was just a conjecture based on an announcement that wasn't specific to using QS in the encoding process

 

The web has already been "waiting" for QS to be picked up by ffmpeg since QS was a reality and Intel was paying people to write about it ;)

 

If anyone knows something more about it with a github link or some nightly release notes I'd love to see/read about it

Edited by dark_slayer
Link to comment
Share on other sites

  • 2 weeks later...

I think it has been discussed before, but someone who knows this stuff should really have a look at gstreamer. My qnap nas with a celeron cpu does HW assisted transcoding, using qstreamer and quicksync typical speed is about 10x original without hammering the cpu much.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
tgusler

Slightly off topic now but do these tweaks support AMD QuickSync or just the intel variant? I have an A10 that supports QS and would like to utilize it so I can host more streams, use less power, and reduce cpu usage. If I can put the cpu in 65watt mode and transcode using tweaks then I'd rather do that

 

 

edit:

I was under the impression that QS was Intel only but I could swear that when I updated my drivers there is a QS option in there. Will double check when I get back to my machine.

Edited by tgusler
Link to comment
Share on other sites

itsrumsey

Slightly off topic now but do these tweaks support AMD QuickSync or just the intel variant? I have an A10 that supports QS and would like to utilize it so I can host more streams, use less power, and reduce cpu usage. If I can put the cpu in 65watt mode and transcode using tweaks then I'd rather do that

 

 

edit:

I was under the impression that QS was Intel only but I could swear that when I updated my drivers there is a QS option in there. Will double check when I get back to my machine.

 

There is no such thing as AMD QuickSync, however some newer AMD products support hardware encoding through their Video Coding Engine.

Link to comment
Share on other sites

dark_slayer

I really don't put any faith in ffmpeg to do anything. As far as I could tell what @@Luke mentioned was just a conjecture based on an announcement that wasn't specific to using QS in the encoding process

 

The web has already been "waiting" for QS to be picked up by ffmpeg since QS was a reality and Intel was paying people to write about it ;)

 

If anyone knows something more about it with a github link or some nightly release notes I'd love to see/read about it

Well I'll be a monkey's uncle. Ffmpeg 2.6 with nvenc support?

 

Edit: 2.6 not 2.6.2 http://git.videolan.org/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES;hb=release/2.6

Edited by dark_slayer
  • Like 1
Link to comment
Share on other sites

Tranquil

Good hint. Hopefully it will now take its way into emby!

Edited by Tranquil
Link to comment
Share on other sites

  • 2 months later...
Bigjohns97

So is there still no QS support?

 

I just noticed the other day when watching a Live tv show on another machine that this is eating up 60-70% of a brand new devil's canyon CPU.

 

This makes it almost unusable for doing more than one at a time and QS integration in this area would blow away the performance of just a regular ffmpeg implementation.

 

How is this not implemented yet?

Link to comment
Share on other sites

Shaneus

I'm coming into this late (and first-time poster here) but this was posted in another thread:

More specifically:

Entries are sorted chronologically from oldest to youngest within each release,

releases are sorted from youngest to oldest.

 

version <next>:

- colorkey video filter

- BFSTM demuxer

 

 

version 2.7:

- FFT video filter

- TDSC decoder

- DTS lossless extension (XLL) decoding (not lossless, disabled by default)

- showwavespic filter

- DTS decoding through libdcadec

- Drop support for nvenc API before 5.0

- nvenc HEVC encoder

- Detelecine filter

- Intel QSV-accelerated H.264 encoding

- MMAL-accelerated H.264 decoding

- basic APNG encoder and muxer with default extension "apng"

- unpack DivX-style packed B-frames in MPEG-4 bitstream filter

- WebM Live Chunk Muxer

I'm only just coming into this as I'm looking at finding something to transcode live TV on my i3-2100 (that has QuickSync) for my PS4. Looks like I came in at around the right time.

 

Hoping this isn't something that is tricky to implement properly!

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