AnyPS5：从零实现PS5远程串流到任意设备

做 AnyPS5 这个项目的起因，说起来其实特别没排面：客厅电视被家里人占着追剧，书房显示器又被我拿来剪视频，PS5 想玩的时候只能来回搬。后来我试过把主机挪到书房，用串流方式在客厅平板上玩，发现官方那套串流客户端支持的设备名单卡得很死，我的 Linux 笔记本、旧 Windows 平板、还有一台安卓电视盒子全部不在名单里。与其等官方适配，不如自己动手做一个通用的客户端，把 PS5 的画面和手柄输入，通过串流协议接到任何能联网的设备上，这就是 AnyPS5。

这个项目解决的核心问题很直接：一台 PS5 主机，想在家里各个屏幕、甚至在外地的设备上继续玩。适合的人群也明确——有多设备游玩需求、想把 PS5 串流到非官方支持平台的玩家，以及单纯想研究串流技术原理的开发者。整个项目做下来，核心链路其实就四块：视频流接收与解码、输入指令回传、网络连接管理、界面与设备适配。这篇文章我把每一块的思路、实现细节和踩过的坑都摊开来讲，能帮你少走不少弯路。

1. 项目起点：需求拆解与方案选型

1.1 需求到底要解决什么

先别急着写代码，把需求拆清楚。我最初列的需求只有一条：在任意设备上实现 PS5 的远程画面显示和手柄控制。但“任意设备”这四个字拆开来看就麻烦了——设备之间的差异包括操作系统、屏幕分辨率、解码能力、网络环境、输入方式。如果每一个都单独适配，工作量是无限大的。

所以我把需求重新抽象成三层：

• 画面层：在任意设备上稳定解码并显示视频流
• 输入层：把设备上的按键、触摸、鼠标事件转换为手柄指令回传给主机
• 连接层：处理设备发现、握手、保活与网络穿透

抽象完之后，方案选型就有了方向。我对比过三条路线：一是等官方应用适配，二是用现成的第三方客户端，但不少都不开源也没法改；三是自己基于公开的协议信息写客户端。第三条路线虽然前期工作量大，但收益最明确——所有层都握在自己手里，想支持什么设备就支持什么设备。

1.2 为什么选择直接对接串流协议而不是另起炉灶

有人可能会问，直接接 HDMI 采集卡再转 RTMP 不也一样吗？确实，HDMI 采集卡方案在我的调查范围内也考虑过，它有个优点是不用碰主机的系统接口，任意游戏都能捕获画面。但缺点也很致命：采集卡需要额外硬件成本，而且采集到的画面走 HDMI 是固定刷新率的，中间再加工一遍，延迟会多出 20-30 毫秒；更麻烦的是，HDMI 采集方案没法回传手柄指令，手柄还是要接在主机上，这在异地场景下完全不可用。

所以最终我选择直接对接主机内置的串流协议。这套协议本身就是为主机远程游玩设计的，视频流、音频流、输入回传通道都是现成的，还自带码率自适应和低延迟模式。我要做的，就是把它“翻译”到不同设备上。这里需要说明，所有协议细节都不是官方公开文档给出来的，而是社区通过长期的抓包分析逐步验证还原的，我在实现时也遵循了公开流传的协议约定。

1.3 技术栈与整体架构

整个项目的架构分五层：

选这些方案不是拍脑袋：界面层用 Web 前端套原生壳，是为了让同一套 UI 跑在 Windows、Linux、安卓上而不需要写三份；视频解码优先走各平台的硬件解码 API，因为纯软件解码在 1080p 60fps 的码率下 CPU 会直接吃满，发热和掉帧都受不了；会话层单独拆出来是因为串流的握手和视频传输是两个通道，一个断了一个不影响另一个的报错排查。

这样一个分层设计带来的直接好处是，每个层可以独立替换。比如后来我换了新的解码方案，只需要改视频层，其他层完全不动。后续如果要做触屏优化或者增加新的输入方式，也只动输入层，犯不着把整个项目推倒重来。

2. 核心链路：视频流的接收与解码

2.1 串流数据是怎么组织起来的

整个视频链路从抓包分析看，主机不会像普通无线投屏那样直接发一坨裸的 H.264 流出来，而是把视频数据切成了一个个小的网络包，每个包都带序号和时间戳。客户端要先把这些包按序号重组，去掉包头，还原出完整的视频帧，再交给解码器。

