PixelStreamingInfrastructure信令协议权威参考20种WebSocket消息类型逐条拆解v1.1【免费下载链接】PixelStreamingInfrastructureMoved to: https://github.com/EpicGamesExt/PixelStreamingInfrastructure项目地址: https://gitcode.com/gh_mirrors/pix/PixelStreamingInfrastructurePixelStreamingInfrastructure 是 Epic 开源的Pixel Streaming像素流送基础设施它的核心就是一套简洁的 WebSocket 信令协议当前版本 v1.1.0。整套协议由 4 类角色之间、29 种消息类型构成负责在浏览器播放器与 Unreal Engine 引擎之间完成握手—建连—订阅—流媒体协商—断开的全部信令流程。本文逐条拆解每一种消息的作用、参数与发送方并给出完整消息时序帮你快速建立 Pixel Streaming 信令机制的全景认知。完整协议文档见SignallingProtocol.md30秒看懂信令协议中的 4 个角色在拆解消息之前先理解协议中的 4 个术语所有消息都围绕它们流转| 角色 | 英文 | 职责 | | :- | :- | :- | | 信令服务器 | Signalling Server | 路由消息、管理新连接是整条链路的中枢 | | 推流端 | Streamer | 输出媒体流的实体Unreal Engine 应用 | | ️ 播放器 | Player | 消费流的浏览器端可通过数据通道与游戏双向交互 | | 转发单元 | SFU | 特殊的 Player接收一路流再转发给多个 Player支持按网络质量选择分辨率simulcast |另外两个高频名词SDP会话描述协议用于两端协商 WebRTC 媒体连接和ICE Candidate描述 WebRTC 与远端设备建立连通性所需的路由信息。完整信令时序一次流会话经历了什么官方文档给出了标准消息序列整个建连过程可以概括为 5 步连接阶段Streamer 和 Player 分别向信令服务器发起连接服务器先下发configSTUN/TURN 配置身份阶段服务器向 Streamer 发identify请求身份Streamer 回endpointId自报 ID订阅阶段Player 发listStreamers查询可用流收到streamerList后发subscribe订阅服务器随即向 Streamer 推送playerConnectedWebRTC 协商阶段Streamer 发offer→ Player 回answer→ 双方交换iceCandidate之后浏览器与引擎直连断开阶段任一方断开时服务器向对端推送playerDisconnected/streamerDisconnected{type: subscribe, streamerId: streamer_01}上面这样一条字符串化的 JSON 就是协议消息的标准形态——所有消息都以字符串化 JSON 传输部分参数本身也是 JSON 字符串。Player 发送的 9 种消息浏览器 → 服务器| 消息类型 | 作用 | 关键参数 | | :- | :- | :- | |offer| 向已订阅的 Streamer 发送 SDP offer由浏览器主导建连 |sdp| |answer| 回应 Streamer 的 offer把 SDP answer 传回 |sdp| |iceCandidate| 将 ICE 候选项转发给 StreamerWebRTC 协商的一部分 |candidate| |listStreamers| 请求当前在线的所有 Streamer 列表服务器回streamerList | 无 | |subscribe| 订阅指定 ID 的流是发起会话的前置动作 |streamerId| |unsubscribe| 退订当前流必须先 subscribe 过 | 无 | |dataChannelRequest| 告知 SFU本 Player 需要与 Streamer 建立数据通道 | 无 | |peerDataChannelsReady| 告知 SFU本 Player 已准备好协商数据通道 | 无 | |stats| 把浏览器侧统计信息上报服务器会打印到控制台 |data| 新手提示subscribe和offer/answer的先后顺序是排错重点——必须先订阅成功再发offer或接收answer否则消息会被忽略。Signalling Server 发送的 9 种消息服务器 → 各端| 消息类型 | 接收方 | 作用 | | :- | :- | :- | |config| Streamer / Player | 下发 peer connection 选项STUN、TURN 服务器地址等 | |identify| Streamer | 请求 Streamer 自报身份等待其回复endpointId| |streamerList| Player | 回应listStreamers返回在线 Streamer 的ids数组 | |streamerIDChanged| Player | 通知已订阅的 Streamer 换了 ID便于自动重连跟对目标 | |playerConnected| Streamer | 有新 Player 订阅附带playerId、dataChannel、sfu、sendOffer四个标志位 | |playerDisconnected| Streamer | 某 Player 退订或断开附带playerId| |playerCount| Player | 当前连接到该服务器的 Player 总数旧行为仅作展示 | |streamerDisconnected| Player | 通知所有 PlayerStreamer 已掉线 | |pong| Streamer | 回应 Streamer 的ping原样带回时间戳用于测延迟 |Streamer 发送的 7 种消息引擎 → 服务器| 消息类型 | 作用 | 关键参数 | | :- | :- | :- | |endpointId| 自报唯一 ID。注意为兼容旧版未回复identify的 Streamer 会被临时分配__LEGACY__ID |id| |offer| 向指定 Player 发起 SDP offer开始 WebRTC 协商 |playerId、sdp| |answer| 回应指定 Player 的 offer |playerId、sdp| |iceCandidate| 向指定 Player 发送 ICE 候选项 |playerId、candidate| |ping| 保活心跳触发服务器的pong响应 |time时间戳 | |disconnectPlayer| 请求服务器把某个 Player 踢下线如游戏内强制断开 |playerId、reason| |layerPreference| SFU 场景下为某 Player 指定偏好的空间/时间层用于强制切换画质 |playerId、spatialLayer、temporalLayer|SFU 发送的 4 种消息转发单元专属当观众数量多到 Streamer 的编码资源扛不住时就引入 SFU它消费一路流再按各端网络状况智能转发同时支持 simulcast 多档画质。| 消息类型 | 作用 | 关键参数 | | :- | :- | :- | |offer| 向指定 Player 发起 SFU↔Player 之间的 WebRTC 协商 |playerId、sdp| |answer| 回应 Streamer 的 offer |sdp| |peerDataChannels| 告诉 Player 用哪两条数据通道与 Streamer 收发数据 |playerId、sendStreamId、recvStreamId| |streamerDataChannels| 要求 Streamer 为某 Player 打开对应数据通道 |playerId、sendStreamId、recvStreamId|SFU 的运行逻辑可参考其源码 sfu_server.js其中可见它连上信令服务器后会依次发送endpointId与listStreamers拿到列表后自动subscribe第一个流。前端源码速览消息类型枚举在哪找浏览器端的协议实现集中在 Frontend 库的 WebSockets 模块三个文件值得对照阅读接收消息类型枚举与结构MessageReceive.ts ——MessageRecvTypes定义了前端会收到的config、streamerList、offer、answer、iceCandidate、ping等类型发送消息类型枚举与结构MessageSend.ts ——MessageSendTypes定义了subscribe、unsubscribe、pong、dataChannelRequest等类型并提供payload()方法把消息序列化默认消息处理注册SignallingProtocol.ts ——setupDefaultHandlers为每种接收消息注册回调未注册的类型会直接忽略并报错信令服务器端的路由逻辑则在 cirrus.js 中实现。版本规则与兼容性要点协议采用语义化版本升级前先看这三条规则来自 SignallingProtocol.md主版本号破坏性变更如新增必填消息/字段、删除现有消息次版本号独立的新增消息向后兼容修订号在现有消息类型中新增的非破坏性字段两个容易踩坑的兼容点__LEGACY__临时 ID老版本 Streamer 可以不回复identify服务器会临时分配__LEGACY__ID 让它继续工作若它迟到的endpointId到达后服务器会向已订阅的 Player 推送streamerIDChanged前端据此保持正确的订阅目标playerConnected的sendOffer标志浏览器会提前声明我要发 offer还是等 Streamer 发 offer避免双方都发 offer 导致协商失败快速排错清单 ️画面一直转圈不出流检查subscribe是否成功、offer/answer顺序是否正确、config中的 TURN 配置是否可达多个 Streamer 连不上确认每个 Streamer 都发送了唯一的endpointId观众过多卡顿考虑启用 SFU simulcast用layerPreference控制画质分层连接频繁掉线观察ping/pong心跳与streamerDisconnected推送排查网络层掌握以上 29 种消息的分工与时序你就具备了阅读和扩展 Pixel Streaming 信令链路的全部基础知识——无论是自定义消息类型、接入多流部署还是排查建连故障都可以直接对照本文的表格逐条定位。【免费下载链接】PixelStreamingInfrastructureMoved to: https://github.com/EpicGamesExt/PixelStreamingInfrastructure项目地址: https://gitcode.com/gh_mirrors/pix/PixelStreamingInfrastructure创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PixelStreamingInfrastructure信令协议权威参考：20+种WebSocket消息类型逐条拆解（v1.1）
PixelStreamingInfrastructure信令协议权威参考20种WebSocket消息类型逐条拆解v1.1【免费下载链接】PixelStreamingInfrastructureMoved to: https://github.com/EpicGamesExt/PixelStreamingInfrastructure项目地址: https://gitcode.com/gh_mirrors/pix/PixelStreamingInfrastructurePixelStreamingInfrastructure 是 Epic 开源的Pixel Streaming像素流送基础设施它的核心就是一套简洁的 WebSocket 信令协议当前版本 v1.1.0。整套协议由 4 类角色之间、29 种消息类型构成负责在浏览器播放器与 Unreal Engine 引擎之间完成握手—建连—订阅—流媒体协商—断开的全部信令流程。本文逐条拆解每一种消息的作用、参数与发送方并给出完整消息时序帮你快速建立 Pixel Streaming 信令机制的全景认知。完整协议文档见SignallingProtocol.md30秒看懂信令协议中的 4 个角色在拆解消息之前先理解协议中的 4 个术语所有消息都围绕它们流转| 角色 | 英文 | 职责 | | :- | :- | :- | | 信令服务器 | Signalling Server | 路由消息、管理新连接是整条链路的中枢 | | 推流端 | Streamer | 输出媒体流的实体Unreal Engine 应用 | | ️ 播放器 | Player | 消费流的浏览器端可通过数据通道与游戏双向交互 | | 转发单元 | SFU | 特殊的 Player接收一路流再转发给多个 Player支持按网络质量选择分辨率simulcast |另外两个高频名词SDP会话描述协议用于两端协商 WebRTC 媒体连接和ICE Candidate描述 WebRTC 与远端设备建立连通性所需的路由信息。完整信令时序一次流会话经历了什么官方文档给出了标准消息序列整个建连过程可以概括为 5 步连接阶段Streamer 和 Player 分别向信令服务器发起连接服务器先下发configSTUN/TURN 配置身份阶段服务器向 Streamer 发identify请求身份Streamer 回endpointId自报 ID订阅阶段Player 发listStreamers查询可用流收到streamerList后发subscribe订阅服务器随即向 Streamer 推送playerConnectedWebRTC 协商阶段Streamer 发offer→ Player 回answer→ 双方交换iceCandidate之后浏览器与引擎直连断开阶段任一方断开时服务器向对端推送playerDisconnected/streamerDisconnected{type: subscribe, streamerId: streamer_01}上面这样一条字符串化的 JSON 就是协议消息的标准形态——所有消息都以字符串化 JSON 传输部分参数本身也是 JSON 字符串。Player 发送的 9 种消息浏览器 → 服务器| 消息类型 | 作用 | 关键参数 | | :- | :- | :- | |offer| 向已订阅的 Streamer 发送 SDP offer由浏览器主导建连 |sdp| |answer| 回应 Streamer 的 offer把 SDP answer 传回 |sdp| |iceCandidate| 将 ICE 候选项转发给 StreamerWebRTC 协商的一部分 |candidate| |listStreamers| 请求当前在线的所有 Streamer 列表服务器回streamerList | 无 | |subscribe| 订阅指定 ID 的流是发起会话的前置动作 |streamerId| |unsubscribe| 退订当前流必须先 subscribe 过 | 无 | |dataChannelRequest| 告知 SFU本 Player 需要与 Streamer 建立数据通道 | 无 | |peerDataChannelsReady| 告知 SFU本 Player 已准备好协商数据通道 | 无 | |stats| 把浏览器侧统计信息上报服务器会打印到控制台 |data| 新手提示subscribe和offer/answer的先后顺序是排错重点——必须先订阅成功再发offer或接收answer否则消息会被忽略。Signalling Server 发送的 9 种消息服务器 → 各端| 消息类型 | 接收方 | 作用 | | :- | :- | :- | |config| Streamer / Player | 下发 peer connection 选项STUN、TURN 服务器地址等 | |identify| Streamer | 请求 Streamer 自报身份等待其回复endpointId| |streamerList| Player | 回应listStreamers返回在线 Streamer 的ids数组 | |streamerIDChanged| Player | 通知已订阅的 Streamer 换了 ID便于自动重连跟对目标 | |playerConnected| Streamer | 有新 Player 订阅附带playerId、dataChannel、sfu、sendOffer四个标志位 | |playerDisconnected| Streamer | 某 Player 退订或断开附带playerId| |playerCount| Player | 当前连接到该服务器的 Player 总数旧行为仅作展示 | |streamerDisconnected| Player | 通知所有 PlayerStreamer 已掉线 | |pong| Streamer | 回应 Streamer 的ping原样带回时间戳用于测延迟 |Streamer 发送的 7 种消息引擎 → 服务器| 消息类型 | 作用 | 关键参数 | | :- | :- | :- | |endpointId| 自报唯一 ID。注意为兼容旧版未回复identify的 Streamer 会被临时分配__LEGACY__ID |id| |offer| 向指定 Player 发起 SDP offer开始 WebRTC 协商 |playerId、sdp| |answer| 回应指定 Player 的 offer |playerId、sdp| |iceCandidate| 向指定 Player 发送 ICE 候选项 |playerId、candidate| |ping| 保活心跳触发服务器的pong响应 |time时间戳 | |disconnectPlayer| 请求服务器把某个 Player 踢下线如游戏内强制断开 |playerId、reason| |layerPreference| SFU 场景下为某 Player 指定偏好的空间/时间层用于强制切换画质 |playerId、spatialLayer、temporalLayer|SFU 发送的 4 种消息转发单元专属当观众数量多到 Streamer 的编码资源扛不住时就引入 SFU它消费一路流再按各端网络状况智能转发同时支持 simulcast 多档画质。| 消息类型 | 作用 | 关键参数 | | :- | :- | :- | |offer| 向指定 Player 发起 SFU↔Player 之间的 WebRTC 协商 |playerId、sdp| |answer| 回应 Streamer 的 offer |sdp| |peerDataChannels| 告诉 Player 用哪两条数据通道与 Streamer 收发数据 |playerId、sendStreamId、recvStreamId| |streamerDataChannels| 要求 Streamer 为某 Player 打开对应数据通道 |playerId、sendStreamId、recvStreamId|SFU 的运行逻辑可参考其源码 sfu_server.js其中可见它连上信令服务器后会依次发送endpointId与listStreamers拿到列表后自动subscribe第一个流。前端源码速览消息类型枚举在哪找浏览器端的协议实现集中在 Frontend 库的 WebSockets 模块三个文件值得对照阅读接收消息类型枚举与结构MessageReceive.ts ——MessageRecvTypes定义了前端会收到的config、streamerList、offer、answer、iceCandidate、ping等类型发送消息类型枚举与结构MessageSend.ts ——MessageSendTypes定义了subscribe、unsubscribe、pong、dataChannelRequest等类型并提供payload()方法把消息序列化默认消息处理注册SignallingProtocol.ts ——setupDefaultHandlers为每种接收消息注册回调未注册的类型会直接忽略并报错信令服务器端的路由逻辑则在 cirrus.js 中实现。版本规则与兼容性要点协议采用语义化版本升级前先看这三条规则来自 SignallingProtocol.md主版本号破坏性变更如新增必填消息/字段、删除现有消息次版本号独立的新增消息向后兼容修订号在现有消息类型中新增的非破坏性字段两个容易踩坑的兼容点__LEGACY__临时 ID老版本 Streamer 可以不回复identify服务器会临时分配__LEGACY__ID 让它继续工作若它迟到的endpointId到达后服务器会向已订阅的 Player 推送streamerIDChanged前端据此保持正确的订阅目标playerConnected的sendOffer标志浏览器会提前声明我要发 offer还是等 Streamer 发 offer避免双方都发 offer 导致协商失败快速排错清单 ️画面一直转圈不出流检查subscribe是否成功、offer/answer顺序是否正确、config中的 TURN 配置是否可达多个 Streamer 连不上确认每个 Streamer 都发送了唯一的endpointId观众过多卡顿考虑启用 SFU simulcast用layerPreference控制画质分层连接频繁掉线观察ping/pong心跳与streamerDisconnected推送排查网络层掌握以上 29 种消息的分工与时序你就具备了阅读和扩展 Pixel Streaming 信令链路的全部基础知识——无论是自定义消息类型、接入多流部署还是排查建连故障都可以直接对照本文的表格逐条定位。【免费下载链接】PixelStreamingInfrastructureMoved to: https://github.com/EpicGamesExt/PixelStreamingInfrastructure项目地址: https://gitcode.com/gh_mirrors/pix/PixelStreamingInfrastructure创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考