UE5 Pixel Streaming实战：三步搭建Windows像素流服务

年前接了个需求要把一个UE5工地安全体验项目搬到网页上客户要求不用下载任何客户端用浏览器打开就能看。我当时第一反应就是用UE5官方自带的Pixel Streaming。说实话第一次接触这套东西的时候光看官方文档有点懵信令服务器、WebRTC、编码器、端口转发这些东西堆在一起很容易绕晕。但真正动手跑通一遍以后你会发现整套逻辑其实很清晰渲染放在云端的Windows机器上浏览器只负责接收画面和回传操作。这篇文章我就按“三步走”的思路把从零搭建Windows像素流服务的完整过程梳理出来顺带分享一些我在实际部署中踩过的坑和排查经验。适合UE开发者、做数字孪生或虚拟仿真的同学参考尤其是那些想把UE应用快速变成网页版的场景。1. 先搞懂Pixel Streaming在忙什么1.1 渲染在云端画面在浏览器Pixel Streaming的思路可以这样理解把UE当作一个“游戏机”浏览器当作“显示器加手柄”。UE程序的画面不是在自己的窗口里呈现而是把每一帧渲染结果交给编码器压缩成视频流通过WebRTC协议推送到浏览器浏览器把画面解码出来同时把鼠标、键盘、触控等输入操作通过网络传回UE端UE再响应操作继续渲染下一帧。这个模式的优点是客户端零安装任何有较新浏览器的设备都能访问包括手机和平板。尤其适合产品展示、建筑可视化、教学培训这类场景用户不需要高性能显卡只要你服务器那边跑得动就行。缺点也很明显对服务器GPU、上行带宽和网络延迟的要求比较高如果做成多人在线使用成本会线性增长。1.2 为什么优先在Windows上搭很多人会问UE5跑在Linux容器里不是更省资源吗确实可以但如果你自己从零开始没有专门的运维团队我建议第一版先在Windows上搭。原因有三个第一UE在Windows下的GPU驱动、硬件编码器NVIDIA NVENC或AMD AMF支持最成熟开发环境即是部署环境调试方便第二官方文档和社区的教程绝大多数默认都是Windows流程遇到问题更容易找到参考第三Windows下打包出来的目标文件可以直接通过运行参数启动像素流服务不需要额外容器化配置。1.3 基础环境清单纸上谈兵没有意义先把清单列出来。以下是我实际使用的环境你可以按自己的情况调整。项目推荐配置说明操作系统Windows 10/11 专业版64位家庭版也能跑但公网部署最好用专业版以上方便管理防火墙和远程登录UE版本UE5.1~5.5均可不同版本插件位置略有差异但整体流程一致GPUNVIDIA GTX 1060 或更高建议RTX系列Pixel Streaming默认走NVENC硬件编码AMD显卡也能用但部分编码参数不同CPU4核以上视频编码主要靠GPUCPU负担相对轻但场景复杂度高时需要更强CPU内存16GB以上UE运行本身吃内存场景大就加Node.js无需单独安装UE自带信令服务器脚本新版信令服务器基于Node.jsUE资源目录已包含浏览器Chrome / Edge 最新版Safari在部分编码格式下兼容较差网络方面局域网内部测试至少需要百兆宽带公网部署时建议服务器上行带宽不低于10Mbps因为一个1080P30的流大概需要4~8Mbps码率。这里说的是码率不是带宽占用实际还要留点余量。2. 三步搭建从打包到访问的完整链路2.1 第一步启用插件、调整项目设置、打包可流送版本先打开你的UE5项目在编辑器里找到“插件”面板搜索“Pixel Streaming”启用它。插件全名是“Pixel Streaming Plugin”启用后会让你重启编辑器。这一步很多人都知道但容易漏掉的是后续的项目设置调整。重启后进入“项目设置 - 渲染”。如果你想让画面质量好一点可以把“全局光照”设为“Lumen”但这会增加GPU负载。像素流送时我一般会开硬件光线追踪前提是你的显卡是RTX系列。如果是集显或老显卡建议直接关掉光追。硬件编码默认是“自动”但如果你的机器有好几张显卡最好在命令行里手动指定编码器否则可能跑到集显上画面会卡到没法看。接下来是打包。在工具栏里选择“Windows - Windows”作为目标平台然后点击“打包项目”。打包前建议新建一个干净的空白关卡作为默认场景因为像素流服务启动后只会加载默认地图不想让别人看到编辑器里的测试场景就单独搞一个启动关卡。打包时有个容易忽略的选项在“项目设置 - 目标硬件”里把目标平台选择为“台式机/服务器”不要让UE为移动平台做过度优化。打包完成后你会得到一个包含.exe和一堆文件的文件夹。注意这个文件夹不能单独拷贝一个exe走Pixel Streaming依赖旁边的Content、Plugins等目录我见过最常犯的错就是把exe单独拉出来运行结果报缺这缺那。2.2 第二步启动信令服务器和流端进程这里先说明一下现在有两条启动路径以前需要手动去引擎目录里找SignallingWebServer然后通过Node.js运行UE5.2之后信令服务器脚本已经集成到插件资源目录里路径大概在引擎安装目录\Engine\Plugins\Media\PixelStreaming\Resources\WebServers\SignallingWebServer。实际操作中我习惯把信令服务器复制到项目打包目录旁边比如建一个PixelStreamingServer文件夹这样不会受引擎升级影响。启动信令服务器很简单Windows下直接双击或在命令行里运行cd C:\YourProject\SignallingWebServer run.bat运行后信令服务器会监听两个端口默认的HTTP端口是80用于浏览器访问网页WebSocket端口是443如果没占用其实它会自动切换或自定义端口浏览器和UE进程通过这个通道交换连接信息。如果你本机80端口被IIS或别的服务占用了可以修改config.json里的端口配置。接下来启动你的UE打包程序。在命令行里执行exe并带上像素流参数YourProject.exe -PixelStreamingIP127.0.0.1 -PixelStreamingPort8888 -PixelStreamingEncoderHardware-PixelStreamingIP填写信令服务器的IP地址。本地测试填127.0.0.1局域网测试填服务器本机局域网IP。-PixelStreamingPortUE程序监听WebSocket连接的端口默认是8888。要跟信令服务器配置里的PeerConnectionOptions对应。-PixelStreamingEncoderHardware强制使用硬件编码不指定的话UE可能默认用软件编码画质和帧率都会受影响。启动后命令行窗口会不断输出连接日志。看到类似“WebSocket connected”的提示说明UE程序已经和信令服务器握手成功。2.3 第三步浏览器访问和基础验证信令服务器和UE程序都跑起来后在同一台机器或局域网另一台电脑上打开浏览器访问http://127.0.0.1如果一切正常浏览器会自动发起WebRTC连接稍等几秒钟就能看到UE画面。第一次访问可能会花一点时间建立连接不要急着刷新黑屏超过10秒再排查。更推荐的方式是直接访问测试页面http://127.0.0.1?Test这个?Test参数会进入Pixel Streaming自带的自动连接测试页页面会强制启动WebRTC连接并且左上角会显示连接状态、帧率、码率等信息。如果你的场景有视角转动移动鼠标应该能看到响应。局域网内其他电脑访问需要把地址换成服务器的局域网IP比如http://192.168.0.25。这里有个很容易出问题的点Windows防火墙默认会拦截入站连接你要在防火墙高级设置里放行80端口、8888端口以及后面要说的WebRTC端口范围。我建议直接放行exe程序比放行端口更省事但如果你跑的是批处理启动Node.js就要手动加一条端口规则。3. 核心机制信令、WebRTC与编码调优3.1 信令服务器到底是干嘛的很多人把一个“像素流服务”想得过于神秘其实它就是一个双向的连接桥。浏览器不知道你的UE程序在哪个IP哪个端口UE程序也不知道浏览器在哪所以需要一个“中介”先让双方交换各自的地址和能力信息。在Pixel Streaming里这个中介就是SignallingWebServer。流程是这样的浏览器访问信令服务器的网页页面加载JS脚本。JS脚本通过WebSocket连接信令服务器发送一条“我想找一个像素流服务”的消息。信令服务器把这个请求转发给UE进程UE进程启动后也已经连上了信令服务器。UE进程收到请求后生成一个SDP应答通过信令服务器回传给浏览器。浏览器和UE进程开始P2P直连画面和输入数据不再经过信令服务器。这也是为什么信令服务器本身不会占用太多网络带宽真正吃带宽的是WebRTC媒体流。如果以后遇到公网一多就卡优先怀疑媒体流的码率和带宽而不是信令服务器。3.2 WebRTC连接建立的关键点WebRTC连接能不能建立成功取决于三件事网络可达性、端口通不通、编码格式是否匹配。先说编码格式浏览器端的WebRTC只认识VP8或H.264。UE5默认使用H.264但H.264有很多子profile有些浏览器只支持特定规范。在信令服务器的config.json里有一项叫PeerConnectionOptions可以在里面加H264 Profile: ConstrainedBaseline来兼容更多浏览器。再说端口WebRTC不是固定端口通信它会在一段端口范围内随机选择。UE自带的信令服务器配置了30000到30100作为媒体端口范围。所以局域网测试时如果开着防火墙需要把这个范围也放行不然就会出现“页面能打开但画面一直黑屏”的情况。常见的端口规划如下服务端口说明网页访问HTTP80浏览器访问入口信令 WebSocket443 或 8888浏览器和UE进程交换SDPUE流端进程监听8888UE进程连接的端口和信令服务器配置对应WebRTC媒体端口30000-30100音视频数据通路这一点很重要你在信令服务器里看到的8888端口并不是媒体流端口媒体端口是后面那一堆。很多人只放行了80和8888结果画面一直起不来就是因为30000端口被防火墙拦住了。3.3 编码性能与延迟调优延迟是像素流服务体验的核心指标。我实测下来局域网内从鼠标点击到画面反馈大概30~60ms属于“可以接受”的水平。如果感觉光标飘、操作肉优先检查以下几项。首先务必确认编码方式为硬件编码。软件编码x264画面质量好但编码延迟高十来秒之后延迟会越来越严重。UE启动日志里会打印编码器信息如果是“H.264 SW encoder”说明在软件编码。其次调整码率和分辨率。在启动参数里可以设置YourProject.exe -PixelStreamingBitrate10000000 -PixelStreamingFPS60 -Resolution1920x1080-PixelStreamingBitrate单位是bps10000000就是10Mbps。公网环境4~8Mbps局域网可以拉到15Mbps。-PixelStreamingFPS目标帧率。不要盲目设60如果场景本身只能跑到30帧设60只会浪费带宽。-Resolution画面分辨率要小于等于你项目里的渲染分辨率否则UE会缩放反而增加模糊。还有一个隐藏参数-PixelStreamingEncoderMinQP和-PixelStreamingEncoderMaxQP控制编码质量波动。如果画面在快速转动时出现马赛克可以把MaxQP调小一点比如26画质会好一些但码率也可能升高。网络层面尽量让客户端和服务器在同一网段。如果走公网优先选电信或联通机房且服务器要开通足够的上行带宽。延迟容易出现在跨运营商、跨地域的情况下可以使用RTC监测工具查看每个客户端的网络质量但这不是今天重点先不展开。4. 搭建过程中踩过的坑与排查技巧4.1 浏览器能打开但画面一直黑这个问题我遇到的最多90%集中在端口没放通或编码器不兼容。排查顺序如下先看信令服务器的日志有没有显示UE进程已经连接。如果日志里没有UE进程的ID说明UE自己压根没连上来需要检查-PixelStreamingIP和-PixelStreamingPort是否写对。再看UE进程命令行窗口有没有出现“New connection requested”之类的输出。如果出现了说明信令握手成功了黑屏多半是WebRTC媒体端口不通或浏览器不支持H.264。先试着放行30000~30100端口然后换Chrome或Edge试试。最后要看浏览器控制台按F12打开开发者工具在Console标签里能看到WebRTC报错。常见报错是Failed to set remote answer sdp这种情况多半是编码参数不匹配去信令服务器的peerConnectionOptions里改用ConstrainedBaseline然后重启。如果确实排查不出问题还有一个终极大招把UE启动参数里的-PixelStreamingEncoderHardware去掉让UE走软件编码。软件编码虽然慢但兼容性极高能快速区分到底是硬件编码的问题还是网络的问题。4.2 画面卡顿像幻灯片但并没有断卡顿的原因很多最常见的是视频码率不足。可以在测试页的左上角信息中看码率和帧率如果码率一直顶着上限说明场景运动过于剧烈带宽不够适当降低码率反而流畅因为强压会导致马赛克和延迟。另一种情况是GPU负载已经满了。你在服务器上如果还接着显示器打开任务管理器可以看到GPU占用如果是100%就要降低场景复杂度、限制帧率。我试过用-PixelStreamingMaxFPS30限制帧率GPU占用从95%降到70%客户端体验反而更稳定。最后检查网络延迟。局域网延迟一般不超过2ms如果用了WiFi路由器和干扰会导致延迟抖动。建议测试时用有线连接排除WiFi干扰。4.3 鼠标和声音问题鼠标点击位置不对、光标飘通常是浏览器全屏模式和客户端窗口比例不一致。Pixel Streaming支持把鼠标输入映射到UE场景但如果UE项目的分辨率是16:9浏览器窗口被拉伸到奇怪的比例输入坐标就会偏。解决办法是固定启动参数里的-Resolution并且在网页端也锁定宽高比。声音没有输出注意看UE项目里是否启用了音频。Pixel Streaming默认会推音频流但很多空场景没有加音频组件所以没声音属于正常。如果场景有声音但浏览器听不到检查网页是否被浏览器静音或者信令服务器配置中的音频编码没有启用。在PeerConnectionOptions里可以加audio direction: sendrecv强制开启。多用户并发时每个浏览器要连接一个独立的UE进程。如果你只有一个UE实例第二个人访问要么被卡在等待队列要么会直接把第一个人顶掉。这在后面的部署部分我会详细说。5. 从测试环境到正式部署还差这几步5.1 公网访问必须处理的三个问题如果只是局域网内部使用前面三步就够了。但要部署到公网还有其他要点。第一是TURN服务器。WebRTC默认走P2P直连但如果客户端和服务器在复杂的NAT网络后面直连很难建立。这时候需要一台TURN服务器作为中继。Pixel Streaming自带的信令服务器不带TURN功能需要单独部署coturn或使用云厂商的TURN服务。在信令服务器的config.json里配置iceServers加上TURN地址和账号密码。没有TURN服务器很多外网用户会出现卡在“正在连接”的问题。第二是端口映射和防火墙。公网部署时你不可能把整个30000~30100范围都暴露出去但WebRTC协议又必须要用这些端口。最省事的方案是购买云主机时直接在安全组里放行这些端口并且给信令服务器安排一个公网IP而不是做一对一的端口映射。第三是HTTPS。浏览器访问WebRTC接口时如果页面不是HTTPSChrome会限制很多功能。虽然http://localhost是特例但公网访问必须用HTTPS才能稳定。可以给信令服务器套一层Nginx把80端口的HTTPS证书代理到信令服务器的HTTP端口同时将WebSocket的WSS也代理过去。5.2 会话管理、鉴权与多人并发默认情况下任何人都可以访问你的像素流页面这对正式项目是不可接受的。Pixel Streaming提供了一套基于Token的鉴权机制叫做“Pixel Streaming Authenticator”。你可以写一个简单的登录页面用户登录后生成一次性的Token放到URL里信令服务器校验通过后才会建立连接。从运营角度看更常见的是后端接口动态创建UE进程。客户端点“开始体验”时后端启动一个带-PixelStreamingPlayerIdxxx的UE进程这个ID跟用户绑定网页端通过?PixelStreamingPlayerIdxxx匹配到对应的进程。这样每个人都有自己的独立实例互不影响。这种做法对服务器性能要求挺高一个UE进程大概会占用2~4个CPU核心和4~8GB内存GPU显存更是大头。如果场景复杂一块8GB显存的卡同时跑两个流就很吃力了。一般生产环境都是多机集群由调度服务器统一分配。个人项目可以先从单机两三路并发开始跑熟了再扩展。5.3 性能评估与硬件选型建议关于硬件选型我结合自己跑过的项目给个粗略参考。以一个中等复杂度的室内场景为例在UE5.3下1080P、30帧、硬件编码单个实例占用资源大概是资源占用情况NVIDIA RTX 3060显存占用约4GB编码器占用10%左右CPU4核8线程占用平均40%-60%内存8GB-12GB上行带宽4~8Mbps所以如果是3路并发一张RTX 3080或RTX 4060 Ti 8GB版本是起步。这里有个小技巧在服务器上可以禁用UE画面的本地预览也就是不显示那个窗口只做后台渲染能省一点CPU和GPU资源。用-PixelStreamingWindowHidden参数可以隐藏窗口。带宽估算也很简单并发路数乘以上行码率。10路并发每路6Mbps就需要60Mbps上行云主机带宽要选100Mbps档。带宽费用通常比GPU费用还高这是很多人忽略的预算项。最后分享两个小经验整个流程跑下来我最深的体会是Pixel Streaming的坑基本都在“网络”而不是“UE”。只要信令逻辑通了画面和交互的稳定性主要看端口、编码参数和带宽。所以建议你搭建的时候不要一上来就琢磨公网、TURN、鉴权这些先在局域网把最基础的“三步”跑通再逐步加复杂功能。另外强烈建议把启动命令写成一个bat脚本把IP、端口、码率这些参数固化下来否则每次手动敲命令很容易漏参数出问题都不知道差在哪。最后分享一个小技巧如果你需要临时排查画面异常在浏览器访问时URL后面加?Test然后按PageUp键可以打开Pixel Streaming内置的统计面板里面能看到帧率、码率、丢包率。发现丢包率高先别急着怀疑代码看看是不是某个端口被运营商标了优先级。这个面板信息比你在命令行窗口里猜要直观得多。