平时看别人折腾各种主机外设我自己一直有一个很具体的抱怨主机明明就放在客厅可但凡想在书房、卧室、办公室拿起来玩一会儿就得去搬电视、倒腾 HDMI、或者买一台专门放在旁边的便携屏。折腾一圈下来游戏没玩几分钟人倒是先累了。所以最近做了一个小项目名字就叫 AnyPS5。思路很简单把自己那台 PS5 变成一种“可以被任意设备随时访问”的存在无论手机、平板、电脑、还是浏览器只要能联网就能连接过去。听起来很像远程流式传输方案但实际做下来你会发现它多了一层很有意思的东西一套统一的主机访问入口。这篇内容就是这次折腾的完整记录包括架构思考、编码参数、输入映射、踩过的问题和调试手段希望能给同样在搞主机远程访问、或者想自己做一个小型流媒体控制中枢的朋友一些参考。提示这不是官方功能也不是任何商业产品的拆解纯粹是一个业余项目在某个周末用开源思路拼出来的实验性系统。方案本身图一个“自己用着爽”很多地方会为了便利性牺牲一部分工业级严谨性。1. 项目初衷与目标场景1.1 从“一台主机一块屏”到“一个入口多端随手用”传统游戏主机的逻辑是“一台主机服务一块屏幕”你坐在哪台显示器前游戏就在哪里跑。但在实际生活里人的位置是流动的下午在书房用电脑晚上挪到客厅窝沙发出门前又想在手机上确认一下商店或者收一下每日奖励。如果每一次位置变化都要把主机搬来搬去体验就非常割裂。AnyPS5 的定位就是把“主机访问”这件事从物理连接中解放出来。主机本身不动我另外写了一个轻量级服务端挂在主机所在的局域网里再在前端分别做了 Web 页面、移动客户端和桌面客户端形成一个统一入口。无论你手头是什么设备打开客户端就能看到同一台主机的画面。这样做最大的价值不是“远程玩游戏”这个功能本身而是它把访问成本压缩到了极低不需要专门买采集卡、不需要额外配一台电脑常驻采集画面也不需要转接 HDMI 信号。全部链路只依赖主机本身的网络能力、家用路由器的带宽和一台很普通的服务端设备。1.2 我想解决的三个具体痛点第一个痛点是延迟。很多现成方案都是“画面能看到但操作没法玩”主要损失在采集、编码、网络传输、解码那几段。AnyPS5 从第一天开始就以“能打的延迟预算”为设计目标后面我会单独拆解一次完整的延迟链路。第二个痛点是输入映射。手机、平板没有标准手柄浏览器里的按键、触屏、鼠标到底怎么映射到主机功能是一个非常令人头大的事情。映射做错了用户就会感觉到“按键响应奇怪”“摇杆不跟手”“鼠标转视角跟碰了鬼一样”。第三个痛点是接入成本。很多方案要装专用应用、要内网穿透工具、要做端口转发、要调一堆配置文件。AnyPS5 在设计上尽量做到“扫码即连”局域网内自动发现、配对成功后绝大多数参数自动协商用户打开页面就能看到画面。这三个痛点说实话都不算原创但把它们揉进同一个项目里并且保持“普通人也能搭起来”的克制感是这个项目真正有用的地方。1.3 为什么没有被现成方案直接劝退说实话刚开始正经查了一圈资料之后我也一度觉得没必要自研市面上已经有非常成熟的远程游玩方案和串流工具直接用现成的不好吗但实测下来有几个问题很难绕开官方的玩法面向的是同品牌生态内部对跨设备、跨平台支持不够灵活。通用串流工具普遍适配的是“台式机到台式机”或者“手机到电脑”的场景和主机之间的信息互动做得很浅进不了主机系统级菜单处理不了授权和手柄映射。很多方案是封闭的不能改造协议也就没法加入我想要的“统一入口”和自定义输入层。我自己做 AnyPS5核心不是再去发明一个串流协议而是把传输、编码、输入、鉴权这些模块全部解耦自己掌控每一层。这样后面对接第三方设备、修改延迟策略、新增输入设备时就不用看别人的脸色。2. 整体架构与关键技术决策2.1 总体架构分层AnyPS5 的架构没有做得很复杂主要分成四层接入层负责设备发现、连接鉴权、会话管理对外提供统一 API。控制层负责接收来自不同客户端设备的输入指令并把它们转换成主机可识别的标准输入事件。媒体层负责画面采集、硬件编码、网络传输和客户端解码是整个项目中延迟占比最高的一层。适配层给第三方客户端提供一套尽量简单的 JSON 协议让任何平台都能快速接入。架构上有一个很刻意的选择服务端和管理界面分离。服务端只做媒体转发和桥接管理界面只是其中一个客户端。这样做的原因是我希望同一个服务端可以被多个客户端同时连接典型场景就是“主机开着我用手机先连上看一眼再用电脑接管操作”两个连接在服务端互不干扰。服务端进程 ├── 连接管理器WebSocket UDP socket ├── 输入注入器将标准化按键映射为系统输入 ├── 视频编码管线采集帧 → 硬件编码 → 分片投递 ├── 发现服务局域网广播和回复 └── 会话管理令牌校验、权限控制、心跳监测这里要说明一下我为了避免版权和驱动层面乱七八糟的问题从第一版就明确不做“系统底层篡改”而是用工控级的模拟输入方式把标准化按键事件转译到主机的系统层接口。2.2 通信协议选型为什么不是一味追求“全 UDP”流媒体场景里很多人第一反应就是“必须用 UDPTCP 延迟高重传会粘滞”。这个判断在互联网长距离开放网络环境下是对的但在局域网范围内未必全对。AnyPS5 第一版直接上了 WebSocket over TCP 做视频传输理由如下局域网内丢包率极低TCP 的拥塞控制不会频繁触发。WebSocket 天然支持双向消息握手、鉴权、输入指令和视频帧可以共用同一个连接简化开发量。主流浏览器和移动客户端都原生支持 WebSocket不需要额外安装驱动。TCP 重传带来的风险我做了两层防护一层是强制开启 NO_DELAY 降低小包延迟另一层是主动丢帧策略。编码器产出的关键帧和普通帧分标记一旦发送队列积压超过阈值就把未来的普通帧丢弃只保留关键帧。等做到了跨公网版本我确实又补了一条 UDP 通道做视频流的低延迟传输控制命令仍走 WebSocket视频码流走专门的 UDP 通道这样兼顾了可靠性和低延迟。2.3 编码参数怎么定一个从带宽倒推的计算过程远程串流表现好不好很大程度上在编码参数上就已经决定了。官方串流工具的很多参数是固定给主机内部记录的第三方很难摸到所以 AnyPS5 的编码参数完全是自己控制的。我做了一次最基础的带宽预算假定家里上行带宽是 50 Mbps考虑到其他设备占用串流最多能分到约 80% 的上行能力也就是 40 Mbps。流媒体编码一个常见的经验值是1080p60 下H.264 编码器想要画面细节和流畅度达到可观的水平推荐码率约等于 8~12 Mbps。如果上到 4K30则至少需要 20~30 Mbps。于是做了一个简单的分级表客户端屏幕能力编码分辨率目标帧率码率范围手机竖屏960x54030fps2.5~4 Mbps手机横屏1280x72030fps4~6 Mbps平板/电脑窗口1920x108060fps8~12 Mbps电视/全屏2560x144060fps16~24 Mbps极限模式3840x216030fps24~32 Mbps我最后默认采用 1080p60 档位码率控制在 10 Mbps再叠加 1 秒缓冲池。为什么不是 4K60因为延迟预算受不了。编码器的复杂度跟像素总量强相关像素从 1080p 涨到 4K编码耗时基本是非线性增长而回到串流这种互动场景画质提升一截、延迟翻一倍综合体验反而降级。编码参数在视频编码器里的具体配置是这样调整的编码器选择优先硬件编码器不支持再回退软件编码器。编码档位选了更偏向低延迟的档位关掉 B 帧让解码端不用等重排。关键帧间隔设成 2 秒一次强制关键帧也就是每 120 帧至少有一个 I 帧便于客户端在切流、花屏时快速恢复。参考帧数限制在 1~2 个参考帧减少参照依赖。这样算下来整体链路延迟被压在可接受范围内。2.4 安全鉴权简单但不等于裸奔因为它本质上是把主机“暴露”在网络上所以安全鉴权我专门花了一个下午认真对待。AnyPS5 的服务端不采用“所有人连上就放行”的默认模式连接必须经过两个阶段第一阶段是配对。首次连接时服务端生成一组一次性配对码客户端在页面上输入配对码服务端通过零知识验证方案完成握手。这样即使监听网络流量别人也拿不到可以冒充的密钥。第二阶段是会话令牌。配对验证之后服务端颁发一段有效期 30 分钟的会话令牌后续所有 WebSocket 请求都携带令牌。令牌过期后会自动刷新不需要用户重新配对。整个链路强制加密局域网内不做裸流传输因为很多现代设备的系统级媒体管线会默认拒绝明文流。注意配对码只在首次设置时需要之后设备会进入“已信任设备”列表。如果你把客户端给一个陌生人用记得在管理界面里把该设备删除否则对方仍能在一段时间内自动重连。3. 核心模块实现细节3.1 设备发现模块让用户少填 IP对一个家用工具来说让用户手填 IP 地址已经算一种失败体验。AnyPS5 的设备发现我采用“局域网广播 服务注册”双通道服务端启动时向局域网内发送 UDP 广播包声明自己的能力。客户端启动时向局域网发送查询请求服务端收到后直接应答自己的地址和端口。如果广播被路由策略挡住还支持用户手动输入主机别名由某个轻量级注册中心提供解析。从可用性角度看广播发现至少要支持同一网段内的自动识别。实际开发中有个坑部分无线路由器默认开启“AP 隔离”设备之间不能互相广播。这种情况下我用了第三个保底通道通过云端的协调服务器做了单向信令穿透。客户端登录之后服务端所在网络主动连接到协调服务器客户端通过同一个协调服务器的会话表找到服务端不需要用户去改路由设置。3.2 视频流模块采集、编码、推流的三个阶段视频采集在 PC 上其实有多种方式我选了兼容性最好的桌面捕获接口原因是用它可以拿到未压缩的原始帧。采集逻辑不要求满帧率抓取而是按目标帧率均匀抓取比如 60fps 就每 16ms 抓一次减少无用帧对 CPU 的压力。采集到的原始帧直接送编码器。为了降低延迟我没有用典型的环形缓冲队列而是让采集线程和编码线程共享一块双缓冲内存。采集线程填满 buffer A 时编码线程处理 buffer B两个线程交替工作避免互相等待。编码完成之后媒体层按 32KB 最大分片切分每片带着递增序号和时间戳发送到客户端。客户端的解码策略也很重要。我没有选择“等攒满一帧再渲染”而是收到关键帧后立刻解码并在下一条关键帧到来前持续渲染收到的普通帧。这样做的代价是有可能显示几帧花屏但换来的是帧率更稳定、延迟更可控。3.3 输入注入与动作映射模块这是整个项目里最考验细节的模块。不同客户端设备的输入方式完全不同手机屏幕左右两侧分别画虚拟摇杆和按键区。平板可以是触屏也可以外接蓝牙手柄。电脑优先读取键盘鼠标也支持接入标准手柄。浏览器必须先从浏览器安全策略允许的范围里拿到用户操作事件。AnyPS5 的做法是先把所有输入统一成“抽象输入事件”比如LEFT_SHOULDER、MOVE_STICK_LEFT、PRESS_CROSS再由输入注入器根据当前主机的系统设置把这些抽象事件映射成最终按键。这里有一个很关键的点抽象层负责逻辑映射层负责适配。比如一个动作游戏玩家习惯“X 键跳跃”但另一个赛车游戏中“X 键是刹车”同一个抽象按键到最终系统键的关系其实是可配置的。我默认提供两套预设映射“经典模式”摇杆控制移动面部按键控制动作肩键控制视角。“灵敏模式”把右摇杆映射为鼠标指针适合在系统界面和浏览菜单时使用。映射配置存在 JSON 文件里用户可以自己改改完即时生效不需要重启服务端。我在实际测试中发现最大的问题反而不是按键映射本身而是“按键冲突检测”。比如手机端的虚拟摇杆和键盘方向键同时输入如果映射层不及时处理主机会收到两个互相矛盾的移动信号表现就是角色原地抽搐。我在映射模块里加了一个优先级判定后到达的输入事件拥有更高优先级同时将前一个输入方向按 3 帧的时间窗口平滑释放。3.4 对外 API 设计给第三方客户端留一条路很多此类项目只做“自己家的 App”把接口全部锁住。AnyPS5 我坚持提供一个极简的 JSON 控制协议原因很实际我自用的前端不一定覆盖所有平台的细节与其把每个平台都写出原生应用不如做一个协议让任何人可以快速接入。接口设计上坚持三个原则一是每个端点都是无状态请求客户端自己管理上下文二是返回结构统一为{code, message, data}前端处理起来非常一致三是所有长连接都走同一个状态机连接状态、会话状态、播放状态各自独立又可以互相查询。拿“开始串流”这个动作举例子客户端发起的不是一条指令而是三条查询主机当前状态待机/运行中/繁忙。请求建立会话并申请视频参数。建立媒体通道并上报客户端能力。这样分层是为了避免热闹半天才发现主机已经有不少用户占用了。4. 从零到能用的实操过程4.1 开发环境与依赖工具开发 AnyPS5 的实验环境很简单一台普通家用台式机当作服务端。一台解码能力还行的手机、一台平板、一台老 Windows 笔记本当作客户端。路由器沿用家里原有的普通家用款式没做任何特殊配置。服务端开发语言我选了 Rust主要图编译产物干净、并发处理靠谱尤其是我这种要用多线程处理采集和编码的场景。客户端这里用浏览器优先因为调试最方便手机 App 只是用浏览器内核简单封装了一层以便支持全屏和自动旋转。依赖的组件基本是开源生态里非常常见的几个库这里不具体点名了建议新手直接用官方文档案例跑一遍不要从零造编码器。4.2 拿到手柄输入事件的关键步骤要让远程端操作本地主机第一步就是本地能收到输入事件。Windows 平台上游戏手柄的事件读取有两条路一是标准输入子系统二是使用全局钩子监听硬件消息。AnyPS5 没有采用全局钩子方案原因是它会在某些安全软件下被拦截而且和多用户桌面会话混在一起会出现状态混乱。实操中我主要做这样几件事枚举当前连接的输入设备拿到设备 ID 和设备类型。持续读取设备状态每 10ms 一次避免同一按键被重复触发。对读取到的原始数据做差值处理只有状态发生变化时才生成一条标准化事件。将这些事件交给抽象输入层由输入注入器转译为主机的输入 API 调用。踩坑经验是很多主机上的输入 API 对“短促低频可信”的要求比普通 PC 上严格得多。模拟输入发送太频繁或者时间间隔不均匀会导致主机自动判定为“无效信号”并直接忽略。最终我是按“下载频率 125Hz、每次发送间隔 8ms 固定节拍器”来实现的效果才稳定下来。4.3 建立加密通道与分布式配对加密通道在局域网内看似不必要但跨公网连接时就是刚需。我采用的方法是在 WebSocket 握手完成后立即通过 TLS 的加密层继续传递验证消息生成两种不同的会话身份控制身份用于接收来自客户端 UI 的常规指令。媒体身份仅用于视频流通道权限只包含接收画面和提供输入事件。两个身份分离好处是即使媒体身份被截获别人也无法通过它控制主机的系统菜单。配对流程做成四步服务端生成一次性配对码以二维码或文本形式呈现。客户端输入配对码发送。服务端用配对码签名后返回一个加密过的初始化向量。客户端使用该向量启动会话之后的连接全部使用会话级密钥。有一点需要注意的是配对码有效期我设成了 5 分钟过期作废必须在服务端上重新生成。这样做主要是防止配对码长期有效导致弱口令风险。4.4 自适应码率的实现思路自适应码率是串流系统里非常影响体验的一环网络稍有波动如果不调整码率就会出现长时间花屏。AnyPS5 的码率调整逻辑不复杂但效果还比较稳。它在服务端维护了一个滑动窗口记录最近 1 秒内发送队列的积压字节数、实际发送速率、丢包判断和客户端反馈的渲染帧率。每个 500ms 做一次决策如果队列积压持续增长就下调码率一个档位例如从 12 Mbps 降到 9 Mbps。如果积压清零且吞吐量有余量就每隔 3 次采样上调一个档位。如果出现丢包直接下调到最低档位并尽快补发关键帧。初期出现的问题是我把调整窗口定得太短结果网络稍微抖一下就反复上下调档画面一会儿清晰一会儿模糊体验反而更差。后来加入“稳定系数”——必须连续 3 个采样周期都满足条件才调整情况才稳定下来。4.5 最小可用版本与验证清单如果你也想复刻类似的小项目下面的清单可以作为你的“能用了”标准手机和电脑能自动发现同一局域网内的服务端。配对后服务端返回主机状态状态与真实系统一致。远程画面延迟在局域网环境下低于 80ms公网前提下低于 160ms。手柄、触屏、键盘三种输入都能完成 360 度转视角和按键响应。网络抖动时画面从清晰变成模糊但不卡死的流程能自动恢复。服务端断开崩溃后所有客户端能自动回到待机界面且不会卡死。配对码过期、删除设备、刷新令牌这三件事在页面上能操作。如果以上七条都通过说明核心链路已经通了后面做功能增强就只是锦上添花。5. 常见问题与排查记录5.1 延迟高、卡顿和画面模糊这是最容易被感知的一类问题也最容易误判。先说结论延迟高的原因大概率不是网络带宽不够而是排队缓冲。排查方法按顺序做先看延迟是不是恒定偏高区间在哪个范围。打开服务端的发送队列长度指标看积压是否持续存在。用抓包工具看一下是否大量 TCP 重复 ACK如果很多说明网线或无线链路本身有大量丢包。检查客户端是否开了“省电模式”很多手机后台会限制网络吞吐然后直接表现为画面卡顿。我遇到的一个典型问题是无线网络下表现很好但换到有线反而出现卡顿排查后发现是有线网卡驱动里的巨型帧协商异常。解决办法是把网卡速度固定到 1Gbps 而不是自动协商症状立刻消失。这种问题从应用层看完全无解只能从链路层破。5.2 输入失效、按键重复、摇杆漂移输入问题我踩的坑最多。首当其冲的是“按键重复”客户端按住一个键不松手经过去抖动处理后事件被发送了两次主机端收到了两次按下而没有收到抬起角色就一直跑。解决方案是引入一个“按下/抬起状态机”每个按键同一时刻只能有一种状态重复的按下消息直接丢弃。摇杆漂移通常是两个原因一是客户端触控区域计算偏差比如虚拟摇杆没有归零就发送了后续偏移二是服务端输入映射器的阈值没有设置死区。我给摇杆加了 15% 中心死区还把最小偏移量限制为 1%这样即使手指轻微抖动也不会传导到主机端。另外如果你的鼠标转视角很“滑”大概率是因为鼠标相对位移和主机的视角控制曲线不一致。我这里不想过度展开只说结论宁可把灵敏度调低一点也不要让视角加速度曲线重复计算。5.3 设备找不到、连接不上、反复掉线局域网设备发现失败第一件事就是检查路由器的“AP 隔离”开关第二件事是确认防火墙有没有拦截 UDP 广播包。比较坑的是很多安全软件默认拦截“局域网程序访问网络”导致广播包发不出去。连接不上还有一个隐蔽原因服务端的主机不支持同一时间多个用户会话。AnyPS5 默认最多允许两个并发连接一个用于控制、一个用于媒体超出就会拒绝。如果多台设备同时争抢后面启动的客户端就会显示连接失败。反复掉线的问题我最后定位到是会话密钥的刷新机制某些客户端实现里WebSocket 重连时只重新建立传输层却没有重新完成密钥协商结果服务端就拒绝新通道。修正方式很简单每次重连都必须重新走一遍“控制身份验证媒体身份申请”不能复用旧密钥。5.4 CPU 占用过高与内存泄漏CPU 占用高大概率落在编码器选择上。软件编码器在 1080p60 下能让你看见 CPU 占用直接拉满所以有条件一定要优先走硬件编码器。当然如果你用的采集源本身是 4K那在缩放阶段就会造成 CPU 压力我在媒体层把采集分辨率限制在目标分辨率再送编码器避免多余缩放。内存泄漏的排查思路是这样的先打开内存曲线观察持续增长再用排除法逐模块禁用最终定位到视频帧的引用计数赋值错误。原因是多线程共享帧数据时忘记及时释放上一帧引用导致积压。我的项目里最终用 Arc 引用计数配合帧池化解决代码逻辑复杂一些但现在长时间开机内存曲线很平稳。6. 一点后续扩展思路AnyPS5 目前对我来说已经是一个足够稳定的常用工具。如果你看完也想在自己家里搭一套类似的访问入口我有几个很具体的建议不要一开始就做多平台客户端直接用浏览器验证核心链路省掉大量适配工作。输入映射模块一定是先做再考虑视频优化否则你根本没法在手机上完成一次调参操作。一定要把状态机设计得足够清晰尤其是会话状态否则后续加“待机唤醒”“自动休眠”“多用户切换”时会被各种竞态条件折磨疯。让一台主机同时服务多个场景这件事做起来确实比想象中琐碎。但只要第一个能用的版本跑通后面每一次优化你都会明显感觉到收益。我个人更期待下一步给 AnyPS5 加上“按房间自动切换参数配置”的能力在同一个家里客厅用电视客户端时默认 4K30书房用电脑时默认 1080p60手机上则自动走 720p30。每次位置切换时不用手动调任何参数让访问入口真正变得无感。这个是这个项目现在给我的最大动力。 
长河君 · 2026/10/13 6:16:18 · 阅读 1.2k AnyPS5：把PS5变成任意设备可访问的统一串流入口
平时看别人折腾各种主机外设我自己一直有一个很具体的抱怨主机明明就放在客厅可但凡想在书房、卧室、办公室拿起来玩一会儿就得去搬电视、倒腾 HDMI、或者买一台专门放在旁边的便携屏。折腾一圈下来游戏没玩几分钟人倒是先累了。所以最近做了一个小项目名字就叫 AnyPS5。思路很简单把自己那台 PS5 变成一种“可以被任意设备随时访问”的存在无论手机、平板、电脑、还是浏览器只要能联网就能连接过去。听起来很像远程流式传输方案但实际做下来你会发现它多了一层很有意思的东西一套统一的主机访问入口。这篇内容就是这次折腾的完整记录包括架构思考、编码参数、输入映射、踩过的问题和调试手段希望能给同样在搞主机远程访问、或者想自己做一个小型流媒体控制中枢的朋友一些参考。提示这不是官方功能也不是任何商业产品的拆解纯粹是一个业余项目在某个周末用开源思路拼出来的实验性系统。方案本身图一个“自己用着爽”很多地方会为了便利性牺牲一部分工业级严谨性。1. 项目初衷与目标场景1.1 从“一台主机一块屏”到“一个入口多端随手用”传统游戏主机的逻辑是“一台主机服务一块屏幕”你坐在哪台显示器前游戏就在哪里跑。但在实际生活里人的位置是流动的下午在书房用电脑晚上挪到客厅窝沙发出门前又想在手机上确认一下商店或者收一下每日奖励。如果每一次位置变化都要把主机搬来搬去体验就非常割裂。AnyPS5 的定位就是把“主机访问”这件事从物理连接中解放出来。主机本身不动我另外写了一个轻量级服务端挂在主机所在的局域网里再在前端分别做了 Web 页面、移动客户端和桌面客户端形成一个统一入口。无论你手头是什么设备打开客户端就能看到同一台主机的画面。这样做最大的价值不是“远程玩游戏”这个功能本身而是它把访问成本压缩到了极低不需要专门买采集卡、不需要额外配一台电脑常驻采集画面也不需要转接 HDMI 信号。全部链路只依赖主机本身的网络能力、家用路由器的带宽和一台很普通的服务端设备。1.2 我想解决的三个具体痛点第一个痛点是延迟。很多现成方案都是“画面能看到但操作没法玩”主要损失在采集、编码、网络传输、解码那几段。AnyPS5 从第一天开始就以“能打的延迟预算”为设计目标后面我会单独拆解一次完整的延迟链路。第二个痛点是输入映射。手机、平板没有标准手柄浏览器里的按键、触屏、鼠标到底怎么映射到主机功能是一个非常令人头大的事情。映射做错了用户就会感觉到“按键响应奇怪”“摇杆不跟手”“鼠标转视角跟碰了鬼一样”。第三个痛点是接入成本。很多方案要装专用应用、要内网穿透工具、要做端口转发、要调一堆配置文件。AnyPS5 在设计上尽量做到“扫码即连”局域网内自动发现、配对成功后绝大多数参数自动协商用户打开页面就能看到画面。这三个痛点说实话都不算原创但把它们揉进同一个项目里并且保持“普通人也能搭起来”的克制感是这个项目真正有用的地方。1.3 为什么没有被现成方案直接劝退说实话刚开始正经查了一圈资料之后我也一度觉得没必要自研市面上已经有非常成熟的远程游玩方案和串流工具直接用现成的不好吗但实测下来有几个问题很难绕开官方的玩法面向的是同品牌生态内部对跨设备、跨平台支持不够灵活。通用串流工具普遍适配的是“台式机到台式机”或者“手机到电脑”的场景和主机之间的信息互动做得很浅进不了主机系统级菜单处理不了授权和手柄映射。很多方案是封闭的不能改造协议也就没法加入我想要的“统一入口”和自定义输入层。我自己做 AnyPS5核心不是再去发明一个串流协议而是把传输、编码、输入、鉴权这些模块全部解耦自己掌控每一层。这样后面对接第三方设备、修改延迟策略、新增输入设备时就不用看别人的脸色。2. 整体架构与关键技术决策2.1 总体架构分层AnyPS5 的架构没有做得很复杂主要分成四层接入层负责设备发现、连接鉴权、会话管理对外提供统一 API。控制层负责接收来自不同客户端设备的输入指令并把它们转换成主机可识别的标准输入事件。媒体层负责画面采集、硬件编码、网络传输和客户端解码是整个项目中延迟占比最高的一层。适配层给第三方客户端提供一套尽量简单的 JSON 协议让任何平台都能快速接入。架构上有一个很刻意的选择服务端和管理界面分离。服务端只做媒体转发和桥接管理界面只是其中一个客户端。这样做的原因是我希望同一个服务端可以被多个客户端同时连接典型场景就是“主机开着我用手机先连上看一眼再用电脑接管操作”两个连接在服务端互不干扰。服务端进程 ├── 连接管理器WebSocket UDP socket ├── 输入注入器将标准化按键映射为系统输入 ├── 视频编码管线采集帧 → 硬件编码 → 分片投递 ├── 发现服务局域网广播和回复 └── 会话管理令牌校验、权限控制、心跳监测这里要说明一下我为了避免版权和驱动层面乱七八糟的问题从第一版就明确不做“系统底层篡改”而是用工控级的模拟输入方式把标准化按键事件转译到主机的系统层接口。2.2 通信协议选型为什么不是一味追求“全 UDP”流媒体场景里很多人第一反应就是“必须用 UDPTCP 延迟高重传会粘滞”。这个判断在互联网长距离开放网络环境下是对的但在局域网范围内未必全对。AnyPS5 第一版直接上了 WebSocket over TCP 做视频传输理由如下局域网内丢包率极低TCP 的拥塞控制不会频繁触发。WebSocket 天然支持双向消息握手、鉴权、输入指令和视频帧可以共用同一个连接简化开发量。主流浏览器和移动客户端都原生支持 WebSocket不需要额外安装驱动。TCP 重传带来的风险我做了两层防护一层是强制开启 NO_DELAY 降低小包延迟另一层是主动丢帧策略。编码器产出的关键帧和普通帧分标记一旦发送队列积压超过阈值就把未来的普通帧丢弃只保留关键帧。等做到了跨公网版本我确实又补了一条 UDP 通道做视频流的低延迟传输控制命令仍走 WebSocket视频码流走专门的 UDP 通道这样兼顾了可靠性和低延迟。2.3 编码参数怎么定一个从带宽倒推的计算过程远程串流表现好不好很大程度上在编码参数上就已经决定了。官方串流工具的很多参数是固定给主机内部记录的第三方很难摸到所以 AnyPS5 的编码参数完全是自己控制的。我做了一次最基础的带宽预算假定家里上行带宽是 50 Mbps考虑到其他设备占用串流最多能分到约 80% 的上行能力也就是 40 Mbps。流媒体编码一个常见的经验值是1080p60 下H.264 编码器想要画面细节和流畅度达到可观的水平推荐码率约等于 8~12 Mbps。如果上到 4K30则至少需要 20~30 Mbps。于是做了一个简单的分级表客户端屏幕能力编码分辨率目标帧率码率范围手机竖屏960x54030fps2.5~4 Mbps手机横屏1280x72030fps4~6 Mbps平板/电脑窗口1920x108060fps8~12 Mbps电视/全屏2560x144060fps16~24 Mbps极限模式3840x216030fps24~32 Mbps我最后默认采用 1080p60 档位码率控制在 10 Mbps再叠加 1 秒缓冲池。为什么不是 4K60因为延迟预算受不了。编码器的复杂度跟像素总量强相关像素从 1080p 涨到 4K编码耗时基本是非线性增长而回到串流这种互动场景画质提升一截、延迟翻一倍综合体验反而降级。编码参数在视频编码器里的具体配置是这样调整的编码器选择优先硬件编码器不支持再回退软件编码器。编码档位选了更偏向低延迟的档位关掉 B 帧让解码端不用等重排。关键帧间隔设成 2 秒一次强制关键帧也就是每 120 帧至少有一个 I 帧便于客户端在切流、花屏时快速恢复。参考帧数限制在 1~2 个参考帧减少参照依赖。这样算下来整体链路延迟被压在可接受范围内。2.4 安全鉴权简单但不等于裸奔因为它本质上是把主机“暴露”在网络上所以安全鉴权我专门花了一个下午认真对待。AnyPS5 的服务端不采用“所有人连上就放行”的默认模式连接必须经过两个阶段第一阶段是配对。首次连接时服务端生成一组一次性配对码客户端在页面上输入配对码服务端通过零知识验证方案完成握手。这样即使监听网络流量别人也拿不到可以冒充的密钥。第二阶段是会话令牌。配对验证之后服务端颁发一段有效期 30 分钟的会话令牌后续所有 WebSocket 请求都携带令牌。令牌过期后会自动刷新不需要用户重新配对。整个链路强制加密局域网内不做裸流传输因为很多现代设备的系统级媒体管线会默认拒绝明文流。注意配对码只在首次设置时需要之后设备会进入“已信任设备”列表。如果你把客户端给一个陌生人用记得在管理界面里把该设备删除否则对方仍能在一段时间内自动重连。3. 核心模块实现细节3.1 设备发现模块让用户少填 IP对一个家用工具来说让用户手填 IP 地址已经算一种失败体验。AnyPS5 的设备发现我采用“局域网广播 服务注册”双通道服务端启动时向局域网内发送 UDP 广播包声明自己的能力。客户端启动时向局域网发送查询请求服务端收到后直接应答自己的地址和端口。如果广播被路由策略挡住还支持用户手动输入主机别名由某个轻量级注册中心提供解析。从可用性角度看广播发现至少要支持同一网段内的自动识别。实际开发中有个坑部分无线路由器默认开启“AP 隔离”设备之间不能互相广播。这种情况下我用了第三个保底通道通过云端的协调服务器做了单向信令穿透。客户端登录之后服务端所在网络主动连接到协调服务器客户端通过同一个协调服务器的会话表找到服务端不需要用户去改路由设置。3.2 视频流模块采集、编码、推流的三个阶段视频采集在 PC 上其实有多种方式我选了兼容性最好的桌面捕获接口原因是用它可以拿到未压缩的原始帧。采集逻辑不要求满帧率抓取而是按目标帧率均匀抓取比如 60fps 就每 16ms 抓一次减少无用帧对 CPU 的压力。采集到的原始帧直接送编码器。为了降低延迟我没有用典型的环形缓冲队列而是让采集线程和编码线程共享一块双缓冲内存。采集线程填满 buffer A 时编码线程处理 buffer B两个线程交替工作避免互相等待。编码完成之后媒体层按 32KB 最大分片切分每片带着递增序号和时间戳发送到客户端。客户端的解码策略也很重要。我没有选择“等攒满一帧再渲染”而是收到关键帧后立刻解码并在下一条关键帧到来前持续渲染收到的普通帧。这样做的代价是有可能显示几帧花屏但换来的是帧率更稳定、延迟更可控。3.3 输入注入与动作映射模块这是整个项目里最考验细节的模块。不同客户端设备的输入方式完全不同手机屏幕左右两侧分别画虚拟摇杆和按键区。平板可以是触屏也可以外接蓝牙手柄。电脑优先读取键盘鼠标也支持接入标准手柄。浏览器必须先从浏览器安全策略允许的范围里拿到用户操作事件。AnyPS5 的做法是先把所有输入统一成“抽象输入事件”比如LEFT_SHOULDER、MOVE_STICK_LEFT、PRESS_CROSS再由输入注入器根据当前主机的系统设置把这些抽象事件映射成最终按键。这里有一个很关键的点抽象层负责逻辑映射层负责适配。比如一个动作游戏玩家习惯“X 键跳跃”但另一个赛车游戏中“X 键是刹车”同一个抽象按键到最终系统键的关系其实是可配置的。我默认提供两套预设映射“经典模式”摇杆控制移动面部按键控制动作肩键控制视角。“灵敏模式”把右摇杆映射为鼠标指针适合在系统界面和浏览菜单时使用。映射配置存在 JSON 文件里用户可以自己改改完即时生效不需要重启服务端。我在实际测试中发现最大的问题反而不是按键映射本身而是“按键冲突检测”。比如手机端的虚拟摇杆和键盘方向键同时输入如果映射层不及时处理主机会收到两个互相矛盾的移动信号表现就是角色原地抽搐。我在映射模块里加了一个优先级判定后到达的输入事件拥有更高优先级同时将前一个输入方向按 3 帧的时间窗口平滑释放。3.4 对外 API 设计给第三方客户端留一条路很多此类项目只做“自己家的 App”把接口全部锁住。AnyPS5 我坚持提供一个极简的 JSON 控制协议原因很实际我自用的前端不一定覆盖所有平台的细节与其把每个平台都写出原生应用不如做一个协议让任何人可以快速接入。接口设计上坚持三个原则一是每个端点都是无状态请求客户端自己管理上下文二是返回结构统一为{code, message, data}前端处理起来非常一致三是所有长连接都走同一个状态机连接状态、会话状态、播放状态各自独立又可以互相查询。拿“开始串流”这个动作举例子客户端发起的不是一条指令而是三条查询主机当前状态待机/运行中/繁忙。请求建立会话并申请视频参数。建立媒体通道并上报客户端能力。这样分层是为了避免热闹半天才发现主机已经有不少用户占用了。4. 从零到能用的实操过程4.1 开发环境与依赖工具开发 AnyPS5 的实验环境很简单一台普通家用台式机当作服务端。一台解码能力还行的手机、一台平板、一台老 Windows 笔记本当作客户端。路由器沿用家里原有的普通家用款式没做任何特殊配置。服务端开发语言我选了 Rust主要图编译产物干净、并发处理靠谱尤其是我这种要用多线程处理采集和编码的场景。客户端这里用浏览器优先因为调试最方便手机 App 只是用浏览器内核简单封装了一层以便支持全屏和自动旋转。依赖的组件基本是开源生态里非常常见的几个库这里不具体点名了建议新手直接用官方文档案例跑一遍不要从零造编码器。4.2 拿到手柄输入事件的关键步骤要让远程端操作本地主机第一步就是本地能收到输入事件。Windows 平台上游戏手柄的事件读取有两条路一是标准输入子系统二是使用全局钩子监听硬件消息。AnyPS5 没有采用全局钩子方案原因是它会在某些安全软件下被拦截而且和多用户桌面会话混在一起会出现状态混乱。实操中我主要做这样几件事枚举当前连接的输入设备拿到设备 ID 和设备类型。持续读取设备状态每 10ms 一次避免同一按键被重复触发。对读取到的原始数据做差值处理只有状态发生变化时才生成一条标准化事件。将这些事件交给抽象输入层由输入注入器转译为主机的输入 API 调用。踩坑经验是很多主机上的输入 API 对“短促低频可信”的要求比普通 PC 上严格得多。模拟输入发送太频繁或者时间间隔不均匀会导致主机自动判定为“无效信号”并直接忽略。最终我是按“下载频率 125Hz、每次发送间隔 8ms 固定节拍器”来实现的效果才稳定下来。4.3 建立加密通道与分布式配对加密通道在局域网内看似不必要但跨公网连接时就是刚需。我采用的方法是在 WebSocket 握手完成后立即通过 TLS 的加密层继续传递验证消息生成两种不同的会话身份控制身份用于接收来自客户端 UI 的常规指令。媒体身份仅用于视频流通道权限只包含接收画面和提供输入事件。两个身份分离好处是即使媒体身份被截获别人也无法通过它控制主机的系统菜单。配对流程做成四步服务端生成一次性配对码以二维码或文本形式呈现。客户端输入配对码发送。服务端用配对码签名后返回一个加密过的初始化向量。客户端使用该向量启动会话之后的连接全部使用会话级密钥。有一点需要注意的是配对码有效期我设成了 5 分钟过期作废必须在服务端上重新生成。这样做主要是防止配对码长期有效导致弱口令风险。4.4 自适应码率的实现思路自适应码率是串流系统里非常影响体验的一环网络稍有波动如果不调整码率就会出现长时间花屏。AnyPS5 的码率调整逻辑不复杂但效果还比较稳。它在服务端维护了一个滑动窗口记录最近 1 秒内发送队列的积压字节数、实际发送速率、丢包判断和客户端反馈的渲染帧率。每个 500ms 做一次决策如果队列积压持续增长就下调码率一个档位例如从 12 Mbps 降到 9 Mbps。如果积压清零且吞吐量有余量就每隔 3 次采样上调一个档位。如果出现丢包直接下调到最低档位并尽快补发关键帧。初期出现的问题是我把调整窗口定得太短结果网络稍微抖一下就反复上下调档画面一会儿清晰一会儿模糊体验反而更差。后来加入“稳定系数”——必须连续 3 个采样周期都满足条件才调整情况才稳定下来。4.5 最小可用版本与验证清单如果你也想复刻类似的小项目下面的清单可以作为你的“能用了”标准手机和电脑能自动发现同一局域网内的服务端。配对后服务端返回主机状态状态与真实系统一致。远程画面延迟在局域网环境下低于 80ms公网前提下低于 160ms。手柄、触屏、键盘三种输入都能完成 360 度转视角和按键响应。网络抖动时画面从清晰变成模糊但不卡死的流程能自动恢复。服务端断开崩溃后所有客户端能自动回到待机界面且不会卡死。配对码过期、删除设备、刷新令牌这三件事在页面上能操作。如果以上七条都通过说明核心链路已经通了后面做功能增强就只是锦上添花。5. 常见问题与排查记录5.1 延迟高、卡顿和画面模糊这是最容易被感知的一类问题也最容易误判。先说结论延迟高的原因大概率不是网络带宽不够而是排队缓冲。排查方法按顺序做先看延迟是不是恒定偏高区间在哪个范围。打开服务端的发送队列长度指标看积压是否持续存在。用抓包工具看一下是否大量 TCP 重复 ACK如果很多说明网线或无线链路本身有大量丢包。检查客户端是否开了“省电模式”很多手机后台会限制网络吞吐然后直接表现为画面卡顿。我遇到的一个典型问题是无线网络下表现很好但换到有线反而出现卡顿排查后发现是有线网卡驱动里的巨型帧协商异常。解决办法是把网卡速度固定到 1Gbps 而不是自动协商症状立刻消失。这种问题从应用层看完全无解只能从链路层破。5.2 输入失效、按键重复、摇杆漂移输入问题我踩的坑最多。首当其冲的是“按键重复”客户端按住一个键不松手经过去抖动处理后事件被发送了两次主机端收到了两次按下而没有收到抬起角色就一直跑。解决方案是引入一个“按下/抬起状态机”每个按键同一时刻只能有一种状态重复的按下消息直接丢弃。摇杆漂移通常是两个原因一是客户端触控区域计算偏差比如虚拟摇杆没有归零就发送了后续偏移二是服务端输入映射器的阈值没有设置死区。我给摇杆加了 15% 中心死区还把最小偏移量限制为 1%这样即使手指轻微抖动也不会传导到主机端。另外如果你的鼠标转视角很“滑”大概率是因为鼠标相对位移和主机的视角控制曲线不一致。我这里不想过度展开只说结论宁可把灵敏度调低一点也不要让视角加速度曲线重复计算。5.3 设备找不到、连接不上、反复掉线局域网设备发现失败第一件事就是检查路由器的“AP 隔离”开关第二件事是确认防火墙有没有拦截 UDP 广播包。比较坑的是很多安全软件默认拦截“局域网程序访问网络”导致广播包发不出去。连接不上还有一个隐蔽原因服务端的主机不支持同一时间多个用户会话。AnyPS5 默认最多允许两个并发连接一个用于控制、一个用于媒体超出就会拒绝。如果多台设备同时争抢后面启动的客户端就会显示连接失败。反复掉线的问题我最后定位到是会话密钥的刷新机制某些客户端实现里WebSocket 重连时只重新建立传输层却没有重新完成密钥协商结果服务端就拒绝新通道。修正方式很简单每次重连都必须重新走一遍“控制身份验证媒体身份申请”不能复用旧密钥。5.4 CPU 占用过高与内存泄漏CPU 占用高大概率落在编码器选择上。软件编码器在 1080p60 下能让你看见 CPU 占用直接拉满所以有条件一定要优先走硬件编码器。当然如果你用的采集源本身是 4K那在缩放阶段就会造成 CPU 压力我在媒体层把采集分辨率限制在目标分辨率再送编码器避免多余缩放。内存泄漏的排查思路是这样的先打开内存曲线观察持续增长再用排除法逐模块禁用最终定位到视频帧的引用计数赋值错误。原因是多线程共享帧数据时忘记及时释放上一帧引用导致积压。我的项目里最终用 Arc 引用计数配合帧池化解决代码逻辑复杂一些但现在长时间开机内存曲线很平稳。6. 一点后续扩展思路AnyPS5 目前对我来说已经是一个足够稳定的常用工具。如果你看完也想在自己家里搭一套类似的访问入口我有几个很具体的建议不要一开始就做多平台客户端直接用浏览器验证核心链路省掉大量适配工作。输入映射模块一定是先做再考虑视频优化否则你根本没法在手机上完成一次调参操作。一定要把状态机设计得足够清晰尤其是会话状态否则后续加“待机唤醒”“自动休眠”“多用户切换”时会被各种竞态条件折磨疯。让一台主机同时服务多个场景这件事做起来确实比想象中琐碎。但只要第一个能用的版本跑通后面每一次优化你都会明显感觉到收益。我个人更期待下一步给 AnyPS5 加上“按房间自动切换参数配置”的能力在同一个家里客厅用电视客户端时默认 4K30书房用电脑时默认 1080p60手机上则自动走 720p30。每次位置切换时不用手动调任何参数让访问入口真正变得无感。这个是这个项目现在给我的最大动力。