Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vsync causing network judder #1448

Open
Slashic opened this issue Oct 22, 2024 · 2 comments
Open

Vsync causing network judder #1448

Slashic opened this issue Oct 22, 2024 · 2 comments

Comments

@Slashic
Copy link

Slashic commented Oct 22, 2024

Describe the bug
Only when vsync is enabled there is 0.40 to 0.90% frame dropped attributed to network jitter when the framerate of the game on the host can't cap the requested framerate and starts to engage adaptive sync on the client.
No jitter occurs if the framerate is stable and stays capped at the requested framerate in moonlight.
An occasional stutter/judder is visible but may be caused by the game itself or the host GPU being bottlenecked, I believe this is purely an error on the statistics display.

Does not happen at all with vsync off: tearing appears and an occasional stutter is still happening.

This seems similar to what is described in: #1323

Steps to reproduce
Launch a game through steam

Screenshots
N/A

Affected games
Metaphor Re:Fantazio, Ys 9, Vision of Mana...

Other Moonlight clients
Can't test that sorry

Moonlight settings (please complete the following information)
Use any of the codecs: H264/HEVC/AV1 (HDR enabled, 4:2:0)
Fullscreen or Windowed Fullscreen
Vsync ON
Any bitrate
4k 120fps or 60fps
Hardware AMD encoder & decoder (host & client)

Does the problem still occur after reverting settings back to default?
Yes (with vsync ON)

Client PC details

  • OS: Windows 10 22H2
  • Moonlight Version: v6.1.0
  • GPU: Radeon 6600

Server PC details

  • OS: Windows 10 22H2
  • Sunshine v2024.1020.30518
  • GPU: AMD Radeon RX 7900 XTX
  • GPU driver: 24.10.1

Additional context
This is on a 1Gbe Ethernet network

@cgutman
Copy link
Member

cgutman commented Nov 3, 2024

This is by design. The encoding rate from the host is not (and cannot be) perfectly synchronized with the rate of the rendering on the client PC. If the host is producing slightly more frames than the client can display, the pacing logic has to drop one every so often to avoid video latency accumulating with V-Sync on.

With V-Sync off, the display pipeline just discards the frame (or displays a portion of it - tearing), so the pacing logic doesn't need to drop frames itself.

@Slashic
Copy link
Author

Slashic commented Nov 4, 2024

Thanks for your reply, this is what i suspected too and indeed that seems logical. I was just a bit confused seeing this mechanism attributed to the network itself and not to the display sync or renderer, this could lead to false diagnostics if unaware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants