AnyPS5：一套不碰系统底层的PS5多屏低延迟串流方案

先把事情说清楚：AnyPS5不是什么魔改套件，也不是一台新主机，更不是绕开主机系统限制的灰色工具。它是我自己折腾了三个多月的项目，目标很朴素——让客厅里那台PS5的游戏画面和操作，能流转到家里几乎每一块屏幕上，手机、平板、卧室显示器、掌机，谁想接着玩就接着玩。

最早有这个想法，是因为我家客厅电视的使用权常年处于“排队状态”。有时我只是想在卧室躺一会儿，把刚才没打完的章节继续推一推，结果要么把主机搬来搬去，要么只能在手机上看个模糊凑合的官方客户端。用了几次之后，我越来越确定这件事不该这么别扭。AnyPS5就是这么立项的，它的核心思路很简单：主机是算力和内容中心，画面和输入走一条统一调度的链路，家里每块屏幕都作为“普通显示终端”接入，而不是让主机去适配每一台设备。

如果你也有类似困境，或者你本身对低延迟视频传输、跨设备输入适配感兴趣，这篇文章把从架构选型到实际踩坑的过程完整记录下来，可以直接参考。

1. 立项动机：为什么放着官方串流功能不用，非要自己搭一套

1.1 官方方案日常用起来“不得劲”的三个点

PS5本身带官方的串流功能，手机和PC上也有官方客户端。我并没有否定这个方案的意思，事实上AnyPS5早期的原型就是围绕它展开的。但在真正高强度用了两周之后，我发现三个绕不开的问题。

第一个是设备覆盖面太窄。官方客户端支持的设备类型是固定的，手机、平板、PC这些主流平台没问题，但家里那些电视盒子、开源掌机、老旧的迷你PC，并不在被支持列表里。我一度想用一个吃灰的电视盒子去串流，结果系统提示设备不受支持，连安装都无法进行。更麻烦的是，每次切换设备都要重新走一遍账号授权和配对流程，家人想玩时往往被这一步卡住。

第二个是输入映射完全固定。官方方案面对手柄时很自然，但我的场景里经常会遇到触摸屏、键盘、甚至一些奇奇怪怪的第三方手柄。官方客户端的输入协议是封闭的，想要把触摸屏某个区域映射成特定按键，或者在背键上增加额外操作，完全做不到。有些游戏对操作精度要求高，触摸屏如果没有自定义映射，整个体验就是崩溃的。

第三个是会话管理太“一台对一屏”。官方方案默认你最多同时活跃一个远端会话，客厅电视一旦占着主机输出，其他地方再想接入就要先断开前一个会话。我家的场景是：客厅有人看电影、卧室有人想玩游戏，或者孩子想在书房看我打一段，这种“同时观看”的需求官方方案没法体面满足。

1.2 我给AnyPS5定的四个目标

既然要自己搭，就得先把目标写清楚，不然很容易做成“什么都想弄，什么都半吊子”。最终我给自己定了四条硬指标。

一是一台主机对应多块屏幕，所有设备通过同一个入口接入，家人不需要理解“串流”“会话”这些概念，打开页面就能用。二是端到端延迟控制在80ms以内，局域网内比官方客户端默认配置更低，至少让我觉得“这游戏还是能打的”。三是输入层必须灵活，手柄、触摸映射、键盘都能接入，而且切换设备时不需要反复配对。四是整体改动不碰主机系统底层，所有自定义逻辑都跑在主机外部。

1.3 立项红线：不碰系统底层，不做灰色渠道

这里要特别说明一下边界。我在立项第一天就给自己定了红线：不做任何系统级越权，不做固件级修改，不碰任何灰色渠道。AnyPS5做的事情，可以理解成在主机外面加了一层“调度网络”——主机只负责输出画面、接收标准手柄输入，所有自定义的转发、映射、多屏管理，都在这层调度网络里完成。

这条红线不仅是安全考虑，也是实际工程上的约束。主机系统一旦被改动，升级、稳定性、账号安全都是连锁问题，完全得不偿失。保持主机侧绝对“干净”，每次系统更新我都照升不误，反而少了大量兼容性麻烦。

2. AnyPS5的骨架：一条从主机到屏幕的数据链路

2.1 画面怎么流出去，操作怎么流回来

整个项目的数据流可以概括为两段。下行方向，游戏画面从主机输出之后，被网关获取，网关把自己的地址暴露给家里所有设备，设备通过网页或轻量客户端打开一个播放窗口。上行方向，设备上的手柄操作或触摸指令被打成小包，带着时间戳回传到网关，网关再把指令转换为标准输入格式送给主机。