这个过程很像快递分拣：货物被拆散装进不同包裹，到达站点后要按单号顺序重新拼起来。如果某个包丢了或者迟到了，你不能停下来等它，而是要把它标记为缺失帧，继续处理后面的包。所以我在客户端里维护了一个滑动窗口缓存，窗口大小是 200 毫秒左右的视频数据，超过这个时间还没凑齐的帧直接丢弃并提交解码器，用丢帧来换取整体流畅度。

这里有个细节很多人会忽略：主机端是以 60 帧的节奏发包的，但网络抖动会让包到达时间变得非常不均匀。如果客户端收到一帧就立刻解一帧，画面节奏会一顿一顿的。正确做法是在解码器前面加一个音视频同步队列，靠音频时钟作为基准，视频帧按照时间戳对齐到音频时间轴上，这样哪怕网络抖动，人耳听到的和眼睛看到的依然是同步的。

2.2 解码器的选择与硬件加速

解码是整个链路里最吃性能的环节。我先说结论：只要设备支持，就必须用硬件解码，不要碰纯软件解码器。同样是 1080p 60fps 的流，纯 CPU 解码在我的测试机上占用率接近 70%，解码延迟还不稳定；切到硬件解码之后，CPU 占用直接降到 10% 以内，延迟也稳定在 8-12 毫秒。

平台差异这块我分开处理：

• Windows 上优先用系统自带的媒体基础框架，它对 H.264 和 H.265 都有硬件加速支持，不用额外装解码器
• Linux 上情况复杂一些，我最后选了基于 V4L2 的硬件解码路径，配合通用的图形驱动接口，实测下来主流核显都能稳定工作，但部分独显在旧驱动上有兼容问题
• Android 上用系统解码器，这个平台相对省心，因为解码器是强制的

判断设备是否支持硬件解码，我写了一个小工具，用 ffprobe 这类工具去检查设备的解码能力列表。这里有一个小技巧：多数硬件解码器对分辨率和帧率有上限，一旦输入超过它的能力范围，解码就会失败或者掉到软件解码。所以客户端在握手之后拿到主机输出的分辨率参数时，会先跟设备能力比对，再决定是直连解码还是先降分辨率。

2.3 帧率与分辨率的动态适配

主机端的编码器支持多档分辨率和帧率，从 720p 30 帧到 1080p 60 帧都有。客户端在第一次连接时会协商一个基准档位，但网络情况是变化的，所以还需要动态降级。

我实现的逻辑很简单：每隔 10 秒统计一次解码丢帧率和网络往返时延，如果丢帧率超过 2%，就把协商档位降一档；如果连续 30 秒都表现稳定，再尝试升一档。这个逻辑看起来简单，但实际调参时踩过坑——刚降档之后的一段时间里网络指标会很好看，系统马上就升回去，然后又开始丢帧，形成抖动循环。最后我加了一个限制：升档之后至少保持 3 分钟稳定才允许继续升档，降档则没有这个限制，随时可以降。

补一句关于画面设置的取舍：同等码率下，我宁可保留 1080p 但把帧率降到 45，也不要 720p 60 帧。因为动作类游戏对流畅度敏感，但串流场景下分辨率太低会让文字和界面细节糊得没法看。这个偏好不一定适合所有游戏类型，你可以自己调整。

3. 输入回传：从手柄到主机的最短路径

3.1 输入通道的建立

很多人都只关注画面串流，忽略了输入回传，但游戏体验恰恰卡在这条链路上。AnyPS5 的输入通道用的是单独的 UDP 连接，和视频通道互相独立。这样做的好处是：即使视频通道因为网络拥塞在降码率、丢帧，输入指令依然能以最高优先级、最小延迟发出去。

输入包的格式很简单：一个包头加上手柄摇杆、按键的状态数据。摇杆是 16 位的模拟量，按键是 8 位的位图。客户端每 5 毫秒采样一次输入状态并打包发送，主机端收到之后做一次线性插值，让摇杆的细微动作也能被模拟出来。

这里有个细节值得说：很多人以为串流游戏时手柄延迟来自网络，其实在现代家庭网络下，局域网内的单程延迟通常只有 1-3 毫秒，真正的大头是输入采样间隔、系统输入队列缓冲和显示延迟。所以我在输入层用了一个实时线程来做采样，并且把采样周期从系统默认的 8 毫秒缩短到 5 毫秒，实测手柄摇杆的循迹感明显跟手。

3.2 按键映射与振动反馈

设备上如果没有手柄，键鼠和触屏也能玩，但映射逻辑要费点心思。我的思路是：给每个虚拟按键提供一个映射表，玩家可以在 UI 上自定义。比如经典的“鼠标移动对应右摇杆，鼠标滚轮对应十字键”就是一套预设。触屏设备则直接套用官方触控板形态的虚拟手柄布局，左半边是虚拟摇杆，右半边是动作按键区。

