AnyPS5实战：从HDMI采集到局域网低延迟串流

说实话最早想做AnyPS5这个项目纯粹是被自己客厅和书房之间的距离逼出来的。电视长期被家里人占着PS5放在电视柜边想玩一会儿只能趁大家都不看的那个时间点而卧室里的笔记本、客厅角落的旧平板全都闲着。你一定也想过这个问题同一台PS5能不能让画面出现在我手边任意一块屏幕上这个想法本身不新鲜但真正动手做一套“从HDMI采集到局域网分发的低延迟串流环境”并且把它调成可以日常玩游戏的状态是我在AnyPS5上花了不少心思才完成的事。这篇文章就围绕AnyPS5这个项目来写。它不是商业产品和复杂框架的说明书而是一个个人项目从选型、搭架构、填坑到调优的完整复盘。如果你手里也有一台主机想在不换电视、不搬机器的前提下把游戏画面送进书房、卧室或者任何一块屏幕上我的这套思路和实测经验应该能给你不少参考。下面我按一条清晰的推进线来拆先讲为什么我要自建而不是用现成方案再讲系统架构然后是我们的服务端实测参数、客户端适配最后是那些最容易让人摔键盘的隐形坑。1. AnyPS5要解决的真实痛点客厅主机与房间之间的“一块屏”1.1 为什么我决定自己造串流系统先说清楚我的使用场景。PS5放在客厅但我大部分游戏时间集中在晚上客厅的电视在那个时间段基本归属于家人。我有两个选择要么把主机搬到书房每次拔线、搬机器、再接上麻烦得不行要么想办法让书房里的笔记本、床头柜上的平板也能收到主机的画面。一开始我也想过用现成的远程游玩方案。但我试用下来有几个问题非常明显第一官方方案走的是公网账号验证链路局域网内虽然也能跑但整个流程依赖官方服务器的状态偶尔抽风一次你就得重新登录第二它的客户端形态是固定的我想在浏览器里打开、想在旧平板上解码、想自己控制码率和延迟缓冲这些需求它给不了那么多自由度第三如果你挂代理或者网络环境本身比较乱这类远程方案的稳定性会直线下降。我想要的是一个完全由我自己控制的局域网内闭环系统——采集、编码、传输、解码每个环节都在我手里出问题时我能看到是哪一环掉的链子。于是AnyPS5这个项目就立项了。目标非常具体通过HDMI采集卡拿到PS5的画面信号在服务端完成编码再用自定义的局域网传输协议分发到手机、平板、笔记本和电视盒子等不同客户端端到端延迟控制在可玩的范围以内同时保证画质在运动场景下不掉链子。1.2 先选型采集卡方案 vs 纯软件方案动手之前我做过一轮方案对比。PS5本身就支持网络串流但那个属于“受平台限制”的链路我没有采用。我的备选方案主要有两条一是纯软件装采集推流工具直接用电脑接收HDMI画面再转发到局域网二是自己写服务端和客户端协议完全定制化。这两者的核心区别在于控制粒度。纯软件方案好处是上手快配置一下就能用坏处是你拿不到传输协议层面的定制权限尤其是“多设备同时接入时的带宽分配”“关键帧间隔控制”“弱网环境下的优先级策略”这些细节现成方案基本不会给你暴露出来。而我既然要做的是“Any”设备都能连的项目就必然要自己决定这些策略。硬件上也有些讲究。采集卡我选择的是USB 3.0接口的免驱HDMI采集卡UVC标准插上就能被系统识别。为什么不用内置PCIe采集卡因为我的服务端有时跑在笔记本上有时跑在小型迷你主机上USB方案的移动性更好哪台机器空闲就插到哪台。实际用下来只要接口带宽足够USB 3.0采集卡和内置卡在延迟上的差距在游戏场景里几乎感知不到。为了把这个选型逻辑说透我做了张对比表项目纯软件推流方案AnyPS5自研方案上手速度快装好就能用较慢需要自己写服务端协议定制能力低高码率、关键帧、重传策略均可控多设备接入能接但带宽分配固定可按设备类型动态分配延迟调优靠软件内部参数每一环都能单独测量和调节调试排障黑盒白盒问题出在哪里一眼能定位选型最后落在自研方案上还有一个原因我希望以后能加更多功能比如双屏联动、状态面板、游戏内截图自动推送。这些依赖底层传输协议的能力自己掌握协议之后实现起来会顺手很多。2. 系统架构与核心模块拆解2.1 整体链路从HDMI到屏幕这部分是整个项目的地基。我的系统链路看起来是下面这样游戏主机 - HDMI线 - 采集卡 - 服务端接收原始画面 - H.264编码 - 局域网UDP发送 - 各客户端解码显示听起来很简单但每个环节都有细节。采集卡拿到的是什么如果你用一张普通的高清采集卡它通过UVC协议传给服务端的通常是未压缩的YUV帧或者MJPEG帧。未压缩帧画质好但数据量惊人1080p60fps的YUV裸流带宽要超过2GbpsUSB 3.0虽然理论上够但实际传输中数据线的质量、主板的USB控制器、其他外设的抢占都会成为瓶颈。所以服务端要立刻完成编码压缩否则整个链路会因为数据堆积而拖垮。编码环节我选择的是H.264原因很直接兼容性最好。H.265虽然同画质下码率更低但老一点的手机、电视盒子硬解H.265常常出问题解码一卡整个画面就废了。H.264在几乎所有设备上都有硬解支持对项目的第一版来说稳定远比极致画质重要。传输层我用的是UDP而不是TCP。如果你没接触过这块我先解释一下TCP是可靠传输数据包丢了会重传但重传带来的等待时间在实时画面传输里是天敌UDP只管发不管收丢包后画面会闪一下但不会让整个链路停下来等待重传。对游戏画面来说偶尔一个瞬时花屏的代价远小于每一次网络波动都卡顿半秒的代价。所以方向定了基于UDP做丢包靠上层策略补偿而不是靠传输层的重传。2.2 自研协议的取舍既然是自研方案协议就不可能完全用现成的RTSP或者WebRTC。很多人问过我WebRTC不是很好吗选WebRTC不就行了吗确实WebRTC在浏览器端的支持非常好我最初也动过这个心思但实测下来它有个问题WebRTC内部有一套拥塞控制算法它会根据估计的带宽动态调整码率听起来很智能但在局域网这种高带宽低丢包的环境里它的自适应算法反而会把画面质量压得过于保守。我要的是“你告诉我码率你就尽量保持这个码率”的体验而不是让协议自己去猜。我最终设计的协议非常精简每帧画面被切开成若干个分片包包外面带上帧序号、分片序号、时间戳和总片数这四个字段。客户端收到分包后按帧序号和分片序号排队重组。关键帧间隔设置的是一秒两个也就是每0.5秒一个可随机接入点新设备加入时最多等半秒就能看到画面这个体验在游戏场景里是可以接受的。音频我没有单独走一条通道而是把音频打包成独立的流和视频流并列发送。为什么不分到同一个包里因为音频要求连续、低延迟但偶尔丢一个包也不致命视频则对吞吐要求极高。两条独立通道客户端就能分别设置缓冲策略音频缓冲尽量小视频缓冲稍微留一点余地。这个设计在调音画同步时帮了我大忙后面会细说。2.3 局域网环境对系统的硬性约束搞串流最怕的是把无线网络想得太美好。我见过不少人在公司办公室里跑局域网串流千兆有线网络下延迟只有两三毫秒于是想当然地以为家里也能做到。实际家用环境要复杂得多。家用无线网络的覆盖范围、墙体衰减、邻居Wi-Fi的信道占用都直接影响UDP包的存活率。我测试时把服务端连在有线千兆交换机上客户端分布在书房、卧室、客厅三个位置效果差异非常大客厅里解码端到端延迟能到90毫秒左右书房隔了一堵墙之后偶尔跳到140毫秒卧室距离最远但干扰少的时段表现又还不错。所以服务端必须有一个参数能应对不同位置的客户端不能一套参数用到死。我的做法是让每个客户端上报自己的实时丢包率和平均延迟服务端据此给每个设备单独计算推荐码率范围。这个设计谈不上新颖但非常实用能避免某个角落里的弱信号设备拖垮整个网络。3. 服务端构建与实测参数3.1 服务端主流程服务端的代码结构我没有用复杂的框架整个主进程就是一个大循环从采集卡拿帧送进编码器编码器吐出的数据包再交给发送模块。看起来简单实际编码时需要处理几个容易忽略的问题。首先是采集卡的帧格式适配。不是所有采集卡输出的都是理想格式有些卡在系统里默认输出的是MJPEG格式这是一种压缩过的帧格式直接送入H.264编码器会经过一次解压再压缩画质损耗和延迟都会增加。所以我在服务端做了一个自动检测模块优先选择YUYV或者NV12格式的裸帧输出只有在这种格式不可用时才退回MJPEG。不少人串流画面发糊查到最后就是栽在采集卡的这个输出格式上。我的服务端主流程用一段伪代码来描述大概是这样def main(): device open_uvc_device(device_id) device.set_output_format(NV12) encoder create_h264_encoder( width1920, height1080, bitrate25_000_000, gop_size30, presetlow_latency ) sender create_udp_sender(multicast_group, port) while not quit_flag: frame device.read_frame() packets encoder.encode(frame) for packet in packets: sender.send(packet) control_data sender.collect_measurements() adjust_bitrate_by_client_feedback(control_data)这个循环的吞吐量很重要。编码器需要输入帧及时、输出包及时不能让中间的队列堆积太多帧否则延迟会线性增长。我在编码器前面设置了一个队列深度的硬限制当队列超过三帧时直接丢弃最旧的帧。这个决定看起来残忍但对实时性来说是完全必要的丢掉一帧旧画面比让所有帧排队等上几秒钟要好得多。3.2 码率帧率延迟三者怎么平衡游戏串流有个三角约束码率决定画质帧率决定流畅度延迟决定响应感。这三者不可能同时拉满必须根据场景取舍。我在AnyPS5默认配置下采用的是1080p60帧码率25Mbps目标延迟控制在100毫秒以内。为什么是25Mbps因为在流畅动作场景下H.264编码1080p60画面要维持足够细节低于20Mbps会出现明显的块效应特别是草皮、粒子特效多的游戏场景。但超过30Mbps之后画质提升边际效应就很明显了反而会占用更多无线带宽留给其他设备的空间就小了。25Mbps是从画质和网络占用两个维度折中出来的经验值。帧率我坚持锁60不降到30。你可能觉得延迟如果压不下来的话锁60也是白搭。但这里有个容易被忽略的点串流画面帧率如果只有30运动场景的视觉流畅感会明显下降玩家的操作感受会觉得“拖”。60帧即使延迟有100毫秒视觉上的连续感还在降到30帧则是双重打击既响应迟钝画面又是断断续续的。关键帧间隔也需要单独说。H.264编码中I帧关键帧是独立可解码的帧P帧需要依赖前面的帧才能解出画面。如果GOP设置太大新加入的客户端要等好几秒才能等到一个I帧这个体验没法忍。我把GOP固定为30帧也就是每秒两个I帧代价是多花一点码率但换取的是任一时间点加入都最多等0.5秒出图。3.3 多设备接入与带宽分配既然项目叫AnyPS5自然希望同时接入的设备越多越好。但在无线网络里总吞吐不是无限共享的。实测时我让服务端跑在千兆有线口客户端里有两个走无线。画面主力是书房笔记本码率给到25Mbps卧室平板作为第二屏只需要低画质显示游戏状态码率给到8Mbps客厅手机只是偶尔看一眼码率压到5Mbps。三路加一起才38Mbps对于一台Wi-Fi 6路由器来说理论上没有压力。但问题是无线协议的开销比想象中大。39Mbps的应用层数据在无线链路上实际占用可能要乘以一个系数。如果家里还有其他流媒体设备在看高清视频整个信道的拥塞程度会迅速上升。我的解决办法是让每个客户端上报自己的丢包情况连续三秒丢包率超过3%就把该设备的码率往下调整一档直到丢包率回到正常范围。这套反馈机制让整个系统在无线环境波动时自动妥协而不是直接崩掉。4. 客户端适配与体验调优4.1 解码能力差异带来的显示差异AnyPS5的客户端覆盖了手机、平板、笔记本、电视盒子这四类设备。看起来都是屏幕实际解码能力千差万别。新一点的手机和平板都支持H.264 High Profile硬解1080p60毫无压力但一些老电视盒子的解码器只支持到H.264 Main Profile甚至只支持Baseline解码1080p的时候要么发热严重要么直接无法硬解。我不知道有多少人在这上面踩过坑。一开始我的想法是统一推High Profile 1080p60流结果家里的老盒子完全扛不住画面像是幻灯片一样一帧一帧跳。后来我在服务端加了一个“能力协商”机制客户端启动时上报自己支持的最高分辨率、Profile、帧率服务端根据这些信息动态选择推流参数。这样电视盒子就分配给它720p30、Main Profile虽然清晰度不如笔记本但至少流畅稳定。下面是我实际测试下来整理的客户端兼容性参考客户端类型解码能力推荐参数实测表现主力笔记本H.264 High 1080p601080p60 25Mbps稳定流畅新手机/平板H.264 High 1080p601080p60 20Mbps低于25Mbps时无明显损失老旧电视盒子H.264 Main 720p30720p30 10Mbps流畅但高动态细节有损失4.2 输入回传与使用方式关于输入回传我最初也设想过从客户端反向给服务端发控制指令再通过USB模拟手柄信号回传给游戏主机。但这个方案绕不开硬件层的认证和HID模拟问题玩起来风险高、代价大对一个个人项目来说性价比太低。所以我最终把回传模块的功能范围缩小了客户端只用来接收画面和查看状态操作仍然通过PS5手柄完成。实际使用中我发现只要把屏幕放在伸手可及的位置手柄直接连着主机这个体验反而是最舒服的。书房里玩的时候屏幕放在桌上手柄蓝牙依然能连到客厅的主机吗实测是不行距离太远了。这时候我在书房临时加了一个USB延长方案的思路没有落地最终买了个超长USB线把手柄接收器拉到了书房这个改造比较简单也解决了远距离操作的问题。AnyPS5的定位是解决“画面到屏幕”操控层面的物理限制我选择了最朴素的方式来解决。再补充一点如果你只是想在卧室床上看个片、刷个剧情动画不需要实时操作手柄那么这个方案的使用体验非常接近随便拿一块屏幕就能看主机的感觉。4.3 延迟优化实测笔记延迟是这个项目的命门。我把整条链路的延迟拆开测了一遍采集卡的采集延迟大概在15毫秒左右编码延迟低延迟预设下约8毫秒网络传输延迟在同一个Wi-Fi下约20到40毫秒客户端解码和渲染延迟约20到30毫秒。加起来就是90到100毫秒左右。实际上手感受如何玩回合制、看剧情、操作菜单完全没有问题。动作游戏讲究精确弹反的这种会比直接插电视差一截但也在能接受的范围内。如果我把码率降到15Mbps、客户端缓冲拉到最小总延迟能压到75毫秒左右代价是画面偶尔会出现轻微模糊。延迟调优过程中的最大发现是客户端缓冲。很多播放器为了画面平滑默认在解码器前面加了十几帧的缓冲这在直播场景中没问题但游戏串流里十几帧缓冲直接吃掉两三百毫秒。我在客户端里把所有缓冲压到最低只保留两帧的余量代价是无线网络波动时偶尔会出现短暂的画面撕裂但整体观感反而好得多——因为延迟明显降低了。如果你也想复现这个项目我建议延迟优化的顺序是先测采集延迟再调编码器预设然后压客户端缓冲最后才考虑网络层面的路由器优先级设置。这四步的收益是递减的如果跳过前三步直接去调路由器的QoS基本属于自我安慰。5. 布网与避坑我在项目中踩过的几个隐形坑5.1 无线频谱的干扰与信道占用我最早把服务端和客户端都放在同一个Wi-Fi 5G频段下实测延迟非常不稳定有时候60毫秒有时候跳到200毫秒。抓包之后发现问题出在信道占用上周围邻居的无线设备把5G频段挤得很满我的路由器自动选择了信道36而隔壁路由器刚好也在用这个信道附近的范围。解决方式看起来很简单就是把路由器的5G信道固定到一个相对干净的频段。但这里有个细节在中国家用环境下5G高频段有一部分DFS信道是有雷达检测机制的路由器检测到雷达信号会自动切换信道反而引入更大的抖动。所以我选择了较低的36到48之间的非DFS信道手动固定。调整之后无线链路的延迟曲线平稳了很多说明干扰对串流的影响远远大于带宽参数的影响。5.2 采集卡的帧格式筛选这个坑我在前面提过但值得单独拿出来说。市面上很多采集卡宣传时都说自己是UVC免驱插上就能用但它们的默认输出格式千差万别。有些卡默认输出MJPEG有些甚至只能输出低帧率。结果是画质看起来就是不对色彩偏淡、边缘发糊、运动场景块状马赛克严重。我的排查过程是这样的先通过系统的视频设备列表查看当前格式发现采集卡报告的是MJPEG而不是YUV。然后我在服务端里加了一个枚举所有输出格式的功能切换成NV12输出。问题立刻改善了一大半延迟也降了十几毫秒。以后再遇到串流画质差的问题我会第一时间怀疑采集卡的输出格式而不是急着调编码器参数。第二个坑是USB线缆。USB 3.0采集卡对线材质量比较敏感我一开始拿了一根手机充电线来接系统反复出现设备掉线。换了一根有屏蔽层的USB 3.0数据线之后问题消失了。这种问题排查起来很隐蔽因为设备管理里看起来一切正常唯独数据传着传着就断了。5.3 音频同步的滞后问题音画不同步这个问题几乎把我逼疯。画面延迟在100毫秒左右但音频有时候比画面快200毫秒有时候慢150毫秒完全不稳定。刚开始我怀疑是音频采集环节引入的延迟后来发现是客户端缓冲设计的问题。因为我把视频缓冲和音频缓冲分别处理视频缓冲留了两帧音频缓冲几乎归零本意是让音频尽可能跟手。但在编码器环节音频需要积累一定数据量才能编码成一个包这本身会引入几十毫秒延迟加上无线传输的抖动音频包的到达时间很不规律。客户端如果不再加缓冲就会出现忽快忽慢的现象。最终我采用的方案是在客户端维护一个音视频时间戳校准模块每秒钟根据收到的视频帧时间戳和音频时间戳计算一次偏移量然后在音频播放队列里做微调最多能自动校正正负100毫秒范围内的偏移。实测跑下来音画同步误差稳定在30毫秒以内这个体感已经完全感受不到了。还是要说一句音频同步调试一定要在无线网络环境下测只插有线测试是发现不了这个问题的。6. 这个项目后续还能怎么玩6.1 把第二屏变成攻略屏和状态屏串流只是基础能力真正让AnyPS5变得“有用”的是第二屏联动。以前打一些需要查资料的游戏我得掏出手机查攻略目光在电视和手机之间来回切换极其分神。现在客户端里加了一个辅助面板模块服务端可以按需把游戏状态信息推送到第二屏当前地图、任务提醒、直播画面甚至服务器实时负载都可以做成独立的小卡片视图。实现上非常轻量因为辅助面板走的是和视频完全不同的通道占用的带宽几乎可以忽略。这就是底层协议自定制的好处如果一开始用了现成方案加这种自定义消息通道会非常痛苦。6.2 多屏联动的脑洞空间多屏联动的方向其实还有不少可以扩展的空间。比如在手机上划出一个窗口专门显示截图游戏过程中想看某个画面细节直接在主屏上标记一下平板立刻显示高分辨率截图这个对观察型玩家相当实用。还有一个方向是加入录像定时任务。既然画面已经经过服务端编码天然的可以跟一个录制模块同时写本地文件。我后来实现了“串流即录像”的功能只是因为要控制磁盘写入对编码线程的干扰所以设置成可选开启。这些扩展功能都建立在AnyPS5这套架构已经把采集、编码、传输、解码每一层都暴露出来、可独立控制的基础上。6.3 一点个人心得AnyPS5这个项目做下来的最大感受是串流的瓶颈往往不在编码器或者传输协议而在于整条链路的一致性和细节取舍。采集卡输出格式不一致画面糊客户端解码能力参差不齐同一个参数不可能通吃无线环境随时在变固定码率一定会出问题。把这些细节都理顺之后你得到的不仅是一套好用的串流方案更是对视频传输全链路的一种感觉——以后再看到任何“卡顿”第一反应就是去定位具体是哪一环出了问题。如果你也想搭一套类似的系统我的建议是先选一张靠谱的采集卡然后从服务端最小循环跑通开始再逐步加客户端和调优。遇到画质问题先查采集格式遇到延迟问题先压客户端缓冲遇到偶发卡顿再去折腾无线信道。串流这件事没有魔法每一步都控制在预期之内最终整体体验就会超预期。