如何将3D相机输出的2DTexture流式传输至Web服务器（含iFrame的HTML站点）并分发至其他Unity客户端

全链路核心拆分逻辑 #

整体交互链路完全适配源端Unity采集→Web服务器转发→iFrame嵌入页面→多端Unity客户端拉流的需求，所有环节跳过冗余的转码和序列化开销，不存在需要定制开发的不可控组件。

源端Unity采集段实现要点 #

• 3D相机输出纹理的处理：先把3D相机绑定RenderTexture作为渲染目标，不要直接在CPU端读取纹理像素，这个操作会触发GPU到CPU的同步等待，单帧耗时占比超过60%。优先通过硬编码通道将纹理流压成H.264码流，控制单路码流的参数在1280*720@30fps，同画质下带宽仅为JPG帧传输的1/10不到，避免上行带宽被打满。
• C#与JS的跨端桥接适配：用Unity内置的jslib插件编写自定义通信层，替代自带的Application.ExternalCall同步阻塞调用：
  • 在C#侧暴露帧推送接口，编码完成的二进制帧直接通过指针传给JS层，绕过C#/JS之间的字符串序列化开销
  • iFrame嵌入场景下提前配置iFrame属性，添加allow="autoplay; media"权限，设置跨域消息白名单，避免CORS拦截桥接调用
• 帧推送的错误兜底：桥接层内置固定长度的帧队列，当网络抖动时自动做丢帧处理，不要无限缓存待发帧，避免端到端延迟随运行时间累加。

Web服务器与iFrame页面适配要点 #

• 服务器层采用轻量转发架构，优先支持HTTP-FLV/WebRTC DataChannel两种浏览器原生可解码的协议，不要引入需要额外插件才能播放的RTMP协议；为每路流配置2s时长的帧缓存，当多个客户端同时拉流时直接从缓存层做扇出分发，不用让源端Unity重复推送相同帧。
• iFrame嵌入的页面逻辑轻量化：JS层只负责两件事：一是接收服务器转发的视频帧，直接解码渲染到<canvas>元素；二是把canvas渲染的流通过captureStream()转成标准MediaStream格式，供下游拉流的Unity端消费，中间不做额外转码。
• 安全配置：iFrame不要设置无限制的sandbox权限，仅开放必要的媒体通信权限，跨域通信时校验来源域名，避免流被恶意站点盗拉。

远端Unity客户端拉流实现要点 #

• 针对不同部署形态的Unity客户端做适配：
  • WebGL打包的Unity客户端：直接通过JS桥接接收MediaStream对象，绑定到本地RawImage的纹理输入；每帧更新时加自动丢帧逻辑，当队列里积压超过2帧就丢弃最旧的帧，避免延迟累积
  • 原生桌面/移动端Unity客户端：直接用C#原生WebSocket客户端连接服务器的流地址，在本地硬解码H.264帧，映射为业务可用的2DTexture，不需要经过JS层中转
• 拉流端的参数对齐：和源端的编码参数保持一致，不要在拉流端做动态分辨率调整，否则会触发解码端的额外格式协商开销。

高频踩坑避坑提示 #

• 不要用Base64格式传输二进制帧，会额外增加33%的带宽开销，所有帧传输都走原始二进制通道
• 不要把源端采集的分辨率设置超过1080p，不然浏览器端的软解码延迟会从100ms以内跳到500ms以上，影响交互体验
• 跨iFrame通信时不要把Unity实例的全局引用直接暴露给父页面，必须做消息白名单校验，不然嵌入的页面可以直接调用Unity的任意公开方法，存在安全风险

内容的提问来源于stack exchange，提问作者Patrick