振动反馈这块容易被忽略。官方串流协议里是包含手柄马达状态数据的，客户端解析出来之后，在设备端通过系统振动接口模拟震动。手机和平板都有线性马达，可以用；电脑上没有振动硬件，我就把它忽略掉了，但不影响整体流程。需要特别提醒的是，不同设备的振动接口参数差异很大，一定要做好容错，不然出现“设备不支持振动就崩掉”这种低级问题就尴尬了。

3.3 延迟控制的几个关键参数

关于延迟，我整理了一张表，按影响从大到小排列：

前四项里，影响最大的其实是网络抖动缓冲。我最初是把缓冲时间固定在 100 毫秒，结果在局域网内白白多出 100 毫秒的延迟，玩射击游戏能明显感到视角转动滞后。后来改成动态缓冲：平时保持在 30-50 毫秒，遇到丢包时最多扩展到 150 毫秒，网络恢复后再慢慢收回来。这样一个简单的改动，实际手感提升非常明显。

提示：如果只是在同一台路由器下局域网串流，抖动缓冲建议调低到 30 毫秒；如果是跨公网访问，就要适当放宽到 80 毫秒以上，否则会触发频繁丢帧。

4. 网络准备：穿透、握手与连接保活

4.1 局域网直连与公网访问的区别

串流场景分两种：局域网直连和跨公网访问。局域网直连最简单，只需要同一网段、能互相通信就行；跨公网访问则是这个项目里最折磨人的部分。

公网串流要解决两件事：一是找到主机在公网上的地址，二是让数据包能穿透主机的网络地址转换。找地址不难，可以由客户端发起会话请求，主机端通过云端信令把当前的公网 IP 和端口回报给客户端。真正的难点是穿透，因为不同路由器的网络地址转换实现差异很大，有些路由器对 UDP 映射规则很宽松，有些则极其保守。

4.2 端口配置与穿透策略

我在实现中采用的策略是“尽力穿透，不行就中继”。所谓穿透，就是客户端和主机都主动向对方的公网地址发 UDP 包，让两边的路由器同时建立映射记录。这个技巧在经典联网游戏里很常见，成功率取决于两端路由器是否属于“宽松型”网络地址转换。实测下来，家庭宽带下成功概率大约六成。

如果穿透失败，就退回中继转发。中继服务器只做数据转发，不碰任何业务逻辑，带宽要求其实不高——串流的单路视频流码率是 8-15 Mbps，一台千兆带宽的服务器可以中继几十路。为了降低中继延迟，中继服务器要部署在离玩家尽可能近的位置，实测中继路径的额外延迟在 30-50 毫秒之间，属于可以接受的范围。

另外，主机上有两个端口参与通信：一个是会话控制端口，一个是视频数据端口。如果玩家希望固定路由器的端口映射做直连，需要把这两个端口都放行。判断端口通不通，我用了一个很简单的方法：客户端先发一个探测包，然后看主机的响应是否在 3 秒内回来，同时比对返回包的源地址，防止是路由器伪造的应答。

4.3 码率自适应与网络抖动处理

码率自适应是整个串流体验是否平滑的关键。我在视频通道里做了一层拥塞控制：客户端每 200 毫秒上报一次接收统计（实际码率、丢包率、往返时延），主机端根据这些数据动态调整编码码率和分辨率。

这套逻辑参考了通用的拥塞控制思想，但没有做得那么复杂。我的规则是三条：

1. 丢包率低于 0.5% 时，认为网络富余，逐步上调码率
2. 丢包率在 0.5% 到 2% 之间，保持当前码率不变，只加大冗余纠错
3. 丢包率超过 2%，立刻降码率，并且把帧率同步降一档

冗余纠错这一条值得展开。串流视频的 H.264 流本身对丢包非常敏感，一个关键帧丢包就会导致画面花屏好几秒。我在视频包里加了冗余编码，同一段数据发 1.5 倍规模的包，多出来的部分用于恢复丢失的包。在弱网环境下，这个策略能显著减少花屏次数，但代价是实际网络消耗变大了，所以只有在丢包超过阈值时才开启。

5. 实操配置与体验调优

5.1 服务端配置建议

拿最常用的场景举例：一台 PS5 接有线网络，客户端设备接同一个路由器的 Wi-Fi。为了最佳体验，我有几条配置建议：

