Foundation Sunshine: a Windows-only Sunshine fork with HLG, HDR Vivid and a virtual display driver

The gap Foundation Sunshine is trying to close

Upstream Sunshine already streams a Windows desktop to Moonlight clients. What it does not do, according to this fork's README, is treat HDR as a first-class path. The README states that conventional streaming schemes support only HDR10 with PQ absolute luminance mapping, and that when the client device cannot hit the required brightness or its parameters do not line up, shadow detail is lost and highlights clip. Foundation Sunshine's answer is a second transfer function alongside PQ: HLG, described in the README as ITU-R BT.2100 Hybrid Log-Gamma, which maps luminance relatively so the display performs its own tone mapping against its own peak brightness. The README also notes HLG's backward compatibility, since an SDR display can decode the signal as BT.709 without a separate tone-mapping step. That is the core pitch. The secondary pitch is virtual displays: the fork integrates the ZakoVDD driver so a headless or multi-session host can present a synthetic monitor with custom resolution, refresh rate and 10-bit HDR depth, created and torn down as streams start and stop. If you stream from a machine that has no monitor attached, or you want each client to get its own display session keyed by GUID, this is the part that changes your setup rather than your picture quality.

Per-frame luminance analysis and where the metadata goes

The mechanism the README describes is a GPU-side analysis pass. A compute shader runs a two-stage reduction over each captured frame to compute MaxCLL (frame maximum content light level) and MaxFALL (frame average light level). Two filters sit on top of the raw statistics. Outliers are removed by percentile truncation, described as P95/P99, so a specular highlight cannot drag the global reference up and dim the rest of the frame. Then an exponential moving average smooths the values across frames, which the README says prevents brightness flicker when the scene cuts. The resulting numbers are injected as SEI or OBU metadata into the HEVC or AV1 bitstream. Static HDR10 metadata (Mastering Display Info plus Content Light Level) is passed through in full, and the README says NVENC, AMF and QSV outputs carry it conforming to CTA-861. Dynamic metadata is a narrower story: the README places HDR10+ (ST 2094-40) and HDR Vivid (CUVA T/UWA 005.3, carried in an ITU-T T.35 registered block) inside the NVENC pipeline specifically. HDR Vivid is given absolute tone mapping in PQ mode and scene-referred relative mapping in HLG mode. If you are on AMD or Intel, read the README carefully before assuming the dynamic metadata path applies to you.

Virtual displays, Zako Direct and the Windows 10 22H2 floor

The virtual display section carries an explicit requirement: Windows 10 22H2 or newer. The integration talks to ZakoVDD over IOCTL, and the README lists five screen composition modes (virtual only, physical only, mixed, mirrored, extended) plus per-client GUID session binding so several clients can switch without rebuilding the display. Configuration changes are said to apply without a reboot. The interesting detail is Zako Direct, described as borrowing the VDD shared frame texture and returning it after conversion, which removes one GPU copy from the VDD capture path. Zero-copy claims are easy to make and hard to verify without a frame-time trace, and the README offers no numbers here, so treat the copy reduction as a design statement rather than a measured result. The 22H2 floor is a real constraint. Older Windows 10 builds, Windows Server variants and any Linux host are outside the stated support surface, and the README's system requirements table lists Windows 10 22H2+ for both the minimum and the 4K-recommended column.

Encoder controls that differ per vendor

The NVENC path is documented around SDK 13.0, with look-ahead and finer rate control, native Mastering Display and Content Light Level writing from SDK 12.2 onward, and full SPS bitstream restriction fields for H.264 and HEVC. The AMF path is where the fork exposes the most knobs: QVBR, HQVBR and HQCBR rate control with a quality-level control in the UI, explicit AMF Low Latency, input queue size and AV1 latency mode settings, and switches for AMF Multi-HW Instance and Smart Access Video so the driver can split encoding work on supported platforms. The README frames the AMF latency controls as a trade between very low latency and driver stability, which is an honest way to put it: pushing the queue down is the kind of change that shows up as a driver reset rather than a smooth frame. Elsewhere the README mentions a persistent encoder probe cache that takes subsequent connections from 26 seconds to under 100 milliseconds, a 260x figure that comes from the project's own documentation and has not been reproduced here. Adaptive downscaling offers bilinear, bicubic and a high-quality tier for 4K host to 1080p client scenarios. A Vulkan encoder path is labelled experimental.

Audio, folder sharing and the control panel