听起来并不复杂，但真正工程化的时候，每一段都有各自的麻烦。下行方向核心是“延迟预算”，上行方向核心是“优先权”。我最初的版本把上行和下行混在一起处理，结果操作经常被视频流排队挤到后面，游戏里按下跳跃键，画面要顿一下才跳。后来我把上行通道独立出来，并在数据包头上标记“输入优先”，问题才得到缓解。

2.2 为什么一定要加一个“中间层”

有人可能会问：主机本身不就能直接输出视频信号吗？为什么还要加一个中间层专门做转发？

这个问题我一开始也没想透。第一版原型我试过让每一台设备直接和主机建立会话，结果主机侧连接状态变得非常混乱。一台主机面对多个设备时，它会认为自己在处理多个优先级相同的会话，频繁切换会话导致画面重新加载。更麻烦的是，每个设备都直接去理解主机侧的输入协议，我每增加一种设备，就要重新适配一次。

中间层其实是把“设备适配”这件事集中收口。AnyPS5的中间层只做三件事：会话管理、流分发、输入协议转换。设备不关心主机是什么型号，不关心官方协议细节，只面向中间层暴露一个统一接口。换一个新设备，只需要让这个设备能播放网页视频流、能发送标准按键包，就可以接入整套系统。

打个不太严谨的比方：主机就像家里唯一的热水器，每间浴室都想用热水，如果每间浴室都直接接管热水器开关，那必然打架。中间层就像水管总管，热水器只要稳定出水，总管负责分流、调温、分配，每间浴室拧开自己那根水管就行。

2.3 模块拆解和硬件清单

AnyPS5在结构上分四层，下面用表格整理一下。

硬件清单方面，核心设备是：一台PS5、一台跑网关的小主机（我用的是闲置的迷你主机，8GB内存足够）、一台支持2.4G/5G双频的路由器、至少两根千兆网线。客户端设备随意，手机、平板、笔电、电视盒子都行，但解码能力会影响体验，这一点后面单独讲。

软件侧没有用什么重型平台，网关主体是几段轻量服务，客户端就是一张网页，核心逻辑都集中在“流分发”和“输入映射”两个模块上。这样做的意图很明确：越是靠桌面环境全家桶，升级越容易踩雷，轻量服务反而好维护。

3. 延迟从哪来：我把五个环节拆开压了一遍

3.1 先给延迟算一笔预算账

做串流方案最容易掉进去的坑，就是“只知道延迟高，不知道延迟高在哪”。AnyPS5立项初期我定了个80ms的端到端目标，然后把这80ms拆成预算。

我的预算表大致是这样的：主机侧编码和输出，15到20ms；局域网传输，5到10ms；客户端解码缓冲，10到30ms；输入回传链路，5到15ms；客户端渲染和显示输出，5ms左右。加在一起差不多50到80ms，和我的目标吻合。

这个预算表的最大作用，是让我在体验出问题时能做“分段定位”。如果体感延迟超过200ms，我就用时间戳逐段测，看是哪一段爆了。网关日志里给每个视频关键帧打上到达时刻，客户端再回传一个收到时刻，两个时间戳一减，就知道传输耗时。这套埋点方法虽然土，但比靠感觉调参可靠得多。

3.2 编码端：不是码率越高越好

很多人一上来就把码率拉满，觉得画质好等于体验好。实际上在串流链路里，编码端最能影响延迟的不是码率大小，而是编码缓冲和帧结构。

主机输出模式下，如果编码器允许积压大量B帧，画面的压缩效率确实会高一点，但解码端必须等这几个帧都到齐才能还原画面，积压越多延迟越大。AnyPS5在网关配置里强制走低延迟编码档位，关闭或尽量减少B帧缓冲，宁可牺牲一点压缩效率，也要让画面帧“到了就解，解了就显示”。

编码格式方面，我建议优先选用HEVC，这种格式在同样码率下画面细节保留更好，尤其是动画或者夜景比较多的游戏，观感差距明显。但它有一个前提：客户端必须支持硬解。如果客户端芯片不支持HEVC硬解，编码器反而要花费额外时间做兼容处理，延迟会一夜回到解放前。所以我在网关里加了一个能力探测，客户端连接时上报自己支持哪种硬解格式，网关再决定喂哪一种流。

3.3 网络端：有线回程比“Wi-Fi信号满格”重要得多

局域网串流最大的错觉，是以为Wi-Fi信号满格就代表传输质量好。测速软件会告诉你平均延迟很低，一旦拖到真实的连续视频流里，无线信道的抖动立刻暴露。抖动是什么？就是每个数据包到达时间的偏差。

画面连续播放时，如果包与包之间的间隔忽长忽短，解码端就必须靠缓冲来“抹平”这种波动，缓冲一多，延迟就上去了。所以AnyPS5的现场网络原则很简单：PS5和网关必须通过网线直连到主路由器，能不用无线就不用无线。客户端设备可以走Wi-Fi，但尽量使用5GHz频段，2.4GHz在干扰少的环境里也能用，不过稳定性看运气。