• 主机尽量用有线网络。主机的 Wi-Fi 模块在近距离时表现还行，但穿墙和隔层情况下，延迟波动明显加剧
• 客户端设备尽量用 5GHz Wi-Fi，避开 2.4GHz 频段。2.4GHz 干扰源太多，实测串流时频繁出现瞬时丢包
• 如果路由器支持 QoS，把串流设备的 UDP 流量设为高优先级，能避免其他设备下载时抢占带宽

这几条听起来都是老生常谈，但真正影响串流体验的往往就是这些基础项。我见过有人折腾半天参数设置，最后发现是客户端连了 2.4GHz Wi-Fi，信号满格但延迟忽高忽低，切到 5GHz 之后一切正常。

5.2 客户端参数推荐

进入客户端设置页，有几个参数值得按设备调整：

这些参数按我上面的表格配下来，大部分设备都能在局域网内达到接近本机游玩的体验。我自己实测，PC 端在 1080p 60 帧、码率 15 Mbps 的设定下，体感延迟大约在 20-30 毫秒，眼睛基本感知不到。公网环境下则要看上行带宽，通常建议把码率压到 10 Mbps 以下，优先保证操作响应。

5.3 不同设备的实测表现

我把家里能连网的设备都试了一圈，结果挺有意思：

• Windows PC：表现最好，解码快、输入准，唯一要注意的是全屏独占模式要在显卡驱动里开启“无边框全屏”或者“独占全屏”，否则延迟会高 15 毫秒左右
• Linux 台式机：能玩，但解码器兼容性是个大坑，部分独显在旧驱动上有花屏问题，更新驱动后解决
• 安卓平板：体验出乎意料地好，触屏虚拟手柄在玩动作游戏时还算跟手，只是长时间玩拇指容易酸
• 安卓电视盒子：连接成功，但解码器性能参差不齐，老盒子上 1080p 会掉帧，只能降到 720p 使用

以上测试结果基于我自己的设备和网络环境，仅供参考，不同设备的实际表现差异很大。如果某个设备的情况和我的不一致，优先看设备的解码能力和网络连接方式，这两个变量基本决定了串流体验的下限。

6. 常见问题与排查实录

6.1 问题速查表

把我在开发和使用过程中遇到的典型问题整理成一张表，方便排查：

6.2 排查思路

遇到问题先别急着改参数，我的排查顺序是：先看网络层，再看解码层，最后看输入层。

网络层最快的方法是看客户端上报的丢包率和往返时延。如果丢包率高于 2%，问题基本就在网络这边，优先检查 Wi-Fi 信号强度和路由器拥堵。解码层的问题最好识别——如果画面卡顿但网络指标一切正常，十有八九是解码器性能不够或者缓冲设置不对。输入层的问题一般表现为指令延迟高但画面流畅，这时要检查输入线程是否被系统调度打断了。

这里我要特别分享一个排查经验：很多“连接不上”的问题，最后发现都是路由器的防火墙默认拦截了 UDP 流量。这是因为普通上网用的 TCP 流量路由器默认放行，而 UDP 在不少路由器上默认策略是丢弃。排查时可以先把路由器的防火墙临时关闭试一下，如果问题消失，就说明是防火墙策略问题，再去细化规则。

6.3 避坑心得

最后写几条我在反复踩坑后总结的心得。

第一，不要在客户端侧做“丢帧等待”。我最早实现的时候，发现某一帧丢了就阻塞解码器等待重传，结果整个画面跟着卡顿，后来改成直接丢帧跳过，流畅度立刻恢复。

第二，输入线程的实时性优先级要处理好。在 Windows 上如果输入线程被其他高负载程序抢占，手柄响应会出现肉眼可见的“一卡一卡”现象，可以把线程优先级设置为实时级，但要注意系统负载过高时可能导致整个系统卡死，需要做降级保护。

第三，音频时钟是所有同步的基准。这句话我反复强调过，但还是要再说一次：如果音频和视频各自用自己的时钟去同步，音画迟早会错位。以音频时间为准，视频帧按时间戳对齐，是串流项目里最稳的做法。

第四，不要忽略温度。长时间串流时，主机和客户端设备都会高负载运行。我的主机是放在封闭电视柜里的，连续玩两个小时后出现过一次画面掉帧加重，后来把柜门打开通风才恢复正常。设备摆放对稳定性的影响，比很多人想象中大得多。

我个人在实际操作中的体会是，AnyPS5 这个项目核心不算复杂，但非常考验耐心。如果你也打算做类似的事，我的建议是先把视频解码和输入回传这两条主链路跑通，再考虑界面和扩展功能。参数没有标准答案，我上面给的数值可以作为起点，但一定要结合自己设备的实测结果去调。串流这条路，最忌凭空想象，最靠谱的就是一遍遍实测、记录、再修正。