Audio gets four listed changes: 7.1.4 channel mapping at 12 channels for immersive layouts, Opus DRED as a neural packet-loss recovery mechanism with a 100 ms redundancy window, a continuous audio stream that fills silence rather than reinitialising the device, and automatic bit-depth matching for virtual speakers at 16-bit and 24-bit. The continuous stream idea is the one with a visible failure mode attached to it in normal setups: audio device reinitialisation between quiet periods is a common source of clicks and dropouts, and keeping the stream alive is a plausible fix. Folder sharing maps Windows host directories, adds an Explorer right-click entry, defaults to read-only, and gates access on paired devices. That read-only default is the right call and worth keeping. The control panel is a Tauri 2, Vue 3 and Vite application with dark mode, QR pairing, live monitoring and WebUI rendering work. Input handling adds per-client configuration, precision touchpad support and a virtual mouse driver called vmouse.

Getting it running and what the docs assume

The README's build instructions live in docs/building.md, configuration in docs/configuration.md and WebUI development in docs/WEBUI_DEVELOPMENT.md, with the primary user documentation hosted on a Tencent Docs page rather than in the repository. That last point matters more than it looks. The main usage guide is a link to docs.qq.com, the community channel is a QQ group, and the repository ships READMEs in English, Simplified Chinese, French, German and Japanese. If you do not read Chinese, your practical documentation is the English README plus the upstream LizardByte docs, and the fork-specific behaviour of the control panel and the ZakoVDD integration is described in more depth in the Tencent document than anywhere in the tree. The release tags reinforce this: all three September 2026 releases carry the suffix 杂鱼, which is not a version scheme you can parse for stability. Clone the repository, read docs/building.md for the build path, and check docs/configuration.md for the config keys your deployment needs before you touch a production host.

Where the fork stops being the right answer

The clearest limitation is platform. This is a Windows fork. A Linux host running upstream Sunshine with VAAPI or NVENC already covers a large share of self-hosted streaming, and none of the ZakoVDD, folder-sharing or Tauri panel work applies there. The second limitation is client coupling. The README recommends specific modified Moonlight builds (moonlight-qt from the same author, two Android forks, VoidLink on iOS, a HarmonyOS build on Huawei AppGallery) and frames the pairing as the intended experience. Stock Moonlight will still connect, since the protocol is Moonlight's, but the HDR Vivid and dynamic metadata paths are designed against clients that understand them, and the fork does not document what a stock client does when it receives metadata it cannot use. The third is the upgrade treadmill. Three releases in eight days, all tagged with the same non-semantic suffix, on a GPL-3.0 codebase that tracks upstream Sunshine. If you fork or patch it, you are rebasing against a moving target. The honest alternative for most people is upstream LizardByte/Sunshine: it is the base this project builds on, it supports Linux, macOS and Windows hosts, it has its own documentation site, and it does not depend on a third-party virtual display driver. The difference in approach is that upstream treats HDR as one output format among several, while Foundation Sunshine treats the HDR chain, from capture gamma through per-frame analysis to SEI injection, as the product.

Licence and the cost of keeping up

Foundation Sunshine is GPL-3.0, the same licence family as the upstream project it forks, which is what you would expect for a derivative of Sunshine. If you redistribute a build, or ship a product that links against it, the copyleft terms apply to the combined work; that is a question for your own legal review, not something to settle from a README. The upgrade cost is concrete rather than theoretical. Because the fork tracks upstream Sunshine and adds a virtual display driver, a Tauri panel and encoder-level changes, an upstream merge can touch the capture pipeline, the encoder wrappers and the WebUI at once. The README's own contribution links point at docs/building.md, docs/configuration.md and docs/WEBUI_DEVELOPMENT.md, which suggests the maintainers expect contributors to rebuild all three surfaces. Budget for a rebuild and a re-test of your encoder path on every upstream sync, and keep the working tag recorded, because the version strings will not tell you which build you are on.

Editorial conclusion

Adopt Foundation Sunshine if your host is Windows 10 22H2 or newer, your client is one of the modified Moonlight builds the README lists, and you specifically need HLG output, HDR Vivid metadata or a virtual display that is created and destroyed with the stream. Do not adopt it if you stream from Linux, if your client is stock Moonlight and you have no interest in the paired forks, or if you need a support channel you can search in English. Before installing, verify three things: which encoder path your GPU actually takes (the HDR10+ and HDR Vivid injection is documented for NVENC only), whether your display chain preserves 10-bit colour end to end, and which of the three September 2026 tags you are pinning, because all three carry the same 杂鱼 suffix and none of them is described as stable in the material.

Official sources

1. AlkaidLab/foundation-sunshine on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases