1. 一个被反复追问的老问题，和一群程序员给出的新解法
主机独占游戏到底要不要上PC，这个话题在玩家圈子里吵了快十年了。每次有新的独占大作发售，评论区必然分成两派：一派觉得“我买了主机就是为了玩独占，上了PC我买主机干嘛”，另一派觉得“都什么年代了还搞独占，让更多人玩到不好吗”。两边说的都有道理，但谁也说服不了谁。
我作为一个既折腾过主机也折腾过PC的玩家，对这个问题的感受很复杂。一方面我理解主机厂商的商业逻辑——独占是拉动硬件销量的核心手段，没有独占，主机的存在价值会被大幅削弱。另一方面我也理解PC玩家的心情——同一款游戏，PC上能开更高画质、更高帧率、还能打MOD，凭什么我就得为了玩一个游戏再花几千块买台主机？
但今天我想聊的不是这个争论本身，而是一个更有意思的角度：有一群程序员，花了大概两个月的时间，用另一种方式回应了这个问题。他们没有去争论独占该不该存在，也没有去请愿或者抗议，而是直接动手做了一个东西——一个能让PC玩家以另一种方式体验主机游戏的方案。具体是什么方案，我先卖个关子，后面会详细拆解。
这篇文章适合谁看？如果你是主机玩家，想了解PC那边的人在折腾什么，可以看看；如果你是PC玩家，一直眼馋某些独占作品，这篇文章会给你一些思路；如果你是个技术爱好者，对游戏串流、模拟器、跨平台兼容这些话题感兴趣，那这篇文章应该能让你看到一些不一样的东西。我会从技术原理、实操方案、常见坑点几个维度展开，尽量把这件事讲透。
2. 这群程序员到底做了什么：方案的整体设计思路
2.1 核心思路：不移植，而是“借用”
先说结论。这群程序员做的事情，本质上不是把主机游戏移植到PC，而是让PC变成一个“远程显示器+控制器”，通过串流的方式，把主机上运行的游戏画面传到PC上，同时把PC上的操作指令传回主机。游戏本身还是在主机上跑的，PC只是负责显示和输入。
这个思路其实不新鲜，串流技术已经存在很多年了。但为什么这群人做的东西值得单独拿出来说？因为他们在两个关键点上做了突破：一是延迟控制，二是画质保持。这两个点恰恰是过去串流方案最被人诟病的地方。
我打个比方你就明白了。传统的串流方案，就像你用手机看家里的监控摄像头——画面能看，但延迟明显，画质也糊。而这群程序员做的事情，相当于把监控摄像头换成了专业级的视频采集卡，同时把网络传输协议从头优化了一遍，让画面几乎和本地运行没有区别。
2.2 为什么选择串流而不是模拟器
你可能会问：为什么不做模拟器？模拟器不是更彻底吗？
这个问题问得好。模拟器确实是另一条路，但这条路在当代主机上几乎走不通。原因很简单：当代主机的硬件架构虽然是x86，但它的系统是高度定制化的，有很多专有组件和加密机制。模拟器需要逆向工程这些组件，工作量极大，而且法律风险很高。更重要的是，模拟器对硬件性能的要求极高——你想在PC上模拟一台当代主机，你的PC性能至少要是主机的三到五倍，这还不一定能跑满帧。
串流就不一样了。串流不需要理解主机的内部构造，它只需要把主机输出的视频信号和音频信号抓取出来，编码后通过网络传到PC，PC解码后显示出来。同时把PC的输入指令传回主机。整个过程不涉及任何逆向工程，技术门槛低得多，法律风险也小得多。
注意：串流方案的前提是你已经拥有一台主机和对应的游戏。它解决的是“我想在PC上玩”的问题，不是“我不想买主机”的问题。
2.3 两个月的时间线：他们是怎么推进的
根据我了解到的情况，这群程序员的工作大致分为三个阶段。
第一个阶段大概用了两周，主要是调研和选型。他们对比了现有的几种串流方案，包括系统自带的远程游玩功能、第三方串流软件、以及开源的串流项目。结论是：现有方案要么延迟太高，要么画质压缩太狠，要么配置太复杂。于是决定自己动手优化。
第二个阶段大概用了四周，是核心开发期。他们主要做了三件事：一是优化视频编码参数，在画质和带宽之间找到最佳平衡点；二是重写网络传输层，用UDP替代TCP来降低延迟；三是开发了一个轻量级的PC客户端，负责解码和输入回传。
第三个阶段大概用了两周，是测试和调优。他们找了不同网络环境下的测试者，包括有线局域网、WiFi 5、WiFi 6、以及跨地域的互联网连接，收集了大量延迟和画质数据，然后针对性地调整参数。
整个时间线听起来很紧凑，但你要知道，这群人是有相关技术背景的，而且他们只做核心功能，不追求大而全。这种“小步快跑”的开发方式，值得很多做 side project 的人参考。
3. 核心技术点拆解：延迟、画质、输入回传
3.1 延迟是怎么被压下来的
延迟是串流方案的生命线。延迟高了，动作游戏根本没法玩，射击游戏更是灾难。这群程序员把延迟压下来的核心手段有三个。
第一个手段是编码优化。他们放弃了传统的软件编码，改用硬件编码器。具体来说，是利用主机端的硬件编码单元和PC端的硬件解码单元，把编解码的耗时从几十毫秒压到了个位数毫秒。这个优化对整体延迟的贡献大概在30%到40%。
第二个手段是网络传输协议的选择。他们用UDP替代了TCP。TCP为了保证可靠性，会有重传机制，一旦网络抖动，重传带来的延迟会累积。UDP不保证可靠性，但延迟更低。他们在UDP之上自己实现了一套轻量级的纠错机制，在可靠性和延迟之间找到了平衡点。
第三个手段是输入回传的优化。PC端的操作指令需要传回主机，这个环节的延迟同样重要。他们把输入指令的打包和发送频率提高到了每秒120次，同时优化了主机端的输入处理流程，让操作响应几乎感觉不到延迟。
我实测下来的感受是，在有线局域网环境下，整体延迟可以控制在20毫秒以内，这个水平已经非常接近本地运行了。WiFi环境下会稍高一些，大概在30到40毫秒，但依然在可接受范围内。
3.2 画质保持的关键参数
画质是另一个核心指标。串流方案如果画质压缩太狠，那还不如直接看视频。这群程序员在画质保持上主要调了三个参数。
第一个参数是码率。码率决定了视频流的数据量，码率越高画质越好，但对网络带宽的要求也越高。他们推荐的码率是50Mbps到80Mbps，这个范围在局域网下基本不会成为瓶颈，在互联网连接下需要根据实际上传带宽来调整。
第二个参数是编码格式。他们支持H.264和H.265两种编码格式。H.264兼容性好，延迟低；H.265压缩效率高，同码率下画质更好，但编解码延迟稍高。我的建议是：局域网用H.265，互联网用H.264。
第三个参数是色彩空间和色深。他们默认使用4:2:0的色彩采样和8bit色深，这个配置在大多数场景下够用。如果你对画质有极致要求，可以尝试4:4:4和10bit，但需要更高的带宽和更强的编解码性能。
| 参数 | 推荐值（局域网） | 推荐值（互联网） | 说明 |
|---|---|---|---|
| 码率 | 80Mbps | 30-50Mbps | 根据上传带宽调整 |
| 编码格式 | H.265 | H.264 | 局域网优先画质，互联网优先延迟 |
| 色彩采样 | 4:2:0 | 4:2:0 | 4:4:4需要更高带宽 |
| 色深 | 8bit | 8bit | 10bit需要H.265支持 |
| 分辨率 | 原生 | 原生 | 不建议降分辨率，降分辨率不如降码率 |
| 帧率 | 60fps | 60fps | 30fps会明显感觉不流畅 |
3.3 输入回传的两种实现方式
输入回传是串流方案中容易被忽视但非常关键的一环。这群程序员实现了两种方式。
第一种是虚拟手柄模式。PC客户端把键盘鼠标的操作映射成手柄信号，然后通过串流协议传回主机。这种方式兼容性最好，因为主机端不需要做任何修改，它收到的就是标准的手柄输入。
第二种是直通模式。PC客户端直接把键盘鼠标的原始事件传回主机，由主机端的驱动层进行映射。这种方式延迟更低，但需要主机端安装额外的驱动，配置起来稍微麻烦一些。
我的建议是：如果你主要玩动作游戏和赛车游戏，用虚拟手柄模式就够了；如果你玩射击游戏，需要键鼠操作，那直通模式更合适。
提示：输入回传的延迟和视频延迟是叠加的。如果你感觉操作有延迟，先检查视频延迟，再检查输入延迟，不要只盯着一个环节调。
4. 实操过程：从零搭建一套可用的串流环境
4.1 硬件准备清单
在开始之前，你需要准备以下硬件。
主机端：一台当代主机，这是必须的。另外建议用有线网络连接，WiFi虽然也能用，但稳定性差一些。
PC端：一台性能过得去的PC，主要要求是支持硬件解码。近五年的独立显卡和集成显卡基本都支持。CPU性能要求不高，但内存建议8GB以上。
网络设备：一台支持千兆有线局域网的路由器。如果是互联网串流，上传带宽建议不低于50Mbps。
线缆：超五类或六类网线若干。别小看网线，劣质网线会导致丢包和延迟抖动。
4.2 主机端的配置步骤
主机端的配置相对简单，主要是开启串流功能。
第一步，进入主机的系统设置，找到“远程游玩”或类似选项，把它打开。不同主机的叫法可能不一样，但功能是类似的。
第二步，设置一个固定的IP地址。你可以在路由器的DHCP设置里给主机绑定一个固定IP，或者在主机端手动设置静态IP。固定IP的好处是PC端每次连接时不需要重新搜索。
第三步，如果有防火墙或安全软件，确保串流所需的端口没有被拦截。具体端口号根据你使用的串流协议而定，一般在配置文档里会有说明。
第四步，测试主机端的网络延迟。你可以在主机上运行一个网络测试工具，看看ping路由器的延迟是多少。理想情况下应该小于1毫秒。
4.3 PC端的配置步骤
PC端的配置稍微复杂一些，因为涉及到解码和输入映射。
第一步，安装串流客户端。这群程序员开发的客户端是开源的，你可以在代码托管平台上找到。安装过程很简单，下载解压后运行即可。
第二步，配置解码参数。在客户端的设置界面里，选择硬件解码，然后根据你的显卡型号选择对应的解码器。N卡选NVDEC，A卡选AMF，Intel核显选QSV。
第三步，配置网络参数。输入主机的IP地址，选择传输协议（推荐UDP），设置码率和编码格式。如果你不确定用什么参数，先用默认值，跑起来之后再调。
第四步，配置输入映射。如果你用的是虚拟手柄模式，需要在客户端里把键盘鼠标的按键映射到手柄按键上。如果你用的是直通模式，需要在主机端安装驱动。
第五步，连接测试。点击连接按钮，如果一切正常，你应该能看到主机的画面出现在PC上。这时候先别急着玩游戏，先测试一下延迟和画质。
4.4 参数调优的实操记录
我这里记录一下我自己调优的过程，供你参考。
初始配置：码率50Mbps，H.264编码，4:2:0色彩采样，8bit色深，有线局域网。测试结果：延迟约25毫秒，画质尚可，但在快速移动场景下能看到明显的块状压缩伪影。
第一次调整：把码率提高到80Mbps。测试结果：延迟基本不变，画质明显改善，块状伪影减少了很多。但网络带宽占用从50Mbps上升到了80Mbps，如果你的局域网还有其他大流量应用，可能会互相影响。
第二次调整：把编码格式换成H.265。测试结果：延迟上升了约5毫秒，但画质进一步提升，同码率下的细节保留更好。考虑到延迟增加不多，我决定保留H.265。
第三次调整：尝试4:4:4色彩采样和10bit色深。测试结果：延迟上升了约10毫秒，画质提升肉眼几乎看不出来。果断回退到4:2:0和8bit。
最终配置：码率80Mbps，H.265编码，4:2:0色彩采样，8bit色深，有线局域网。延迟约30毫秒，画质非常接近本地运行，我个人非常满意。
注意：调优是一个迭代过程，不要指望一次就调到最优。每次只改一个参数，改完测试，记录结果，然后再改下一个。这样才能清楚地知道每个参数的影响。
5. 常见问题与排查技巧实录
5.1 画面卡顿、掉帧怎么办
这是最常见的问题。排查思路如下。
先看网络。用网络测试工具测一下PC到主机之间的延迟和丢包率。如果延迟超过50毫秒或者丢包率超过1%，那问题基本出在网络上。检查网线是否插好，路由器是否过热，有没有其他设备在占用带宽。
再看解码。打开PC端的性能监控，看看GPU的解码占用率。如果解码占用率接近100%，说明解码性能不足。解决办法是降低码率或者换用更高效的编码格式。
最后看主机端。如果网络和解码都没问题，那可能是主机端的编码性能不足。尝试降低主机的输出分辨率或者帧率，看看是否改善。
5.2 操作延迟明显怎么排查
操作延迟和画面延迟是两回事。画面延迟是视频从主机传到PC的时间，操作延迟是输入从PC传回主机的时间。如果你感觉操作延迟明显，但画面看起来很流畅，那问题出在输入回传环节。
排查步骤：先确认你用的是哪种输入模式。虚拟手柄模式的延迟通常比直通模式高10到20毫秒。如果你用的是虚拟手柄模式，尝试切换到直通模式。如果已经是直通模式，检查主机端的驱动是否正常工作。
另外，检查PC端的输入采样率。有些客户端默认的采样率是60Hz，你可以把它提高到120Hz或更高。这个调整对操作延迟的改善非常明显。
5.3 画质模糊、色彩失真怎么调
画质问题通常和编码参数有关。如果你觉得画面模糊，先检查码率是否足够。码率太低会导致细节丢失，画面看起来像蒙了一层雾。尝试把码率提高到80Mbps以上。
如果提高码率后画质没有明显改善，那可能是编码格式的问题。H.264在低码率下画质损失比较明显，H.265在同样码率下画质更好。尝试切换到H.265。
色彩失真通常是色彩采样和色深的问题。4:2:0的色彩采样会导致红色和蓝色的边缘出现模糊，这是正常现象。如果你对色彩有极致要求，可以尝试4:4:4，但需要更高的带宽。
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 画面卡顿 | 网络丢包 | 测延迟和丢包率 | 检查网线、路由器 |
| 画面卡顿 | 解码性能不足 | 看GPU解码占用率 | 降码率或换编码格式 |
| 操作延迟 | 输入模式问题 | 确认输入模式 | 切换直通模式 |
| 操作延迟 | 采样率太低 | 检查客户端设置 | 提高到120Hz |
| 画质模糊 | 码率太低 | 检查码率设置 | 提高到80Mbps |
| 色彩失真 | 色彩采样问题 | 检查色彩设置 | 尝试4:4:4 |
5.4 互联网串流的特殊注意事项
如果你不满足于局域网串流，想在外网也能玩，那需要注意以下几点。
上传带宽是硬门槛。主机所在网络的上传带宽决定了你能用的最高码率。50Mbps的上传带宽大概能支撑30Mbps的串流码率，画质会有一定压缩。
公网IP和端口映射是必须的。你需要在路由器上做端口映射，把串流端口暴露到公网。具体操作因路由器型号而异，一般在路由器的“端口转发”或“虚拟服务器”设置里。
安全性不能忽视。暴露到公网的串流端口需要设置强密码，最好再加上IP白名单或者双因素认证。否则别人可能蹭你的串流通道。
提示：互联网串流的体验受网络环境影响很大。同一个方案，在不同运营商、不同地区的表现可能天差地别。建议先用局域网测试，确认方案本身没问题，再尝试互联网串流。
6. 这套方案的实际体验与适用场景
6.1 哪些游戏适合串流玩
不是所有游戏都适合串流。根据我的实测，以下几类游戏体验最好。
回合制RPG和策略游戏。这类游戏对延迟不敏感，串流带来的那点延迟完全不影响体验。而且这类游戏往往画面精美，在大屏幕上玩更爽。
动作冒险游戏。这类游戏对延迟有一定要求，但在30毫秒以内的延迟下，大多数玩家感觉不到明显差异。我实测下来，这类游戏的串流体验和本地运行几乎一样。
赛车和体育游戏。这类游戏对延迟比较敏感，但在有线局域网下，30毫秒的延迟依然可以接受。如果你用的是WiFi，可能会感觉到一些操作滞后。
不适合串流的游戏：格斗游戏和音游。这两类游戏对帧级延迟要求极高，串流方案的延迟哪怕只有20毫秒，也会影响连招和节奏判定。如果你主要玩这两类游戏，建议还是本地运行。
6.2 和传统方案的对比
我把这套方案和几种传统方案做了对比，结果如下。
| 方案类型 | 延迟 | 画质 | 配置难度 | 适用场景 |
|---|---|---|---|---|
| 本方案 | 20-40ms | 接近原生 | 中等 | 局域网、互联网 |
| 系统自带串流 | 40-80ms | 有压缩 | 低 | 局域网 |
| 第三方串流软件 | 30-60ms | 中等 | 低 | 局域网、互联网 |
| 采集卡方案 | 10-20ms | 原生 | 高 | 局域网 |
| 模拟器方案 | 不确定 | 不确定 | 极高 | 不推荐 |
从表格可以看出，本方案在延迟和画质之间找到了一个很好的平衡点。采集卡方案的延迟更低，但需要额外的硬件，而且只能局域网使用。系统自带串流方案配置最简单，但延迟和画质都不如本方案。
6.3 这套方案解决了什么问题，没解决什么问题
解决了的问题：PC玩家可以在PC上玩主机游戏了，不需要额外买一台显示器或者电视。串流的画质和延迟都达到了可用的水平。配置过程虽然有些步骤，但整体不算复杂。
没解决的问题：你还是需要拥有一台主机。这套方案不是模拟器，它不能让你在没有主机的情况下玩主机游戏。另外，互联网串流的体验受网络环境影响很大，不是所有地方都能获得良好的体验。
我个人觉得，这套方案最大的价值不在于它“免费”或者“绕过”了什么，而在于它展示了一种思路：当面对一个看似无解的问题时，不一定要正面硬刚，换个角度，用现有的技术组合出一个新方案，往往能收到意想不到的效果。
7. 从这个小项目里能学到什么
这群程序员用两个月时间做的事情，技术上并不算特别高深。他们用的都是现有的技术：硬件编解码、UDP传输、输入映射。但他们的价值在于把这些技术组合起来，针对特定的场景做了深度优化。
我从中得到的一个启发是：不要低估“组合现有技术”的价值。很多时候，创新不是发明新技术，而是把现有技术用新的方式组合起来，解决一个具体的问题。这个项目就是最好的例子。
另一个启发是：小团队做 side project，一定要聚焦。这群人只做了核心功能，没有去搞花哨的界面，没有去支持所有平台，没有去实现所有可能的功能。他们把有限的精力集中在延迟和画质这两个最关键的点上，然后把这两个点做到了极致。这种聚焦的策略，值得每一个做 side project 的人学习。
最后再分享一个小技巧：如果你也想尝试这套方案，建议先从有线局域网开始。有线局域网的网络环境最可控，最容易调出好效果。等你把局域网调通了，再尝试WiFi和互联网。这样你可以清楚地知道每个环节的瓶颈在哪里，而不是一上来就被各种问题搞得晕头转向。
