Jump to content

Hardware acceleration and Intel video drivers


TheShanMan
 Share

Go to solution Solved by TheShanMan,

Recommended Posts

I recently converted all my symlinks to hardlinks because I read in another thread that symlinks are problematic. That seems to have helped with videos playing reliably on my phone itself. However, some videos don't want to cast to my chromecast devices. I get the spinner on my TV, then I get the player controls at the bottom of the Emby app, but after about a second both go away and the picture for the video.

 

It's not obvious to me from looking at the log file what the problem is however I see that ffmpeg quits after maybe a half second.

 

I restarted the server, turned on debug logging, and then performed my test in order to capture full detail but not more than necessary. The log is attached.

 

2 questions:

  1. Why is it failing and how do I fix it?
  2. Why is it trying to transcode? It's not a high bandwidth file. Does chromecast require a fixed resolution like 1080p in order to avoid transcoding?

Log.txt

Edited by TheShanMan
Link to comment
Share on other sites

Sorry, I didn't notice that you also have to click "attach this file" to get the log file uploaded. It's now attached to the original post. I've also found the ffmpeg log files and they're attached here. Thanks!

logs.zip

Link to comment
Share on other sites

It seems that you are running Emby on a server without having a monitor connected.

 

Emby has probably incorrectly detected QuickSync to be available on the virtual graphics adapter ("QuickSync RDPDD Chained DD").

 

This kind of incorrect detection had been fixed in the latest beta versions.

 

For now, you should disable those incorrectly detected hardware acceleration codecs by selecting the "Advanced" configuration.

 

 

PS: The upcoming beta will support QuickSync in headless (no-monitor) configurations!

  • Like 1
Link to comment
Share on other sites

I do have a monitor connected. My Emby server is also my TV where I run Emby Theater. That said, the TV is powered off almost always when I encounter this failure to cast (different TV).

Link to comment
Share on other sites

I'm not seeing where to configure the codec stuff. I assumed you were talking about Emby server settings but the Advanced page doesn't have codec stuff and I can't find it on other server settings pages.

Link to comment
Share on other sites

  • 2 weeks later...

That seems to have been the problem. I haven't seen it happen since making the change you suggested. However, I still see the QuickSync options in 4.0.3. Maybe you meant it's fixed in builds after 4.0.3?

Link to comment
Share on other sites

  • 4 months later...

This problem seems to have resurfaced on the very day I installed server 4.2.0.40. I still see QuickSync listed so I tried moving that choice to the bottom of the lists and checking the other option, however I'm still not able to start playing videos on chromecast. I had to disable hardware acceleration entirely to get it working. Logs attached.

logs.zip

Link to comment
Share on other sites

Can you try installing the latest intel video drivers and then reboot your machine? Thanks.

Link to comment
Share on other sites

  • 3 weeks later...

I was having trouble casting from my phone to a chromecast yet my wife could cast the same video, using the same emby user just fine. I just looked at the transcoding log and it says

 

[h264_qsv @ 0000000002f6ba40] Error initializing the encoder: invalid video parameters (-15)

Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

Turns out I had streaming quality set to something other than "auto". Couldn't Emby be a little more helpful in detecting that the transcoding settings need tweaking and suggest something helpful like "try setting the streaming quality to auto" (or a specific quality level)? Or even just "the current transcoding settings aren't supported by your device"? Instead, it acts like it's trying to play but the player controls just show it remaining at 0:00 eternally, so the emby app doesn't even seem to realize the server decided not to start the stream.

Link to comment
Share on other sites

OK, happy to do that but in case it wasn't clear, I wasn't seeking help solving my problem. I was suggesting an enhancement to make it easier for end users to realize why emby isn't working. Anyway, I put back the faulty settings in the android app and reproduced the problem. Logs attached.

 

A further thought on enhancing this... if Emby can't play with the given quality settings, perhaps it could ask the user if it could override their chosen quality settings (or actually change them) to a quality setting that would work, or might work.

logs.zip

Link to comment
Share on other sites

I rather think that this is hardware acceleration problem.

 

Your log is showing a QuickSync device named "RDPDD Chained DD". Do you know what that is? I've never seen it.

 

Does hw acceleration work at all in other cases? I suppose it doesn't..?

Link to comment
Share on other sites

I was told in another thread that the faulty detection of that device was fixed in a newer version of the server. The issues I was experiencing at that time went away once I went in and manually disabled them. But since the fix I set it back to automatic detection and haven't encountered any issues other than if this one is related. Let me know if you'd like me to dig up that thread.

 

My only guess as to what it is would be due to the "RDP" part of the name. I always have an RDP session to my Emby server/htpc open (i.e. I have 2 active sessions, the TV session and the RDP session). So that's my best guess.

 

Attached the detection log.

hardware_detection-63701541223.txt

Link to comment
Share on other sites

Thanks for the log. The detection is working correctly. We cannot exclude this device from being detected based on a string search (e.g. 'RDP') because there might be legit cases where this would actually work.

So I'm afraid, but the solution for your case remains the same: To disable it in Emby's transcoding settings.

Link to comment
Share on other sites

I can do that, but are you saying that is the reason having non "auto" quality settings weren't working? And disabling that device would make non "auto" quality settings work?

 

Incidentally, you're the one who said the improper detection of that device was fixed, for whatever that's worth: https://emby.media/community/index.php?/topic/70839-hardware-acceleration-and-intel-video-drivers/

Link to comment
Share on other sites

The automatic fallback from GPU to CPU isn't happening here in this example, so that's one thing that we should be able to get corrected.

Link to comment
Share on other sites

I can do that, but are you saying that is the reason having non "auto" quality settings weren't working? And disabling that device would make non "auto" quality settings work?

 

Yes, correct. Except that the exact distinction is not between "auto" and "non-auto". It is rather about whether the selected "non-auto" bandwidth is lower than the bandwidth of the original file.

In the latter case, transcoding is required to reduce the bandwidth. And that's the point where a transcoding error can prevent playback.

Normally, it should automatically fall back to cpu transcoding instead of hw transcoding, but in case of chromecast that doesn't work right now.

 

But even when we would have the fallback working, you would not want it because it adds to the startup delay when doing playback.

 

Incidentally, you're the one who said the improper detection of that device was fixed, for whatever that's worth: https://emby.media/community/index.php?/topic/70839-hardware-acceleration-and-intel-video-drivers/

 

Yes, that is correct. The fix we had done was to check for the 'VendorId' of a device's graphic drivers and exclude devices where that VendorId is Microsoft's vendor id, which in turn means that the device is a virtual device, not a physical one. Obviously that check doesn't seem to work in your case.

Link to comment
Share on other sites

@@TheShanMan - sometimes hardware drivers have bugs of their own, and sometimes they knowingly report the wrong information in order to force applications to act a certain way.

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
 Share

×
×
  • Create New...