Transcoding - HW Acceleration not working properly

[Luke 42077]

Did you restart emby server after connecting the monitor?

[softworkz 5066]

Did you restart emby server after connecting the monitor?

 

Yes. Otherwise he wouldn't see the radeon entries now.

[iinthesky73 4]

@@softworkz

 

Yep.. I do

 

[iinthesky73 4]

Also.. you don't actually need to have the monitor physically connected. Just disabling the onboard video does the trick. Through it's still a mystery why it wouldn't be able to recognize both the onboard and the GPU card simultaneously.

 

Anyway, just another tidbit of information.

[softworkz 5066]

I found the problem: You are having the DXVA2 hw decoders for your Radeon now.

 

But the Radeon encoder is not detected.

For this, you will need to have a physical monitor connected _and_ run Emby server from a console session, not from a remote session (like remote desktop)

Otherwise it won't work.

 

And the decoders aren't used because you were playing msmpeg4 encoded videos for which no hw acceleration is available.

Edited January 17, 2019 by softworkz

[iinthesky73 4]

@@softworkz

 

 

Ok I will try again. That is peculiar though because the way I have it configured to run is, when the server boots up, the admin user is logged in automatically (not through a remote desktop session) and after login emby is set to run via startup folder. So technically, it is running as console login. There usually is no monitor connected though I simply don't understand why that would matter. Perhaps you can explain the technical reason at a later time. 

 

I just rebooted the box with a monitor attached and logged in and emby is running with the monitor attached from as a console logged in user. I'll run some tests.

 

Also, you are saying that hw acceleration for .avi is not available and won't be? 

 

Thanks a lot! 

Edited January 17, 2019 by iinthesky73

[Luke 42077]

@@softworkz

 

 

Also, you are saying that hw acceleration for .avi is not available and won't be? 

 

it is available for the container, for example if it had h264 video inside, but not when the video codec is mpeg4. At least not for your gpu.

[iinthesky73 4]

Hey let me say thanks for the attention to this problem. I am able to use Emby to watch my content but I would like to see this product function to the best it can possibly function! So again, I appreciate all the help and hope that I can help you guys out as well.

 

Anyhow.. So far I've tested several things with the prescribed conditions (monitor connected and emby server running fromc console login)-- i streamed a 1080p mkv file and a mp4 file and switched from Direct to 480p to force transcoding and I still see the same behavior. The GPU is doing absolutely no noticeable work. 

 

Maybe you can teach me a little about what to look for in these logs so I can see if there any changes in the conditions or functions of the encoders/decoders.

 

I've attached a few more logs below:

EmyServerLog.txt

ffmpegRemux1.txt

ffmpegRemux2.txt

ffmpegRemux3.txt

ffmpegTranscodeLog1.txt

ffmpegTranscodeLog2.txt

ffmpegTranscodeLog6.txt

ffmpegTranscodeLog7.txt

ffmpegTranscodeLog8.txt

HardwareDetectLog.txt

 

[Luke 42077]

Just FYI - in the remux logs this is expected because there is no video transcoding of any kind. That means no CPU transcoding or GPU transcoding.

[Luke 42077]

Also, what is your M: drive?

[Luke 42077]

In transcodelog7, it looks like you did get hardware decoding.

[iinthesky73 4]

In transcodelog7, it looks like you did get hardware decoding.

 

@@Luke

 

M: is my RAID array

X: is another STRIPED array of fast SSD for transcoding directory

 

I think I'm starting to understand better how this operates. 

 

If I am not mistaken, when a stream is transcoded the temp folder selected for transcoding is filled with re-encoded files at the desired or negotiated quality level.. Emby will continue to translate the file from beginning to end and save it in the folder until the entire file has been transcoded and then it will stop and just stream those pieces. I observed that if I leave it to transcode, eventually it will complete and the CPU usage goes back down to nearly 0.

 

Is that pretty much how it works?

 

Also, can you show me how to identify whether there is hardware decoding going on? 

 

I still don't understand why the majority of the work is being done by the CPU. Or is it? It's very confusing. I would imagine that the ideal operation would be to offload everything or nearly everything to the GPU which is made for this kind of stuff. 

Edited January 17, 2019 by iinthesky73

[Luke 42077]

 

 

Emby will continue to translate the file from beginning to end and save it in the folder until the entire file has been transcoded and then it will stop and just stream those pieces

 