如果你家里是Mesh组网，还要注意一点：网关和主机最好都挂在同一个节点下。无线回程Mesh会多一跳传输，果不其然延迟会平白多出5到10ms，这对20ms的网络预算来说是相当大的损耗。

3.4 解码端：不是每台设备都能硬接1080p60

客户端解码是我的第三个优化重点，也是家里各种设备差距最大的地方。新一些的手机和平板支持硬解，跑1080p60很轻松，解码环节几乎不产生额外延迟。但一些老电视盒子、低端掌机，如果不支持对应格式的硬解，视频流就会落到软件解码，CPU瞬间拉满，掉帧、发热、音画不同步全来了。

我的处理方式是网关做动态降级。侦测到客户端解码能力不够时，自动把画面降到720p，并且降低帧率到50帧。这个动作会稍微损失一些流畅度，但换来的是稳定的帧间隔。串流游戏最怕的不是“画质降一级”，而是“画面忽快忽慢”，动态降级之后整体体感反而更好。

3.5 输入端：操作回传必须走优先通道

最后一个环节是输入。手柄按下按键，指令要回传到主机，主机再把新画面推出来。很多时候玩家感觉“不跟手”，问题不在画面下行，而在输入上行被拥堵的视频流挤到队列尾部。

我最早没把上行输入独立出来的时候，实测按下一个按键到画面变化的延迟大约有120ms，玩游戏就像在隔着一层棉花操作。后来我在网关里把输入通道单独抽出来，用较小的、固定频率的包传输控制指令，并在网络层给这种小包打了高优先级标记。修改之后，输入延迟降到30ms左右，整体的“跟手感”一下就不一样了。

这个优化同样有一个边界：如果家里其它设备在大量下载，占满了网络带宽，再高的优先级也会被拥挤的路由器缓存拖累。所以AnyPS5的家庭网络建议是，主路由打开流量整形，给视频流所在的VLAN留出一个专门队列，但不要用简单的“UDP优先”一刀切——我自己就在这上面栽过跟头，后面详细说。

4. 三个月踩坑实录：有些问题真的很反直觉

4.1 HDMI控制功能让串流画面莫名闪断

AnyPS5跑到第二周时出现了一个诡异问题：串流画面播放大概几分钟就会闪一下黑屏，随后自动恢复，恢复后音频重新对齐，看起来像是视频流中断了一次。我一开始怀疑是网线松了、编码器过热、客户端硬解不稳定，挨个排查全都正常。

最后发现根源在电视。客厅电视开启了HDMI控制功能，这个功能允许电视通过HDMI线缆反向控制连接在上面的设备。某次电视进入待机流程时，它认为应该把主机信号切换到另一个HDMI口，这种切换动作并没有真的切断画面，但还是把主机侧的画面状态“打扰”了一下，于是串流流被强制重置。

解决办法很简单：关掉电视的HDMI控制功能，或者在电视设置里把主机对应HDMI口的“快速切换”关掉。这个坑最让人无语的地方在于，它不是网络问题、不是编码问题，而是客厅电视和主机之间的“一纸协议”。从那以后，AnyPS5的调试日志里专门加了一个字段，记录画面中断前是否有HDMI信号状态变化，至少以后再遇到类似问题能快速定位。

4.2 QoS规则把“输入指令”也排到了大流量队列尾

这个坑非常反直觉，而且花了我最长时间。为了给串流画面腾出带宽，我在路由器上设置了一条规则：把视频流使用的UDP端口打上最高优先级。结果当天晚上打游戏就出现了新的怪现象——画面流畅度提高了，但操作延迟明显变大，经常出现“按下按键，过一会儿才有反应”。

我原本以为是网关的输入模块出了问题，反复调整了半天都没用。后来拿着抓包工具看流量特征才明白：我的视频流和输入流用的是同一个协议类型、同一个端口段，QoS规则只会“按流量分类”，不会去判断这个包到底是画面数据还是按键指令。于是输入小包和视频大包被归到同一个高优先级队列，路由器忙着转发大流量，小包只能在队列尾慢慢等。

解决办法是把QoS策略从“按端口分大类”改成“按包大小分级”。小于一定字节的包直接走最高优先级通道，视频这类大包走次要通道。正因为输入的按键包通常都很小，这个策略几乎完美匹配需求。这也是我在前面强调“不要简单用UDP优先”的原因——分类逻辑越粗，误伤面就越大。

4.3 手柄多设备切换的配对记忆冲突

