Repository navigation
Conversation
|
Add a host-side cap on the streamed video resolution. Client requests exceeding the cap are downscaled preserving aspect ratio, with even dimensions. The cap is applied both to the RTSP viewport (encode size) and to the launch session (so display device configuration switches the host display to the actual streamed size rather than the uncapped request). (cherry picked from commit 8868e21)
The option was registered in the config options map but had no input markup in the tab component, so it never appeared in the web UI. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KPZiLfh6KcTYcUtnydjZfC (cherry picked from commit bea1841)
(cherry picked from commit 2b40aa9)
(cherry picked from commit 07524f4)
07524f4 to
4ab6403
Compare
|
Rebased onto current master and added tests (config parsing and the capping math). @ReenigneArcher is there any chance for this to be accepted? The case for it is that when a stream has to be scaled up, it's better for the client to do so. Without a host-side cap, a client asking for a resolution higher than the host can produce results in wasted CPU cycles and bandwidth. With the cap, the host encodes at a resolution it can actually produce, the stream carries fewer pixels at the same bitrate, and the client's display pipeline scales it up, which it does well and for free. I'll close it you say no, but I think it's a neat way to minmax performance. |
ReenigneArcher
left a comment
ReenigneArcher
left a comment
There was a problem hiding this comment.
Reviewed 4ab64033cefdc5b9e81728def02a97640a9fddca against its target and current master (657f9b68bf0b2d34adf585b620775d19bb40d8a4). The latest target still has no stream-resolution cap, so the feature remains useful. Requesting changes for the required documentation on both new tests; the other inline comment identifies a small parser/capping boundary defect.
Validation passed: MSYS2 UCRT64 configuration and test_sunshine build with tray support disabled; all 30 tests selected by ConfigPersistenceTest.*:ConfigCapStreamResolution/*:ConfigConsistencyTest.*; all 21 web configuration tests; the production web build; clang-format checks on all changed C++ files; and git diff --check. A separate C++ harness using the unchanged parser and cap function bodies reproduced the one-pixel-cap defect.
Verification limits: no Moonlight streaming session or macOS hardware test was run. CI, common lint, and CodeQL await maintainer approval. The current Sonar gate is red, but its two reported findings reference the absent legacy src_assets/common/assets/web/config.html, rather than a file changed at this head.
Merge status: GitHub reports mergeable, and a local merge against current master completed without conflicts.
Review completed by Codex | Model: gpt-6.1-sol | Thinking: xhigh
|
Both reviews make sense. Done. |
|
Description
New config option (max_stream_resolution = 2560x1440): client resolution requests exceeding the cap are downscaled preserving aspect ratio (even-aligned). Applied both to the RTSP viewport (encode size) and the launch session, so display-device configuration switches the host display to the actual streamed size.
Encoder latency scales with pixel count. Moonlight's resolution setting is global across hosts, so a single slow-encoder host forces a fleet-wide compromise; this makes the tradeoff per-host instead. Measured example: a host whose 4K HEVC encode adds ~120ms of processing latency drops to ~35ms capped at 1440p, with the client settings untouched.
Includes web UI (Audio/Video -> "Maximum Stream Resolution"), docs, and locale entries; config consistency tests pass.
Screenshot
Issues Fixed or Closed
Roadmap Issues
Type of Change
Checklist
AI Usage
See our AI usage policy.