GPU Transcoding (Intel QuickSync and nVidia NVENC)

[Deihmos 147]

I went back to final.

[millsii 8]

I have been following this thread for a while and decided to try out Intel Quick Sync. All seems to work very well both with local and remote streaming. However, for remote streams, ffmpeg continues to run after the client has stopped the stream. For local streams, ffmpeg is always closed.

 

EDIT: Sorry, I did attach two transcoding log files of remote streams. One with Auto transcoding that did close ffmpeg and the other with Intel Quick Sync that did not close ffmpeg. I just realised they showed my dynamic address, so deleted them. I will post new logs tomorrow. Sorry again, but dont know how to delete entire post from phone?

Edited May 8, 2016 by millsii

[Luke 37329]

I have been following this thread for a while and decided to try out Intel Quick Sync. All seems to work very well both with local and remote streaming. However, for remote streams, ffmpeg continues to run after the client has stopped the stream. For local streams, ffmpeg is always closed.

 

EDIT: Sorry, I did attach two transcoding log files of remote streams. One with Auto transcoding that did close ffmpeg and the other with Intel Quick Sync that did not close ffmpeg. I just realised they showed my dynamic address, so deleted them. I will post new logs tomorrow. Sorry again, but dont know how to delete entire post from phone?

 

Hi, welcome. that's unrelated. Please report that issue in the community section for the app that you're playing from. Thanks.

[Tranquil 93]

Shouldn't the server decide, when to terminate a ffmpeg session? I'm having the same problem since qsv was introduced. The server shows correctly, at least in the dashboard, that no playback is currently running but keeps the ffmpeg process alive. 

 

EDIT:

It also happens to me when using chrome on my mobile.

Edited May 9, 2016 by Tranquil

[millsii 8]

Apologies Luke if my post was in the wrong thread. I thought it might be relevant in this thread as it is happening across multiple clients, Chrome and Android. It only occurs when Intel Quick Sync is selected. I have reverted back to Auto transcoding and all is well.

[witteschnitte 7]

Any news from the developers for changing the ffmpeg "vsync" parameter to "-1" instat of "cfr".

 

I posted it long time ago, but i got no response.

 

Regards

[Luke 37329]

i have not had a chance to test it.

[witteschnitte 7]

I dont understand what the developers are doing. In the last update you remove the ffmpeg quicksync decoding part -c:v h264_qsv....why?????

It worked so very well

 

Instead of adding the vsync -1 Parameter, you removed the half quicksync functionality

Edited May 22, 2016 by witteschnitte

[Luke 37329]

I dont understand what the developers are doing. In the last update you remove the ffmpeg quicksync decoding part -c:v h264_qsv....why?????

It worked so very well

 

Instead of adding the vsync -1 Parameter, you removed the half quicksync functionality

 

Because features have to work properly in order for us to use them, or users just end up frustrated. Encoding is where the real benefits are, not decoding. Maybe your proposed change is a solution, maybe it is not, but it takes time. We have been using that command line param for a couple years now, it is not something we can just quickly change on a whim, it takes time to understand what the side effects might be with all of our supported media types on all of our supported operating systems.

[witteschnitte 7]

Thank you Luke for your fast reply.

I unterstand what you mean.

But what are the changes und this update with quicksync?

before this update i got 5 till 10 percent cpu usage with quicksync.

now i got 50 percent and more.

 

So something is changed in the emby side

[Luke 37329]

A change in decoding is not going to cause that kind of difference, so more than likely it's a change related to encoding. Please open a new topic and see how to report a media playback issue. Thanks!

[witteschnitte 7]

Sorry but i think if there is a problem in embys quicksync config i think this will be the right place.

 

How can i go back to emby version 3.0.5934???

 

because in the ubuntu repository only the new one exists. But this new version fills up my CPU with quicksync.

Do i have a chance to go back??

 

Regards

[Luke 37329]

What i'm saying is that if quicksync is not being used, then it's not related to quicksync. Regardless without seeing any logging info, it's very difficult to help.

[witteschnitte 7]

Thank you for your answer. 

If i look in the transcoding logs it looks simalar to the old ones. instead of the ffmpeg decoding part.

In the transcoding logs i dont find a hint why my cpu gets burned.

 

are there other logs i can view to test?

[witteschnitte 7]

I´m testing around and found that it does not matter whether i use quicksync or not. the cpu usage will be the same.

In the transcoding log the quicksync codec is used. but if i look at my cpu usage it seems to have no effect.

 

I dont know what to do

[Luke 37329]

what i'm going to do on the dev branch is make the vsync change and then we'll see how it goes during this release period. if there are no issues then we can make it a permanent change.

[witteschnitte 7]

Thanks Luke. But this parameter only helps if the Video play jerky.

This issue with the high cpu usage will not be healing by vsync

Edited May 23, 2016 by witteschnitte

[chvb 1]

Can someone post an updated Guide how it is possible to enable the nvenc transcoding with an Nvidia Card?

thanks

Edited May 23, 2016 by chvb

[Tranquil 93]

Not possible immo. :-(

[Luke 37329]

the first step with nvidia is you have to supply your own ffmpeg build with the proper decoders and encoders built in.

[doughaas 0]

the first step with nvidia is you have to supply your own ffmpeg build with the proper decoders and encoders built in.

Assuming providing a proper ffmpeg build isn't an issue how would we go about getting emby to recognize it?  I've tried looking at the config/encoding.xml as mentioned way back in this thread but the format of that file seems to have changed since then.

[Luke 37329]

Assuming providing a proper ffmpeg build isn't an issue how would we go about getting emby to recognize it?  I've tried looking at the config/encoding.xml as mentioned way back in this thread but the format of that file seems to have changed since then.

 

You would have to replace the current ffmpeg builds within the ffmpeg sub-folder. Be aware though that some of our linux packages specify the path to ffmpeg on the command line:

 

http://emby.media/community/index.php?/topic/3634-linux-setup/

 

If the path is being specified on the command line then there is currently no way to override apart from replacing the ffmpeg and ffprobe files at that location.

[chvb 1]

Assuming providing a proper ffmpeg build isn't an issue how would we go about getting emby to recognize it?  I've tried looking at the config/encoding.xml as mentioned way back in this thread but the format of that file seems to have changed since then.

 

Yes, thats the Problem. There are some changes. The transcoding will start but when i open the tank Manager i see that the transcoding uses the cpu. (Also when i look at GPU-Z the Card is idle). I'm using a Windows Installation to test this.

 

I have test this with my ffmpeg version wich i use with mcebuddy to convert media files. There i've got no problems using the nvidia ncenc encoding.

[witteschnitte 7]

Hi Luke i am going back to my question with the high cpu usage.

If i used the ffmpeg command emby is using and add the h264_qsv for decoding, quicksync runs nice again. and if i add vsync -1 it is also not jerky.

 

But if i remove the decoding Part, quicksync uses very high cpu.

 

So can you add the leading ffmpeg parameter h264_qsv for decoding back again?

 

without this quicksync is not working very well

Edited May 24, 2016 by witteschnitte

[Luke 37329]

It has to work before we can add it back. I don't want to have users coming in and reporting playback failures, unless you want to help respond to them So the best thing to do is participate in testing with either the beta or dev channel.