Yes, but it doesn't transcode and then stream, rather it does both at the same time.

 

 

 

Also, can you show me how to identify whether there is hardware decoding going on? 

 

The server dashboard can tell you this information. There is an example in our release announcement:

 

https://emby.media/community/index.php?/blog/1/entry-447-announcing-emby-server-40/

 

if you are just looking at the ffmpeg log, you can see hardware decoding right here:

ffmpeg.exe -hwaccel dxva2 -hwaccel_device 0 -f matroska -i file:"M:\Movies\13 Hours (2016)\13 Hours (2016).mkv"

In fact, all of the ffmpeg logs had hardware decoding, it's just that some of them failed for unrelated reasons which I'm going to ask you about now.

[Luke 42077]

Can you zip up and attach this file?

M:\Movies\28 Weeks Later (2007)\28 Weeks Later (2007).eng.srt

ffmpeg is acting like it's a bad srt. Thanks.

[iinthesky73 4]

Can you zip up and attach this file?

M:\Movies\28 Weeks Later (2007)\28 Weeks Later (2007).eng.srt

ffmpeg is acting like it's a bad srt. Thanks.

 

Here you go:

 

 

13 Hours (2016).eng.zip

 

Ohh damn sorry wrong file

28 Weeks Later (2007).eng.srt

Edited January 17, 2019 by iinthesky73

[iinthesky73 4]

Yes I saw errors related to the GPU as well which I don't really understand.

 

In the 3.x versions, Emby appears to have been offloading much more work to the GPU because as I mentioned at the start, when I ran a stream requiring transcoding the mem and gpu clock and wattage kicked up indicating its working and the CPU was not used very much at all. Now it's the opposite which is really the crux of the curiosity here. 

 

While streaming earlier and switching the quality levels I did see a very very slight spike in the GPU wattage but no clock adjustments. So something was prodding some extra power into the GPU but again it's confusing because the CPU was working @ aprox. 80% the whole time. 

 

is there a way to drop this down to he command line level and run some commands to try to see if we can cattle prod the GPU with the ffmpeg binary outside of the emby plumbing?

[Luke 42077]

Here you go:

 

 

13 Hours (2016).eng.zip

 

Ohh damn sorry wrong file

28 Weeks Later (2007).eng.srt

 

I added these subs to a goldbergs episode and this is what i see. is that not what you're seeing?

 

[Luke 42077]

is there a way to drop this down to he command line level and run some commands to try to see if we can cattle prod the GPU with the ffmpeg binary outside of the emby plumbing?

 

yes you can always experiment with running commands against the ffmpeg binaries if you like. The paths to the files would be in any transcoding log.

[iinthesky73 4]

yes you can always experiment with running commands against the ffmpeg binaries if you like. The paths to the files would be in any transcoding log.

@@Luke

 

Ok i'll fool around with it. Seems we are still on square one though. Based on the performance of the 3.x version vs. the the 4.x update, we still don't know if its truly utilizing my GPU. From my point of view, it does not appear to be doing so. I think there was some mention of an update which will use DX11 or higher which might help to give Emby full access to Radeon GPUs... What is the plan for that?

[Luke 42077]

DX11 has been added in the server beta channel, in 4.1+.

[Luke 42077]

I see you edited the attached subtitles. Is it the 28 weeks later one that should be tested? If so can you please zip that up and attach it here? thanks.

[iinthesky73 4]

I see you edited the attached subtitles. Is it the 28 weeks later one that should be tested? If so can you please zip that up and attach it here? thanks.

 

Yes you asked for 28 Weeks Later and i pasted 13 hours for some stupid reason... I attached the 28 weeks later srt

 

28 Weeks Later (2007).eng.zip

[Luke 42077]

Yes you asked for 28 Weeks Later and i pasted 13 hours for some stupid reason... I attached the 28 weeks later srt

 

28 Weeks Later (2007).eng.zip

 

Where did you get these srt subtitles as they are mal-formed. The beginning is supposed to read:

1
00:00:50,040 --> 00:00:52,918
- What are you gonna cook?
- Your favourite.

But it is missing the 1 at the top.

[iinthesky73 4]

@@Luke @@softworkz

 

 

I have no idea. 

 

Notwithstanding... So, are we acknowledging this is a bug or an issue or we're not there yet?

[Luke 42077]

The subtitles are mal-formed, so they will not display, however, I would think we ought to be able to prevent it from causing the video to fail.