音视频【免费下载链接】foundation-sunshineSunshine fork: an enhanced sunshine, a self-hosted game streaming host for Moonlight with HDR10/HDR Vivid, virtual displays, advanced audio, optimized encoders, and a modern control panel.项目地址https://gitcode.com/gh_mirrors/sunshine5/foundation-sunshine点击查看免费下载本文聚焦 Foundation SunshineSunshine fork在 Windows 平台上的原生 HDR 捕获输入与 NVIDIA DLSS NRNeural Radiance神经渲染增强的集成方案核心是hdr_filter如何在不把 SDR 变 HDR、不丢失 scRGB 宽色域与高光的前提下让一个只认 SDR的神经增强模型安全处理线性 FP16 的 HDR 桌面。读完本文你将掌握该三段式 GPU 代理管线的实现原理、nr-defaults.json与运行时校验等配置细节以及从单元测试、硬件 smoke 到生产路径首帧编码的完整验证矩阵与尚存的工程边界。一、核心设计原则信号保真而非信号转换DLSS NR 的 HDR 集成遵循一条最根本的原则保留会话的原始信号语义。原文档HDR.md对此给出了明确的三点约束SDR 保持 SDRSDR 捕获继续走 SDR 路径模型不承担任何把 SDR 升级为 HDR 的职责原生 HDR 捕获保持线性 scRGB FP16一直保持该格式直到进入既有的 PQ/HLG 转换和编码器阶段中间不允许出现先压成 SDR 再转 HDR的信息损失单 pre-encode 槽位下 RTX HDR 优先如果 RTX HDR 占用了唯一的 pre-encode 处理槽位则由 RTX HDR 接管该会话此时 NR 对该会话保持非活跃状态。换言之这套设计是HDR 保真地集成一个 SDR 模型而不是宣称模型本身理解 HDR。文档特别强调如果模型输出与代理输入完全一致则残差精确为零增强则可能有意改变局部亮度、色彩与纹理——这些都属于模型行为而非信号转换。二、为什么不能把捕获的 scRGB 直接喂给模型一个关键的事实边界来自实测的 NVIDIA 运行时文档记录的 310.8.0.0 运行时配合驱动 616.92 测试该运行时虽然接受 FP16 资源但会把值钳制到 0..1 范围包括强度为零的情况因此直接把捕获的 scRGB 传入模型会丢失带符号的宽色域值与高光信息文档给出明确警告资源格式支持并不能作为原生 HDR 模型支持的证据。从仓库实现看这一判断还体现在运行时的信任链上。adapter_loader.cpp 在加载foundation_dlssnr_adapter.dll与nvngx_dlssnr.dll时会计算 SHA-256 摘要适配器摘要必须匹配编译期内置的SUNSHINE_DLSSNR_ADAPTER_SHA256否则报adapter_untrusted运行时摘要则在持久化配置的 pin 值存在时强制比对不匹配即报runtime_untrusted未 pin 时仅在加载时计算并记录日志。这解释了后面验证矩阵中大量围绕runtime_untrusted与degraded状态的测试设计。三、hdr_filter三段式 GPU 代理管线hdr_filter.*是整套方案的核心实现hdr_filter.cpp、hdr_filter.h。它的策略是保留原始 FP16 纹理向模型呈现一个 SDR 代理proxy。管线分为三个 GPU pass全部内嵌在同一份 HLSL 着色器中3.1 prepare pass构造 BGRA8 SDR 代理以203-nit 白点归一化。着色器注释给出了换算依据scRGB 中1.0对应 80 nits因此203 / 80 2.5375成为proxy_scale的基数proxy_scale(c) 2.5375 max(0, max(c.r, max(c.g, c.b)))在归一化的同时把超出白点的高光压缩进 BGRA8 代理的动态范围代理输出为saturate(encode(max(c, 0) / proxy_scale(c)))的 BGRA8 纹理当模型分辨率低于源分辨率scale_percent 100时prepare 通过四个双线性采样点覆盖低分辨率像素足迹适用于 50%–100% 的缩放区间特殊捷径若输入是 SDR 且scale_percent 100则直接透传原始输入给模型跳过代理开销见process()中if (!hdr scale_percent_ 100) return model_-process(input);。3.2 模型推理SDR 代理上的 NR可选光流代理帧被包装为filter_detail::make_sdr_result结果sdr_rec709/unorm8并把reference_white_nits置 0 后送入模型模型在同一份代理上执行 DLSS NRnr_motion_quality 0时还会启用光流optical flow路径真正执行推理的是 dlssnr_filter.cpp 中的external_neural_enhancement_filter_t它通过dlssnr_adapter_loader_t调用适配器的create/process/destroy并通过全局互斥量串行化适配器调用。3.3 resolve pass残差解码并叠加回原始 scRGB同时采样精确量化后的代理before与模型增强结果after计算delta decode(after) - decode(before)——由于两侧采样的是同一份量化代理模型恒等时残差精确为零将残差钳制到 ±0.25再乘上proxy_scale(source.rgb)缩放回 scRGB 量纲叠加到原始像素结果被钳制在-65504..65504FP16 可表示范围并在非有限值时回退到原始像素原始 alpha 与帧元数据完整保留return float4(all(isfinite(result)) ? result : source.rgb, source.a);输出纹理格式为R16G16B16A16_FLOAT文档强调不会把任何中间 SDR 帧送入 HDR 编码器场景元数据分析scene metadata analysis会通过既有转换路径读取 resolve 后的帧。该滤波器的入口是make_hdr_compatible_filter(device, context, model, scale_percent)它在设备/上下文/模型为空或缩放比例非法valid_nr_scale要求 20–100 且为 5 的倍数时返回空指针dlssnr_filter.cpp的make_filter在加载并校验适配器后把external_neural_enhancement_filter_t包进hdr_filter_t返回。四、与既有管线契约的衔接frame_contract 与 pre_encode_filterhdr_filter是 vendor-neutral 的 pre-encode 滤波契约pre_encode_filter.h下的一个实现上游帧语义由 frame_contract.h 描述frame_domain_eunknown / sdr_rec709 / linear_scrgb / pq_bt2020 / hlg_bt2020pixel_encoding_class_eautomatic / unorm8 / float16捕获帧描述captured_frame_desc_t记录 domain、encoding、reference_white_nits、adapter LUID、是否借用borrowed与源代次。pre_encode_filter_helpers.h 中的validate_neural_input给出了原生 HDR 输入的严格契约这是hdr_filter决定走 HDR 代理路径的判据domain 必须是linear_scrgb编码必须是float16R16G16B16A16_FLOAT格式reference_white_nits必须精确等于80.0f不得是借用borrowed false的资源。对应的捕获侧映射在 frame_contract.cppselect_wgc_capture_format在契约要求float16或automatic linear_scrgb时选择R16G16B16A16_FLOAT否则回退B8G8R8A8_UNORMdescribe_dxgi_captured_frame依据格式把线性 gamma 的 FP16 帧描述为linear_scrgb把 8 位 UNORM 帧描述为sdr_rec709。五、配置参数与 nr-defaults.jsonNR 的流默认参数由 nr_defaults.cpp 管理持久化为nr-defaults.json位于应用数据目录schema version 为 1{ version: 1, enabled: true, scale_percent: 100, intensity: 1.0, style: 0, skin_structure_strength: 0.0, auto_mask: false, ui_correction: false, motion_quality: 0 }各参数的合法范围valid()校验非法则整体拒绝加载/保存参数含义合法范围/取值scale_percent模型处理分辨率相对捕获分辨率的缩放20–100且必须为 5 的倍数valid_nr_scaleintensity增强强度0.0–1.0--zero场景即设为 0style风格档位0–4skin_structure_strength皮肤结构强度0.0–1.0auto_mask自动遮罩布尔ui_correctionUI 修正布尔motion_quality光流质量档0 零运动禁用光流1–3 光流质量档这些字段最终映射到 frame_contract.h 的pre_encode_filter_config_tnr_scale_percent / nr_intensity / nr_local_tone_strength / nr_local_structure_strength / nr_skin_structure_strength / nr_style / nr_motion_quality / nr_auto_mask / nr_ui_correction并在 dlssnr_filter.cpp 中传入foundation_dlssnr_config_tmotion_mode由nr_motion_quality 0决定是否为FOUNDATION_DLSSNR_MOTION_OPTICAL_FLOW。运行时状态会经 api.cpp 暴露为nr_requested_intensity / nr_intensity / nr_requested_motion_quality / nr_motion_quality / nr_scale_percent / nr_settings_failure_reason等观测字段。后端身份与组件文件名定义在 config.hNR 后端 id 为alkaidlab.nvidia_dlssnr适配器为foundation_dlssnr_adapter.dll运行时为nvngx_dlssnr.dllruntime_pins支持按后端 pin 运行时摘要未 pin 时接受未 pin 的运行时加载时计算并记录日志。六、验证矩阵从单元测试到硬件 smoke原文档给出了完整的验证分层仓库中对应的测试目标可见 tests/CMakeLists.txt。6.1 单元测试pre_encode_filter_unit_testsWARP 软件光栅化覆盖带符号值、次正规数subnormal、1000/4000-nit 高光、alpha、元数据、奇数尺寸、缩放resize、调用者设备上下文状态恢复SwapDeviceContextStateClearState的 state guard以及后端不可用时的 HDR 透传frame_contract_unit_tests验证 NR 保留原生 PQ/HLG 输出策略、要求私有 FP16 捕获交接private handoff且 NR不会成为合成 HDR 源。6.2 硬件 smokedlssnr_pipeline_smoke命令行工具位于 dlssnr_pipeline_smoke.cpp用法为dlssnr_pipeline_smoke absolute adapter path runtime SHA-256 [--hdr] [--zero] [--flow] [--4k] [--shared]--hdr --zerointensity置 0走生产级已验证加载器执行真实 NR要求 HDR 输出与输入像素级完全一致验证恒等模型零残差性质--hdr --flowmotion_quality置 2 启用 NR 光流要求输出发生变化且保留 HDR 高光在重复的 720p/1080p 会话上验证--4k增加 1080p/2160p 缩放场景实测真实运行时在 3840x2160 下重复通过原生 HDR 处理--shared构造生产者 D3D11 设备、在消费者设备上打开 keyed-mutex 共享纹理并在释放捕获所有权前完成私有拷贝测试在首帧处理后立即回读而非只检查排空批次。这些硬件 smoke 是显式 opt-in 检查不是常规 CI 测试且不证明 Moonlight 串流、游戏画质或 30 分钟会话的稳定性。6.3 聚合硬件测试DlssNrHardwareDlssNrHardware.NativeHdrFirstEncodedPacket覆盖 NR → 合成 P010 写入 → 真实 HEVC NVENC 提交的整条链路要求无需显式调用者 Flush、无 CPU 回读、无第二个 NR 帧即产出首个编码包。运行方式SUNSHINE_TEST_DLSSNR_ADAPTER绝对适配器路径 SUNSHINE_TEST_DLSSNR_SHA256运行时小写 SHA-256两者缺一则跳过。本地测试产出 1 个初始 IDR 加 2 个后续包含初始化约 1.2 秒。注意它使用最小化诊断 P010 写入而非生产色彩转换桌面捕获、真实转换路径与网络投递均不在其范围内。后续补充的生产路径测试族ProductionConversionFirstEncodedPacket经生产共享纹理交接、HDR 转换/降采样与 NVENC 代码使用合成像素验证DesktopCaptureFirstEncodedPacket额外要求SUNSHINE_TEST_DLSSNR_CAPTURE1捕获已是 HDR 的桌面、编码首帧再要求真实帧进入 NR 活跃状态并产出另一个包ProductionHlgConversionFirstEncodedPacket同样的占位帧过渡与真实 NR/NVENC 检查但输出 HLG——PQ 与 HLG 两种变体本地均通过ProductionUnavailableNrStillEncodesHdr拒绝运行时 pin不改动已安装文件验证生产编码器初始化、启动占位帧与 3 个后续 HDR 包以及 NRdegraded状态与runtime_untrusted原因工厂在缺失/被拒后端时已包一层 identity fallback主处理失败时同一 failover 包装会切换到该 fallbackProductionHdrCaptureToSdrFirstEncodedPacket与ProductionUnavailableNrStillEncodesHdrCaptureToSdr复现HDR 捕获 → SDR 输出的转换失败并在修复后验证占位帧加 3 个真实 NR/NV12/NVENC 包。七、端到端跟进三个 SDR-only 门槛的消除2026-09-20真实原生 HDR 测试暴露了三个残留的仅限 SDR门槛均已修复HTTP launch attachment启动附加流程中的信号处理opened-display filter check打开显示器时的滤波检查private texture handoff私有纹理交接。修复后 NR 能穿越全部三处而SDR→HDR 滤波器仍拒绝原生 HDR 源。交接逻辑使用解析后的捕获契约resolved capture contract仅排除了源已分离这一条要求。另一个关键修复来自配对包复测HDR 桌面以 scRGB FP16 捕获而客户端协商的是 SDR HEVC时原先 NR 的捕获契约从输出 transfer 推断导致在真实帧到达后端前就被拒绝。修复后NR 从每个已知的SDR UNORM8 或线性 scRGB FP16 帧中解析自身输入域不改变客户端的输出 transfer也不改变私有交接要求未知域仍然被拒绝SDR→HDR 滤波器保留其严格输入契约。八、占位帧问题与桌面捕获过渡生产路径跟进复现了一个被拒绝的首帧Desktop Duplication 在获知捕获格式前可能返回一个非空白的、仅含光标的占位帧dummy其未知语义无法满足真实 NR 契约。修复方式是转换阶段对这类占位帧绕过增强保留正常启动视频路径直到出现真实捕获帧。DlssNrHardware.ProductionConversionFirstEncodedPacket与DesktopCaptureFirstEncodedPacket即针对这一过渡而设计。九、实测数据loopback Moonlight 与吞吐量范围9.1 Moonlight 桌面回环复测占位帧修复后使用官方 Moonlight 6.1、1920x1080 捕获/输出、60 fps 请求、禁用运动估计首次 HEVC 帧成功接收解码主机同时报告 NR 活跃、PQ 输出与场景元数据活跃。会话在 Moonlight 进程时钟上运行29:13首帧解码在 00:06用户以退出快捷键主动断开接收/解码/渲染59.98 fps网络与抖动丢包0.00%主机处理延迟 6.9/920.9/7.3 msmin/max/mean峰值成因未隔离属整会话主机测量而非 NR 模型增量成本56 个主机采样覆盖 27.5 分钟 NR/PQ/场景元数据活跃期私有内存稳定在1369.20–1369.36 MiB。文档明确这是桌面回环测试不是 4K 串流性能或游戏画质证据该次是主动结束的运行不是完整的 30 分钟测试该门槛与真实游戏评估仍是独立验收项。9.2 配对包与吞吐量范围较新的 Core 91080d54 / Panel 074ce83 配对包通过溯源与文件校验。一次显式 HEVC Main10/PQ 桌面会话使用 4K scRGB 捕获 1080p60 输出客户端在 10:20 主动结束报告 60 fps、零网络/抖动丢包20 个主机采样覆盖 570.39 秒NR、PQ、分析与元数据全部活跃——属于短时桌面证据30 分钟稳定性与真实游戏运动质量验收被明确取消。在隔离的 RTX 5080 / 驱动 616.92 / 运行时 310.8.0.0 环境下4K BGRA8 NR 在 1200 帧上测得68.78 fps14.539 ms/帧10 帧预热后 GPU Evaluate 均值 13.869 ms两个与三个独立进程分别约 68.4 与 68.2 fps聚合吞吐未提升。该测量输入已预上传、强度为 1、光流关闭、仅回读最终输出排除游戏渲染、HDR 代理 pass、捕获与编码此前历史 ~44 ms 的 GPU 结果未被复现成因仍未隔离两者都不是固定的分辨率/FPS 门槛。十、审查边界与降级路径组件引用生命周期启动阶段同时保留两个已启用组件的引用直到 RTSP 解析出最终线上格式PQ 优先选择 RTX HDRHLG/SDR 仍可选择 NRRTSP 随后释放未使用的引用hdr_mode 上报实际的hdr_mode跟随编码器色彩空间而非请求的捕获策略SDR 源 HDR 请求生产回归要求 SDR 输出状态与已投递的 NVENC 包该回退保留10-bit Rec.709编码——位深本身不等于 HDR未知 FP16 色彩语义仍被拒绝仅绕过 NR 不足以建立正确的下游传递函数多实例同进程内两个 D3D11 设备与独立 NR 实例的短时交错处理、输出回读、对等销毁与重建测试通过调用如主机一样被串行化这不是并发 API 调用安全或多客户端串流验收也不据此推断单实例限制Panel 配套控制面板已检查 VC 运行时缺失时提供明确的提示与下载操作。十一、结论实验性状态与待验收门槛综上所述Foundation Sunshine 通过hdr_filter实现了信号保真的 SDR 模型 HDR 集成原始 scRGB FP16 全程保留模型只看到 203-nit 白点归一化、高光压缩的 BGRA8 代理残差以 ±0.25 钳制后缩放回叠alpha 与元数据无损任何中间 SDR 帧都不会进入 HDR 编码器。此前的首帧超时问题已解决。但依据原文档的明确边界该功能仍处于实验状态完整的 30 分钟稳定性测试与真实游戏画质/运动质量评估仍是后续独立验收门槛单次吞吐量测量不构成分辨率/FPS 承诺。对于希望深入验证的读者可直接阅读 HDR.md 原始文档结合 hdr_filter.cpp 的着色器实现、dlssnr_filter.cpp 的适配器加载链路以及 dlssnr_pipeline_smoke.cpp 的硬件测试入口进行复现。赞分享音视频【免费下载链接】foundation-sunshineSunshine fork: an enhanced sunshine, a self-hosted game streaming host for Moonlight with HDR10/HDR Vivid, virtual displays, advanced audio, optimized encoders, and a modern control panel.项目地址https://gitcode.com/gh_mirrors/sunshine5/foundation-sunshine点击查看免费下载相关推荐Foundation Sunshine 的 NVIDIA Optical FlowNVOF头文件集成与 DLSS NR 运动矢量管线解析Foundation Sunshine 的 NVIDIA Optical FlowNVOF头文件集成与 DLSS NR 运动矢量管线解析 本文聚焦 Foun音视频Foundation Sunshine 硬件光流验证指南DLSS NR 适配器的 NVOF 诊断与冒烟测试Foundation Sunshine 硬件光流验证指南DLSS NR 适配器的 NVOF 诊断与冒烟测试 导读 本文是 Foundation Sunshin音视频foundation-sunshine 原生侧载组件合同DLSS NR / RTX Video 增强组件的可信安装、版本与生命周期管理foundation sunshine 原生侧载组件合同DLSS NR / RTX Video 增强组件的可信安装、版本与生命周期管理 本文是 foundat音视频上一篇ngxtop高可用监控测试计划制定全面的测试方案下一篇Requests终极指南10个生产环境最佳实践部署技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考