AnyPS5要服务多块屏幕，手柄自然也会在多台设备之间切换。我一开始的做法是：想在掌机上玩，就把手柄和掌机配对一次；换到平板，再重新配对。表面看问题不大，但使用几天后，手柄开始频繁出现“连接上了却持续掉线”的情况。

问题出在手柄固件的配对记忆上。手柄内部会记住最近一次配对信息，我们在设备A和设备B之间反复横跳，每次“重新配对”都会往手柄里写入新的连接信息。一旦手柄和某个设备的连接状态没有完全释放，就会莫名其妙地自动连回上一次的设备，然后和当前设备断掉。

后来我换了一个思路：不再让手柄和多个客户端设备直接配对，而是让一个固定的接收设备挂载手柄，由它作为输入桥接。客户端之间切换时，手柄始终连接在这个桥接设备上，AnyPS5只需要切换的是“命令从哪个客户端接收”，而不需要手柄重新去配对。这样改动之后，手柄掉线问题再也没有出现过。

4.4 千兆网线不如一根短跳线管用

这个案例特别能体现家庭环境中“物理层优先”的道理。为了保持客厅整洁，我把PS5接到了墙壁网口，由墙壁暗线连到弱电箱里的主路由。结果AnyPS5在串流时总出现零星的画面撕裂和音频杂音，测试工具显示丢包率并不高，但视频流的关键帧偶尔丢失。

一次偶然改动解决了一切。因为要临时调试，我直接拔掉墙壁暗线，用一根一米长的网线把PS5临时接到主路由旁边。之后串流连续跑了整整一个下午，一次画面异常都没有。我这才意识到，旧房预埋的墙壁网线实际只跑通了百兆速率，而且线缆本身存在老化破损，虽然平日网上冲浪看不出区别，但串流这种持续高带宽低抖动要求的场景立刻就会露馅。

经验总结就是：局域网串流先看物理链路，再做软件优化。如果你也搭了类似的串流系统，建议先用一台笔记本配合网线直连测速，确认链路能稳定跑满千兆的持续带宽，再聊画面参数。

5. 还能往哪走：AnyPS5的下一步规划和边界

5.1 把启动器和存档整理进同一张页面

目前AnyPS5已经把“玩”这一条链路打通了，接下来一个方向是做启动整合。我设想的场景是：打开AnyPS5的入口页面，看到的不是一张单纯的串流播放器，而是一列“游戏卡片”，每张卡片对应主机上安装的一个游戏。点一下卡片，网关会通过标准输入指令模拟操作帮助启动游戏，玩家不用再拿着手柄在主机系统菜单里来回找应用。

存档的方向也在考虑，但定位是“提醒”而不是“自动云覆盖”。网关可以定期读取存档状态变化并推送通知，避免多设备交替游玩时弄不清楚哪份存档是最新的。自动同步我暂时不做，因为主机存档走的是系统自己的逻辑，外部直接干预很容易造成版本冲突，风险大于收益。

5.2 多用户并行的可行性边界

很多朋友问过：能不能让两台设备同时玩两个不同的游戏？这个问题受制于主机本身的输出能力，一台机器同一时间只能输出一路游戏画面，所以AnyPS5在多用户并行上只能做到“画面观看并行，操作串行排队”。

实际跑下来，这个边界感反而挺清晰。客厅里有人看电影时，卧室的人可以正常接入玩游戏；如果有人想在另一个屏幕“围观”，网关可以额外分发一画面流，延迟比主会话高一点点但足够看。如果两个人想同时操作不同游戏，那就必须等主机侧具备多个独立会话的能力，这不是一个外部网关能解决的。

5.3 边界就是价值：哪些事情AnyPS5坚决不做

最后想说一下项目的边界。AnyPS5从立项到今天，有一条原则从来没变过：不碰主机系统底层，不做任何越权修改。网关做的是设备侧的调度和适配，主机始终是一台“标准的主机”。

这件事的价值在于：当系统推送新版本时，我可以第一时间升级而不用等待兼容性修补；当游戏更新需要联网验证时，网络环境完全干净；当家里其它成员想自己去理解这套系统时，入口足够简单，不需要了解任何底层逻辑。折腾往往是为了解决真实问题，而不是为了证明“我能改动什么”。AnyPS5真正让我满意的，是它把“屏幕自由”这件事做到了，而主机本身依然是那台“什么都能玩”的机器。

最后再分享一个小技巧：如果你想复刻一个类似的项目，不需要先把所有功能都做完，先用一根质量靠谱的短网线，把主机、网关和主路由之间用有线连接起来，再把串流设备放到5GHz频段。这两个物理动作做对之后，剩下的软件调参才有意义。我在初期浪费了大量时间在软件配置上，最后才发现最值钱的优化，是那根看起来毫不起眼的网线。