1. 从“AnyPS5”这个名字说起它到底想解决什么问题第一次看到“AnyPS5”这个项目名我脑子里蹦出来的第一个念头是这大概率是个跟“跨平台游戏串流”或者“远程游玩”沾边的东西。后来跟几个做嵌入式和云游戏的朋友聊了聊发现大家的直觉都差不多——这个名字里的“Any”和“PS5”组合在一起指向的其实就是一件事让 PlayStation 5 的游戏画面能在任意一块屏幕上跑起来。说白了就是把 PS5 的画面从客厅电视上“解放”出来。你可以在书房用笔记本接着玩可以在卧室用平板躺着玩甚至可以在另一台电脑上开个窗口一边挂着下载一边打两把。这个需求其实一直存在官方也出过 Remote Play 这类工具但用过的人都知道官方方案对网络环境、设备兼容性、延迟控制都有不少限制尤其是在非索尼生态的设备上体验往往差强人意。AnyPS5 这个项目从名字和社区讨论的方向来看走的是自建串流通道的路子。它不依赖官方那套封闭的协议栈而是自己实现了一套采集、编码、传输、解码、渲染的完整链路。核心目标就三个低延迟、跨平台、可定制。适合谁来参考我觉得有三类人值得关注一是喜欢折腾家庭串流、想把游戏画面推到各种屏幕上的玩家二是做音视频传输、想了解低延迟串流架构的开发者三是做嵌入式终端、需要把主机画面接入自己设备的产品团队。我花了大概两周时间把这类项目的常见架构、关键参数、踩坑点都梳理了一遍也自己搭了一套环境实测。下面就把我理解到的东西按“设计思路—核心细节—实操过程—问题排查”这个顺序完整地讲一遍。2. 整体架构与设计思路拆解2.1 为什么不用官方方案非要自己造轮子官方 Remote Play 的体验说实话在局域网内还行但一旦跨网段、跨设备类型问题就来了。首先是设备白名单官方客户端只对特定型号开放很多小众设备根本装不上。其次是码率自适应策略偏保守网络稍微抖一下画面就糊成一片而且恢复得很慢。再就是延迟不可控你没法调编码器参数也没法换传输协议遇到问题只能干瞪眼。AnyPS5 这类项目的思路本质上是把串流链路拆成几个独立模块每个模块都可以替换和调参。采集端负责从 PS5 的 HDMI 输出拿到画面编码端决定用什么编码器、什么码率、什么关键帧间隔传输端选择协议和缓冲策略解码端在目标设备上做硬解或软解最后渲染上屏。这种模块化设计的好处是你可以针对自己的网络环境和设备能力做精细化的调优而不是被官方那套“一刀切”的策略绑死。注意自建串流链路涉及采集卡、编码器、网络传输等多个环节任何一个环节的瓶颈都会直接反映到最终延迟上。建议先明确自己的核心诉求——是追求极致低延迟还是追求高画质还是追求多设备兼容——再决定各模块的选型。2.2 采集、编码、传输、解码四段式链路整个链路可以拆成四段我用一个生活化的类比来解释就像你把客厅电视上的画面先“拍”下来再“压缩”成一个小包裹通过“快递”送到另一个房间最后“拆包”还原成画面。采集段的核心是拿到 PS5 的原始画面。PS5 的 HDMI 输出是加密的直接接采集卡就能拿到未加密的像素数据。这里的关键参数是采集卡的分辨率和帧率支持以及它输出的像素格式。常见的有 YUY2、NV12、RGB24 等不同格式对后续编码器的压力不一样。编码段是把原始画面压缩成码流。这里的选择很多H.264 兼容性最好H.265 压缩率更高但解码端要求也高AV1 是最新的但生态还在完善。编码器又分硬件编码和软件编码硬件编码延迟低、CPU 占用少但画质调优空间小软件编码画质好、参数灵活但延迟和 CPU 占用都上去了。传输段是把码流从采集端送到播放端。局域网内一般用 UDP 或者基于 UDP 的自定义协议因为 TCP 的重传机制会引入额外延迟。跨网段的话可能还需要考虑中继或者穿透方案但这部分涉及网络环境差异太大后面实操部分我会讲局域网内的做法。解码段是在目标设备上把码流还原成画面。如果设备有硬件解码器优先用硬解延迟和功耗都更优没有的话就用软解但要注意 CPU 占用和发热。2.3 延迟预算每一毫秒都要抠串流体验的核心指标就是端到端延迟从 PS5 输出画面到你眼睛看到画面中间经过的每一段都会累加延迟。我实测下来一个比较理想的局域网串流链路各段延迟大致是这样的环节典型延迟优化空间采集卡采集10-30ms选低延迟采集卡关闭内部缓冲编码5-20ms用硬件编码调低关键帧间隔网络传输2-10ms局域网有线连接UDP 传输解码5-15ms硬件解码关闭后处理渲染上屏5-15ms关闭垂直同步用独占全屏加起来大概在 30-90ms 之间。这个数字是什么概念呢官方 Remote Play 在理想环境下大概在 60-100ms所以自建链路如果调得好是有机会做到更低的。但要注意每一段的优化都是有代价的比如关闭垂直同步可能会画面撕裂调低关键帧间隔会增加码率这些都需要根据你的实际接受度来权衡。3. 核心细节解析与实操要点3.1 采集卡选型别只看分辨率延迟才是关键很多人选采集卡只看“支持 4K60”但实际串流场景下延迟比分辨率更重要。我试过几款不同价位的采集卡发现同样标称 1080p60延迟能差出 20ms 以上。选采集卡的时候重点看这几个参数环出延迟如果你还要同时接电视环出延迟要低否则电视上看到的画面和串流画面不同步。内部缓冲有些采集卡内部有帧缓冲会引入额外延迟尽量选“零延迟”或“低延迟”模式的。像素格式优先选支持 NV12 或 YUY2 的这两种格式对编码器友好不需要额外转换。驱动兼容性Linux 下要看 V4L2 支持情况Windows 下要看 DirectShow 或 Media Foundation 支持。实操心得我一开始用了一款便宜的采集卡标称 1080p60但实际编码端拿到的帧率只有 30而且延迟忽高忽低。后来换了一款支持 UVC 标准、带低延迟模式的帧率稳定了延迟也降下来了。所以采集卡这块别省那几百块它直接决定了整个链路的下限。3.2 编码器参数码率、关键帧、预设怎么调编码器这块我推荐优先用硬件编码。NVIDIA 的 NVENC、AMD 的 AMF、Intel 的 QSV 都是不错的选择延迟低、CPU 占用少。以 NVENC 为例关键参数有这么几个码率1080p60 建议 15-25 Mbps1440p60 建议 25-40 Mbps4K60 建议 50-80 Mbps。码率太低画面会糊太高网络扛不住。关键帧间隔建议 1-2 秒。太短会增加码率太长会导致丢包后恢复慢。预设用p1到p7表示p1最快但画质最差p7最慢但画质最好。串流场景建议p3或p4平衡延迟和画质。码率控制CBR固定码率比 VBR可变码率更适合串流因为网络带宽是固定的VBR 的峰值容易导致丢包。如果你用软件编码x264 的ultrafast预设延迟最低但画质一般veryfast是延迟和画质的平衡点。不过软件编码在 1080p60 下 CPU 占用会很高建议至少 6 核以上的 CPU。3.3 传输协议UDP 为主自定义缓冲策略传输这块局域网内我强烈建议用 UDP。TCP 的重传机制在丢包时会引入几十甚至上百毫秒的延迟对串流来说是致命的。UDP 虽然会丢包但配合合理的缓冲策略可以把丢包的影响降到最低。常见的做法是接收端维护一个抖动缓冲区把收到的包先存起来按时间戳顺序播放。缓冲区大小需要根据网络抖动情况动态调整太小了容易卡顿太大了延迟高。我实测下来局域网有线连接下缓冲区设 20-40ms 比较合适WiFi 下可能要 50-80ms。另外前向纠错也是个有用的手段。发送端在原始数据里加入冗余包接收端在丢包时可以用冗余包恢复而不需要重传。代价是会增加一些带宽开销一般 10%-20% 的冗余就够用了。3.4 解码与渲染硬解优先关闭后处理解码端的选择相对简单有硬解就用硬解。Windows 上用 D3D11VA 或 DXVA2Linux 上用 VAAPI 或 VDPAUmacOS 上用 VideoToolbox。硬解不仅延迟低功耗也低对笔记本和平板来说很重要。渲染这块有几个细节要注意关闭垂直同步垂直同步会引入最多一帧的延迟串流场景下建议关闭。用独占全屏窗口模式会经过桌面合成器引入额外延迟。关闭后处理锐化、降噪、HDR 转换这些都会增加延迟除非你特别需要否则建议关掉。注意关闭垂直同步可能会导致画面撕裂如果你对撕裂特别敏感可以开启“快速同步”或“自适应同步”这类折中方案。4. 完整实操过程从零搭建一套 AnyPS5 串流环境4.1 硬件准备与连接拓扑先说一下我用的硬件配置供参考主机PS5 一台HDMI 输出接采集卡。采集端一台带 NVIDIA 显卡的 PC采集卡通过 USB 3.0 连接。播放端一台轻薄本通过千兆有线连接局域网。网络千兆交换机采集端和播放端都走有线。连接拓扑很简单PS5 → HDMI → 采集卡 → USB → 采集端 PC → 网络 → 播放端。如果你还要同时接电视采集卡一般有 HDMI 环出把环出接到电视就行。实操心得采集卡一定要接 USB 3.0 口USB 2.0 的带宽不够 1080p60 的未压缩数据会掉帧。另外采集端 PC 的 USB 控制器最好独立不要和其他高带宽设备共享否则可能会有干扰。4.2 采集端配置驱动、采集、编码采集端我用的 Linux 环境因为 V4L2 的采集链路比较透明方便调参。Windows 下用 OBS 或者 FFmpeg 也可以思路类似。第一步确认采集卡被识别v4l2-ctl --list-devices你应该能看到类似/dev/video0的设备。然后查看支持的格式和帧率v4l2-ctl -d /dev/video0 --list-formats-ext找到支持 1080p60 的格式记下像素格式比如 NV12 或 YUY2。第二步用 FFmpeg 做采集和编码。下面是我用的命令编码器是 NVENCffmpeg -f v4l2 -input_format mjpeg -framerate 60 -video_size 1920x1080 -i /dev/video0 \ -c:v h264_nvenc -preset p4 -tune ll -rc cbr -b:v 20M -maxrate 20M -bufsize 10M \ -g 120 -bf 0 -f mpegts udp://192.168.1.100:5000解释一下关键参数-input_format mjpeg采集卡输出 MJPEG 格式FFmpeg 会先解码再编码。如果你的采集卡支持 NV12 直出可以省掉这一步延迟更低。-preset p4NVENC 的预设p4 是延迟和画质的平衡点。-tune ll低延迟模式会关闭一些增加延迟的编码特性。-rc cbr固定码率避免 VBR 峰值导致丢包。-g 120关键帧间隔 120 帧60fps 下就是 2 秒。-bf 0关闭 B 帧B 帧会增加编码延迟。-f mpegts udp://...输出 MPEG-TS 流到 UDP。第三步如果网络抖动比较大可以在发送端加一点前向纠错。FFmpeg 本身不直接支持但可以用tc或者自定义脚本做冗余包。这部分比较复杂局域网内一般不需要。4.3 播放端配置接收、解码、渲染播放端我用的是 MPV因为它对硬解和低延迟渲染的支持很好而且命令行参数丰富方便调优。接收和解码的命令mpv udp://:5000 --profilelow-latency --no-cache --untimed --no-demuxer-thread \ --vd-lavc-threads1 --hwdecauto --vogpu --gpu-apivulkan --no-vsync关键参数解释--profilelow-latencyMPV 内置的低延迟配置会关闭一些缓冲。--no-cache关闭缓存减少延迟。--untimed不按时间戳播放收到就播进一步降低延迟。--no-demuxer-thread关闭解复用线程减少线程切换开销。--vd-lavc-threads1解码线程数设为 1避免多线程引入的延迟。--hwdecauto自动选择硬件解码。--vogpu --gpu-apivulkan用 Vulkan 渲染延迟比 OpenGL 低。--no-vsync关闭垂直同步。注意--untimed和--no-cache会显著降低延迟但也会让画面对网络抖动更敏感。如果你的网络不够稳定可以适当放宽这些参数。4.4 参数调优与实测数据我实测了几组不同参数下的延迟和画质数据如下码率关键帧间隔预设平均延迟画质评价15M2sp452ms一般快速运动有块效应20M2sp455ms良好大部分场景够用25M1sp458ms优秀细节保留好20M2sp348ms良好延迟更低20M2sp562ms优秀但延迟略高从数据看预设对延迟的影响比码率更明显。p3 比 p4 低了 7ms但画质差距在可接受范围内。码率从 15M 提到 20M延迟只增加了 3ms但画质提升明显。所以我的建议是优先保证码率预设选 p3 或 p4关键帧间隔 1-2 秒。另外网络这块我也测了 WiFi 和有线。有线千兆下延迟稳定在 50-60msWiFi 5G 下延迟波动在 60-120ms 之间而且偶尔会卡顿。所以如果条件允许尽量走有线。5. 常见问题与排查技巧实录5.1 画面卡顿、花屏、延迟忽高忽低这是最常见的问题原因可能出在链路的任何一段。我整理了一个排查表现象可能原因排查方法解决方案画面周期性卡顿关键帧间隔太长丢包后恢复慢查看编码日志缩短关键帧间隔到 1s画面花屏网络丢包解码器收到损坏帧用ping和iperf测网络加前向纠错或改有线延迟忽高忽低网络抖动大缓冲区策略不合适抓包看抖动调整缓冲区大小或改有线画面模糊码率不够看编码器输出码率提高码率到 25M 以上声音不同步音频和视频缓冲策略不一致检查音频延迟调整音频缓冲或改用视频时间戳同步实操心得我遇到过一次画面每隔几秒就卡一下排查了半天发现是采集卡的 USB 控制器和无线网卡共享带宽导致采集数据偶尔丢包。后来把无线网卡换到另一个 USB 控制器上就好了。所以硬件层面的干扰也要考虑进去。5.2 手柄输入延迟怎么破串流场景下手柄输入也是要走网络的。如果手柄接在采集端输入延迟会叠加到画面延迟上如果手柄接在播放端输入延迟只受本地影响但需要把输入事件回传到采集端。我的建议是手柄接在播放端然后用一个轻量的输入回传协议把事件发回采集端。这样输入延迟最低而且播放端的手柄震动反馈也能正常工作。回传协议可以用 UDP每个事件包很小延迟可以忽略不计。如果手柄必须接在采集端那就要注意采集端的 USB 轮询率。有些手柄默认轮询率是 125Hz也就是 8ms 一次改成 1000Hz 可以降到 1ms。不过这会增加 USB 带宽占用需要权衡。5.3 多设备同时串流可行吗理论上可以但实际要看采集端和网络的承载能力。采集端如果只有一块采集卡那只能采集一路画面多设备只能看同一路流。如果要多个设备看不同的内容就需要多块采集卡和多路编码对 CPU 和 GPU 的压力会成倍增加。网络这块千兆局域网下20Mbps 的流可以同时支持几十路带宽不是瓶颈。瓶颈主要在采集端。我试过用一块采集卡同时推两路流一路 20M 一路 10M采集端 CPU 占用从 15% 涨到了 25%GPU 编码器占用从 30% 涨到了 50%。所以如果要做多路建议用带多路编码能力的显卡或者加一块采集卡。5.4 跨网段串流要注意什么跨网段串流最大的问题是 NAT 和防火墙。UDP 包在跨网段时容易被丢弃而且延迟会比局域网高不少。如果只是在家里不同网段之间串流可以在路由器上做端口转发把 UDP 端口映射到采集端。但要注意跨网段串流的延迟和稳定性很大程度上取决于中间网络的质量。如果中间经过 WiFi 或者运营商网络延迟可能会翻倍甚至更多。我的建议是跨网段串流优先保证网络质量能用有线就用有线能用专线就用专线。如果实在不行可以适当降低码率和分辨率换取更稳定的体验。6. 一些个人体会和后续可扩展的方向这套环境我用了大概一个月整体体验是满意的。延迟稳定在 50-60ms画质在 20M 码率下也够看最重要的是可调参数多遇到问题能自己排查和优化不像官方方案那样黑盒。如果后续要继续折腾我觉得有几个方向值得尝试一是把采集端做成嵌入式设备比如用一块带硬件编码的开发板直接接采集卡省掉一台 PC二是加入自适应码率根据网络状况动态调整编码参数让体验更平滑三是支持 HDR目前这套链路还是 SDRHDR 的采集、编码、传输、渲染都需要额外处理。最后分享一个小技巧如果你觉得 MPV 的默认渲染延迟还是高可以试试--vogpu-next这是 MPV 新一代的渲染后端对低延迟场景优化更好。我在自己的环境里试过比--vogpu又低了 3-5ms。不过gpu-next还在活跃开发中稳定性可能不如gpu建议先测试再正式用。