Hardware encoders do not work on macOS Ventura #2272
Comments
|
|
|
Would it be possible to add more encoders supported by Sunshine or to add the ability to explicitly specify what device should be used for encoding. Or do you think it's not really a solution? |
|
I went with Apple's own "Screen Sharing" for the time being but it would be lovely to have it all in my place (Moonlight) =) |
|
I might be hitting this in #1603 as well. I'm not sure if what I'm seeing is exactly the same though. https://github.com/LizardByte/Sunshine/actions/runs/8313001334/job/22748528257#step:12:5742 |
|
Did you grant screen sharing permission? |
I did grant screen sharing permission. And here's a video of the problem I'm having: even with software encoder it fails to properly capture the screen (it looks like the mouse cursor and some other UI elements are "shaking") but in reality (on the actual screen) mouse cursor moves properly. It's just that Sunshine/Moonlight fails to capture/reproduce the image properly IMG_3580.mp4 |
ReenigneArcher
changed the title
|
I'm getting the exact same issue on macOS Monterey, using Sunshine installed with brew. However, I'll mention that my setup is a little unusual because I am running all this on a virtual machine with GPU (AMD Radeon Pro WX4100) passthrough using QEMU. Games are able to utilize the GPU just fine. Same log output and same "shaking" or "stuttering" effect when connecting through Moonlight on Linux. |
|
@lulzsun that's actually my setup here 😁 |
|
Did a little digging around, appears that #2347 might be the exact same issue described here. A user says an older build of sunshine worked, will try later when I get the chance. |
|
Tried version 0.14.1 of sunshine and surprisingly software encoding works and that shaking/freezing issue is resolved. Hardware encoding still doesn't work and the error logs still output the same thing as the latest version. |
|
@lulzsun did you install sunshine using brew or something else? |
|
version 0.14.1 of sunshine doesn't seem to be available in brew and I'm having trouble building it myself |
|
You shouldn't even attempt to use a version that old... that are several security issues we have fixed in the past 2 years. |
|
@ReenigneArcher I see.. any idea as to why there might be a regression on macOS between those versions? |
|
Sorry, I don't know... we would need to know the first version that doesn't work, then try to narrow it down to a specific commit between the last working version and the first broken one. |
|
@ReenigneArcher @lulzsun I did a short test of different versions of Sunshine on macOS and here's what I got: v0.21.0 - doesn't work properly (see my video above) I'm happy to find a version of Sunshine that works propertly (v0.19.1) for me and now I'm happy |
|
Tried v0.19.1 and unfortunately hardware encoding still doesn't work for me, but at least software encoding is still usable. |
|
@lulzsun and does your hardware encoder gets detected and working properly with other applications? (e.g. Hanbrake, videoproc) You should see something like this: #2272 (comment) |
|
@VasylBaran Apparently it doesn't... I just assumed it was working. I installed VideoProc to check and it says HEVC and H264 were both unavailable/disabled. Not sure why that is the case. I think my GPU should be able to support it, but I'll have to look into it further myself as it seems like it is unrelated to Sunshine now. |
|
+1 Encountering this issue on an RX 550 Lexa card spoofed to 67FF in Mac OS Ventura OSX-KVM under Proxmox (Ryzen 7 1700) |
|
@lulzsun @xXTeraXx I did a small “research” on this topic in the past. Here’s a list of articles and guides that I found useful enough to save them:
|
|
@VasylBaran thank you for testing the different versions! I'm not sure the cause of the issue at this point, but here is all the changes from v0.19.1 to v0.20.0. https://github.com/LizardByte/Sunshine/pull/1115/files |
|
Can confirm, version 0.19.1 works for me too. Newer versions don't. macOS 14.4.1 |
@VasylBaran Thanks, this was helpful in figuring out that I was using the wrong SMBIOS required for enabling hardware acceleration. It seems like it "works" now (using version 0.19.1), but this time I ran into another problem. Not sure if it is related to Moonlight/Sunshine, but I get this weird color artifact in addition to higher latency compared to using the software encoder. Screenshot: With hardware encoder
Screenshot: With software encoder
Sorry if my issue is now off topic since it might no longer be related to the original issue. |
|
@lulzsun how about the current version when using the correct SMBIOS? |
Unfortunately still getting the same initial issue on version 0.23.1 installed using brew (no hardware encoder detected and shaking/freezing issue with software encoder). Will be sticking to 0.19.1 and forcing software encoder for the time being until the issue is figured out in latest version. |
|
@ReenigneArcher found the issue. First it was in commit So after trying to fix the retain/release cycle of this change without success, I decided to just revert the necessary changes, taking care to not remove newer unrelated changes, and it's now working for me even with the If you have any improvement suggestion, for example how to fix without fully reverting PR: #2485 |
|
@Hazer just wanted to say 'thank you!' for taking the time and looking into it. Kudos! |
|
If anyone using homebrew wants to try out my branch (@VasylBaran I'm looking at you), you can download the file here: unzip the file downloaded, then run in the same folder: This should install the version with my most recent changes. While reverting those changes helped, I think now I got a proper implementation of the fix, testers welcome. |
|
Hi, I've been trying to install this version or the last one that worked (v19 apparently) without succes. I'm using macports, not homebrew. Do you know when will it be merged with 'nightly' so I can try that branch? Thanks for all the work! |
I can confirm that this build works well on an M1 Macbook Air, although I do see an interesting "Error: Encoder did not produce IDR frame when requested!`" error in the logs. Can't test it on AMD-based system at the moment, but I don't think this issue was linked to a any particular system. Looks like the problem I logged is fixed in this build, encoders are being correctly identified and used ;-)
|
|
@VasylBaran Thanks for the test! Yeah, this missing IDR frame message is happening with me too, on my RX 570, but I think it's another issue for a new PR, and don't seem to break the stream. I guess some GPUs need some tweaks to the GOP/Keyint settings for optimal usage, but that's another round of experimentation. Having it at least working again makes things easier! |
yes, thanks again for doing this! |
|
It's working for me now with the last nigthly. I think is not using hardware encoder correctly, but I didn't try before the patch so I have to do more testing. But now the mouse works and the screen doesn't get stuck. |
|
@ArtanisKrall if hardware encoding still don't work for you after your tests, please open another issue with your details, gpu, logs, etc, and a print of your VideoProc converter status, so I can give it proper attention. |
|
Thanks! Don't worry I have to do more testing first. It's my first time using MacOs, its a virtual machine with GPU-Passthrough and I'm not familiar with this card capabilities (its a RX 460 4GB). I have to figure out what I am doing first... |
|
@Hazer I could be wrong but I don't believe that streaming on macOS Sonoma is working correctly. I'm using the code from This is on an M2 Mac but I was seeing the same issue with an Intel Mac with 5700 XT (confirmed using Video Proc that the encoder was working). Interestingly, less CPU cores light up with software encoding forced. 
|
|
I've determined that the high CPU usage occurs when you allow HEVEC to report HDR as being available or leaving it set to automatic. CPU usage returns to normal when the available HEVC options are explicitly set. Even with normal usage, Sunshine on macOS still feels around 400ms laggier than Windows (using the same client) so I think I'll need to stick with VNC for now. |
|
@lprhodes did you get high CPU usage after you changed sunshine's default settings or do you get high CPU usage with default settings? |
|
@lprhodes can you please open a new issue for this? I don't have a client with HEVC decoding support, nor HDR, to test it right now, but maybe someone has. |
|
@VasylBaran @Hazer default settings. I certainly can open a new issue. Aside from the excessive CPU bug, what work (if any) do you think can be done to improve the overall performance of Sunshine on macOS so that it sits closers to that of Windows? I have some free time coming up that I'd like to dedicate to this. Is ffmpeg the primary bottleneck? |
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the nightly release?
Describe the Bug
Sunshine fails to use hardware encoders on macOS despite the fact that other applications (e.g. Hanbrake, videoproc) can.
It falls back to default software encoder but it's full of graphical glitches/atrifacts.
Expected Behavior
Hardware encoder should be found and used by Sunshine (on macOS)
Additional Context
I see the following message in logs:
Error: [h264_videotoolbox @ 0x7f9470706140] Error: cannot create compression session: -12902
[h264_videotoolbox @ 0x7f9470706140] Try -allow_sw 1. The hardware encoder may be busy, or not supported.
Error: Could not open codec [h264_videotoolbox]: Generic error in an external library
Info: Encoder [videotoolbox] failed
Host Operating System
macOS Ventura
Operating System Version
13.6.5
Architecture
64 bit
Sunshine commit or version
0.22.1
Package
macOS - brew
GPU Type
AMD
GPU Model
RX 6600
GPU Driver/Mesa Version
n/a
Config
Apps
No response
Relevant log output
The text was updated successfully, but these errors were encountered: