Sunshine
Sunshine copied to clipboard
LizardByte
Any kind of frame limiting makes the stream (micro)stutter
Is there an existing issue for this?
- [X] I have searched the existing issues
Is your issue described in the documentation?
- [X] I have read the documentation
Is your issue present in the nightly release?
- [X] This issue is present in the nightly release
Describe the Bug
Turning on any kind of frame limiting makes the stream (micro)stutter. I've tried limiting the frame rate in-game, using the Nvidia control panel and RTSS. Setting the frame limit to 59 fps with RTSS does give an ok-ish experience but anything else (I've tried 59-61, 88-91, 119-121) makes it pretty bad. Turning v-sync on or off without any limiting gets rid of the (micro)stutter with the unlimited frame rate giving the smoothest experience.
On the client side I'm using a Nvidia Shield TV Pro (2019) with Moonlight. I've tried all of the frame pacing options but none of them really get rid of the stutter. Setting Moonlight's frame pacing to "Prefer lowest latency" with an unlimited frame rate on the host gives the absolute best experience but it still occasionally has a stutter here and there.
I did notice that Sunshine adjusts the capture rate to the monitor refresh rate (60/59.951hz) (Adjusted capture rate to 59.951fps to better match display) while Moonlight forces my TV to 60hz (from it's default 59.xx hz) mode and I assume expects a 60 fps stream. If I remember correctly, setting my monitor to 100hz or 120hz made Sunshine adjust the capture rate to 59.999 fps which did reduce the stutter even while frame limiting. I'd prefer to use the dummy hdmi plug though which only supports 60/59.951hz at my preferred resolution.
I'm not quite sure where the actual issue lies but my gut feeling is telling me that it's something related to the adjusted capture rate and the mismatch between the host and client frame rate.
Expected Behavior
No response
Additional Context
G-sync is turned off; HAGS on or off doesn't change anything
Host Operating System
Windows
Operating System Version
10 (pre 22H2)
Architecture
64 bit
Sunshine commit or version
0.21
Package
Windows - installer
GPU Type
Nvidia
GPU Model
GeForce RTX 3070
GPU Driver/Mesa Version
546.33
Capture Method (Linux Only)
No response
Config
min_log_level = 2
fps = [30,60,90,120]
fec_percentage = 5
resolutions = [
2560x1440,
1920x1080
]
Apps
No response
Relevant log output
[2024:01:07:00:36:38]: Info:
Device Description : NVIDIA GeForce RTX 3070
Device Vendor ID : 0x000010DE
Device Device ID : 0x00002484
Device Video Mem : 8032 MiB
Device Sys Mem : 0 MiB
Share Sys Mem : 8156 MiB
Feature Level : 0x0000B100
Capture size : 2560x1440
Offset : 0x0
Virtual Desktop : 2560x1440
[2024:01:07:00:36:38]: Info: Active GPU has HAGS enabled
[2024:01:07:00:36:38]: Info: Using realtime GPU priority
[2024:01:07:00:36:38]: Info: Desktop resolution [2560x1440]
[2024:01:07:00:36:38]: Info: Desktop format [DXGI_FORMAT_B8G8R8A8_UNORM]
[2024:01:07:00:36:38]: Info: Display refresh rate [59.951Hz]
[2024:01:07:00:36:38]: Info: Requested frame rate [60fps]
[2024:01:07:00:36:38]: Info:
Colorspace : DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709
Bits Per Color : 8
Red Primary : [0.679688,0.30957]
Green Primary : [0.206055,0.693359]
Blue Primary : [0.151367,0.0546875]
White Point : [0.313477,0.329102]
Min Luminance : 0.5 nits
Max Luminance : 270 nits
Max Full Luminance : 270 nits
[2024:01:07:00:36:38]: Info: Adjusted capture rate to 59.951fps to better match display
[2024:01:07:00:36:38]: Info: Capture format [DXGI_FORMAT_B8G8R8A8_UNORM]
[2024:01:07:00:36:38]: Info: SDR color coding [Rec. 709]
[2024:01:07:00:36:38]: Info: Color depth: 8-bit
[2024:01:07:00:36:38]: Info: Color range: [MPEG]
[2024:01:07:00:36:38]: Info: NvEnc: created encoder P1 two-pass rfi
While adding HDR support to my dummy HDMI dongle using CRU I figured I could try forcing the refresh rate to actual 60hz instead of 59.xxxhz. This does reduce the stuttering quite a bit with frame limiting but it's still not great. I've settled on just using v-sync for now, this seems to be the most stutter free option.
I was experiencing the exact same issue on Linux with AMD RX 6800 XT.
To achieve stutter free experience I had to either bump FPS limit to 90 or enable VSync in game at 60 Hz.
Hmm will try the same 90 framerate limit but having the same issues, ans they are painfull actually opened a ticket for moonlight-android Can you check if you are expeeince the same? https://github.com/moonlight-stream/moonlight-android/issues/1319
Hmm will try the same 90 framerate limit but having the same issues, ans they are painfull actually opened a ticket for moonlight-android Can you check if you are expeeince the same? moonlight-stream/moonlight-android#1319
Try with 40mbps in 4k60, in have 5ms, it's no very good but ok .. ^^
I'm at 1080@60 25 mbps :) two different shield device same issue. Check the github issue that i've linked
I tried downgrading to the previous version as some people mentioned that elsewhere but that didn't change anything.
For now I've settled on 4k@60 fps HEVC at 150 Mbps om thewith I think frame pacing set to ~either low latency or never drop any frame (don't remember exactly)~ balanced + fps limit and on the host 4k@60 with VSync on. This seemed to work quite well last time while sim racing, guess I'll have to get used to the slight input lag because it's definitely noticeable compared to no VSync even with the wheel connected over the network with VirtualHere.
Anyway, as long as this keeps working like last time then I'm fine-ish with how it is. My current theory is that using a native resolution on the Shield/TV disables the AI up-scaling which possibly helps a bit getting a more stable frame rate.
EDIT: At 1440p@60 fps even VSync started giving issues with frame rate, that's why I tried 4k :)
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
I haven't played in a while but I imagine this issue is still a thing mister @LizardByte-bot
I did notice that Sunshine adjusts the capture rate to the monitor refresh rate (60/59.951hz) (
Adjusted capture rate to 59.951fps to better match display) while Moonlight forces my TV to 60hz (from it's default 59.xx hz) mode and I assume expects a 60 fps stream. If I remember correctly, setting my monitor to 100hz or 120hz made Sunshine adjust the capture rate to 59.999 fps which did reduce the stutter even while frame limiting. I'd prefer to use the dummy hdmi plug though which only supports 60/59.951hz at my preferred resolution.I'm not quite sure where the actual issue lies but my gut feeling is telling me that it's something related to the adjusted capture rate and the mismatch between the host and client frame rate.
This does read a bit like my investigations on the Linux side of the codebase. (It does not modify the capture rate, but there was still a mismatch due to other reasons, #2286). I achieved the smoothest stream by forcing everything to a precise 60Hz. (#2333)
While investigating this, I also noticed that a) on Windows the capture rate is modified. This may be beneficial for capturing (depending on vsync?), but it could be problematic on the receiving end. b) Moonlight-qt doesn't seem to be able to request non-integral framerates. That's not an issue for my TV (60.00Hz) but for some other devices it could be beneficial to be able to pass e.g. 59.94. Of course if game content is rendered at a different rate altogether this point is moot. And it's just a question on which end some kind of pacing is done (sunshine vs moonlight) in order to avoid multi-second stutter periods.
I can definitely imagine noticeable stutter issues if you're rendering your game at 60fps (no-vsync), which is then captured at 59.951, only to be played back at 60fps again...
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
This issue was closed because it has been stalled for 10 days with no activity.