MOONLIGHT CLIENT OPTIMIZATIONS
A streaming client adapted for Noland's managed remote path
Noland embeds its Moonlight-compatible client and controls the native decode, presentation, telemetry, and reconnect lifecycle instead of sending video frames through the web interface.
QUICK ANSWER
What you need to know
Noland keeps the performance-critical stream in native code and adds bounded client-side controls around queueing, pacing, telemetry, remote packet sizing, and one-attempt recovery. Conservative defaults preserve known behavior until an optimization is explicitly enabled or validated for the platform.
NATIVE PIPELINE
Keep frames out of Tauri and React
The embedded client connects to Sunshine using the Moonlight protocol while native platform code owns decoding and presentation. Tauri coordinates the session and exposes aggregate state, but compressed or decoded video frames do not travel through JSON, the webview, or React.
This architecture lets each platform use its available media stack: Media Foundation and DXGI paths on Windows, GStreamer on Linux, and AVSampleBufferDisplayLayer on macOS. Platform capabilities differ, so Noland does not pretend that every optimization can be implemented safely on every backend.
- Native decode and renderer ownership
- Fixed-size control and telemetry rings
- No per-frame JSON allocation in the hot path
- Platform-specific behavior with documented limits
LATENCY CONTROLS
Bound buffering and make pacing behavior explicit
Optional frame-reserve modes are limited to zero through three decoded frames. Windows retains fixed IMFSample references, while Linux uses a bounded downstream-leaky GStreamer queue. Teardown and reconnect flush these queues so stale frames from an old generation cannot leak into a replacement session.
Windows also exposes explicit off, automatic, software, and supported hardware-multiple pacing modes. Adaptive late-frame dropping is gated by evidence such as severe lateness, a newer decoded frame, back pressure, cooldown, and smoothing compatibility; it is not enabled on backends that cannot prove a safe drop point.
- Zero-to-three-frame optional decoded reserve
- Oldest-frame overflow policy in bounded queues
- Explicit pacing modes instead of hidden timing behavior
- Conservative platform gates for adaptive frame dropping
REMOTE PATH
Treat a managed internet path differently from a local LAN
Noland's default managed remote configuration retains Moonlight's WAN behavior and uses a conservative 1024-byte packet size. An optional adaptive controller can choose from a fixed safe ladder using route classification, interface or tunnel MTU hints, aggregate RTP/FEC counters, and RTT variance.
This is not active PMTU discovery and does not send probe packets. Packet size is selected before stream startup and changes only through a controlled reconnect after repeated strong evidence, never by mutating the running protocol in place.
- Remote-safe default packet size
- Fixed candidate ladder from 960 to 1392 bytes
- No raw-socket, ICMP, DF-bit, or payload probing
- Controlled reconnect rather than in-place protocol mutation
RECOVERY AND DIAGNOSTICS
Recover once, then expose enough evidence to debug the path
An unexpected non-zero termination can trigger one immediate, generation-guarded reconnect. A user stop, graceful host termination, replacement stream, or application shutdown clears reconnect intent. This avoids recursive or unbounded retry loops that can fight the user or hide a persistent failure.
Aggregate diagnostics can report stream and display rates, queue depth, decode and render dwell, back pressure, local drop reasons, RTP/FEC deltas, reconnect totals, path classification, MTU hint, and selected packet size. These are measurements and controls—not a guarantee of a particular FPS or end-to-end latency.
FAQ
Questions about moonlight client optimizations
01Does Noland send video through React or the Tauri webview?
No. Native code owns the Moonlight connection, decoding, and presentation. The web interface receives control state and aggregate diagnostics rather than video frames.
02Are all latency optimizations enabled by default?
No. Safety-sensitive features such as adaptive late-frame dropping, adaptive packet sizing, decoder back-pressure policy, pacing, and smoothing reserves use conservative defaults and platform-specific gates.
03Does adaptive packet sizing discover the real path MTU?
No. It uses route classification, operating-system MTU hints, cached choices, and aggregate stream evidence. It does not perform active PMTU probes or change packet size during a running connection.
04Will the client reconnect forever after a failure?
No. Automatic recovery is bounded to one immediate attempt per eligible failure episode and is suppressed for explicit stops, graceful termination, replacement streams, and shutdown.
