Part1前言 和官方臃肿不堪的像素流SDK相比,我们在官方的基础上做了大量的优化和精简,开发出了轻量、零依赖、开箱即用的软件套装,项目持续开发了2年,经受住了大量的压力测试,收获了许多社区文档和用户反馈 基于WebRTC 的像素流技术主要由 3 个网络节点组成,各司其职: 基于像素流的三维可视化技术以图中的 UE5、信令、前端这 3 个节点为主,再辅以 Web、代理、Stun 等可选节点,组成了整个云渲染的底层架构 ,各节点之间相互配合、监控、认证,为像素流的稳定性提供了全面的保护,各节点的分工如下: Part3示例:完整的像素流工程 # 安装 WebSocket npm install ws@8.5.0 # localhost:88" # 打开测试网页 start http://localhost:88/test.html Part4signal.js 信令服务器 特性 ●文件只有5KB,gzip压缩后只有3KB response = await ps.emitMessage(request); // 返回不稳定 Part11展望 接下来,我们准备兼容苹果IOS端,升级至UE5.1,希望大家帮忙提提PR、问题反馈,一起把像素流
像素流SDK 目录像素流SDK 组成 动机 Pixel Streamer 信令服务器 密码认证 nginx的wss代理 WebComponnets:Web组件API 生命周期控制 启动UE 限制连接人数 下面是开发过程中的一些核心理念 组成 像素流SDK由3个端组成,分别是: ·前端:浏览器 ·中间件:信令服务器,nodejs ·后端:UE4 其中后端是UE官方开发的C++插件,前端和中间件则是由我们开发 将这3个端一一启动(顺序无所谓),就能在浏览器中看到画面了。 这里我们定义了
如果想要使用网页访问这些模型资源内容,我们通常会使用官方的像素流,虽然这种方式可以实现网页访问,但是也存在一些问题和缺点。传统像素流1. 3. 适用类型,传统像素流只是作为UE的引擎插件,只支持UE的内容,像unity或者其他类型的软件都没办法支持使用。4. 在以上几种因素的影响下,传统的像素流满足不了一些使用者的需求,通常会采用新型的像素流送方式---点量像素流送。在上述几个影响的因素方面,点量像素流送是如何解决的?以下可供参考:1. 兼容性,点量像素流送像常规的主流浏览器都支持,包括谷歌、360、微信或iOS,都能轻松打开进行操作。2. 访问方面,点量像素流送在弱网环境下会自动匹配相适应的码率,达到稳定流畅的运行操作。3. 总的来说,这种新的像素流送方式能够解决传统像素流的痛点,并且应用支持的范围也较广,对于一些场景使用者来说大大减少了问题的存在,让使用更加方便。
https://xosg.github.io/PixelStreamer/ PixelStreamer官方中文README.md 3D 像素流: 虚幻引擎 WebRTC 核心组件 和 EpicGames 官方的像素流 SDK 相比,我们开发出了更轻量的像素流 SDK,包含 2 个文件:前端组件(WebComponents API)外加信令服务器(NodeJS)。 所有依赖升级到最新版,包括浏览器、NodeJS、UE4、像素流。 网络问题:是否能 ping 通,是否开了防火墙(可用 test/unreal.html 测试)。 高频请求导致 UE4 崩溃。 UE 端通过检查启动命令行来判断像素流的相关信息。 不需要像素流的时候只要把 video 移出 DOM 即可,不用手动关闭 WebRTC。 访问外网时,需要添加 stun。 像素流 2 个 js 文件的版本号和虚幻引擎同步,目前是 4.27.0。 在任务管理器中通过“命令行”一列获悉 UE4 程序的启动参数。
Programs\PixelStreaming\WebServers\SignallingWebServer 即信令网页服务器,删除了其中90%以上的无用代码和库,解决了许多bug,成就了一个超轻量,上手即用的像素流前端库和信令服务器 先复习一下WebRTC技术,相关内容推荐: 《虚幻引擎的像素流技术》 《WebRTC:理论基础、行业地位、网络架构》 《WebRTC安全问题:私有IP与mDNS》 类型 即时性 数据量 场景 通讯 低 小 http网页、文件传输、Email 即时通讯 高 小 聊天室、电话、RTS网络游戏 即时音视频通讯 高 大 视频通讯、远程桌面、3D像素流 WebRTC主要是为了解决“即时音视频通讯”的需求的 像素流协议 PixelStreamer最核心的基础组件是虚幻引擎像素流插件定义的“像素流协议”,其中分2个部分,分别是基于DataChannel的二进制消息格式,和基于WebSocket和信令服务器之间的 目前主流的会话凭证是利用localStorage+Authoriation头部实现JWT的存储,很遗憾,这3样东西都是文本格式的,如果想要存储为二进制格式,需要另3样技术:CachesAPI、http2.0
Gibson在1950年首先提出来的,是空间运动物体在成像平面上的像素运动的瞬时速度,是利用图像序列中像素的变化以及相邻帧之间的相关性,来找到上一帧跟当前帧的像素点之间存在的对应关系,从而计算出相邻帧之间像素点的运动信息的一种方法 稠密光流描述图像每个像素向下一帧运动的光流。为了方便表示,使用不同的颜色和亮度表示光流的大小和方向,如下图的不同颜色。 随后出现了PWC[3]、RAFT[4]等一系列深度学习模型,并不断刷新EPE(光流估计的评价指标)。需要注意的是,基于深度学习的光流估计算法都是针对稠密光流估计问题。 上图对比发现,椅子的相对位置有变化 光流估计评价指标 EPE(Endpoint Error)是光流估计中标准的误差度量,是预测光流向量与真实光流向量的欧氏距离在所有像素上的均值(越低越好)。 RAFT模型搭建 RAFT由3个主要组件组成: 从两个输入图像img1和img2中提取每像素特征的特征编码器(Feature Encoder)以及仅从img1中提取特征的上下文编码器(Context
像素流与WebRTC 像素流是虚幻引擎利用WebRTC技术将视频流实时传输到浏览器的流程,像素流由3个部分组成: 发送方:虚幻引擎后端的像素流官方插件,用于发送实时视频流 中间方:用NodeJS启动的信令服务器 ,用于在发送方和接收方之间转发信令,协助建立P2P 接收方:浏览器前端用JavaScript调用WebRTC的功能,接受视频流 像素流是WebRTC的一个子集,因为WebRTC包含mesh、sfu、mcu 等多种复杂架构,但数字大桥使用的像素流只用到了最简单的p2p架构,即一个虚幻引擎后端向多个浏览器前端传输像素流。 3个端的启动方式如下: 信令服务器启动参数 选项 默认值 作用 player 88 浏览器用户端口 unreal 8888 虚幻引擎端口 token insigma WebSocket认证凭证 limit void 允许传输音频 RenderOffScreen void 后台运行 graphicsadapter 自然数 选择GPU AllowPixelStreamingCommands void 允许调试像素流
实时云渲染(Real-time Rendering)技术作为通用引擎的流送技术,比像素流推出还要早几年。 如何使用像素流服务UE的像素流送Pixel Streaming通过WebRTC协议将渲染后的画面(像素数据)实时编码为视频流,传输到客户端(如浏览器)。 像素流的技术架构图如下。需要将项目作为打包应用程序运行时、或使用 Standalone Game 选项在虚幻引擎中启动时才能使用像素流送插件。总流程至少包括如下四步:1. 集成像素流插件在UE引擎中找到像素流送(Pixel Streaming) 插件并勾选 启用(Enabled) 框,重启项目修改应用。 2.如何使用实时云渲染服务实时云渲染是一种更广义的技术,通常指在云端完成3D场景的渲染,并将渲染结果以视频流的形式传输到客户端。
在之前《UE像素流技术:边缘计算与RTC架构》一文中论证了WebRTC的基本原理,以及WebRTC与虚幻引擎结合使用的可行性。 之后在《像素流协议》一文中介绍了虚幻引擎基于WebRTC定义的一套像素流协议,这套协议本身又分成2部分: 基于DataChannel的二进制格式:用于UE4与前端通讯 基于WebSocket的JSON格式 PixelStreamer是一个轻量级的前端像素流SDK(另赠送信令服务),对接的是虚幻的像素流插件。本项改编自虚幻的原版本,但删除了所有但依赖库和垃圾代码,同时合并成一个JS模块,开箱即用。
点量小芹接到部分用户反馈,使用UE4做的模型,在使用像素流技术实现多终端支持时,在微信和小程序中会出现不能全屏的问题,偶尔还会出现在iOS手机中卡死的问题。找了很多方案,也没有解决这个问题。 其实在很早之前小芹和大家分享过,像素流技术不是一个完善的产品,是从理论上验证了可行性,如果真想用到实际的项目中,还需要做很多技术开发和学习,尤其是在大并发的项目要求中。 图片点量云渲染方案,针对像素流技术中可能存在的问题,做了深入研究,并将其产品化。 其实除了这个问题,在使用像素流的时候,还有客户遇到其他的比如并发无法做到很大,而且多块显卡的使用不能负载均衡,显卡增加一定数量后就不会在被启用。这些都是在实际中遇到的,而负载均衡在大并发中是很重要的。 其实不仅仅是UE4或者U3D的模型,Windows下的大部分程序都可以云渲染。而且对于网络环境没有特殊的要求,局域网、公网或者私有网络均可实现部署。如果在使用像素流技术的过程中遇到疑问,欢迎交流。
一般为屏幕的“宽×高”,例如分辨率有720×1280的手机设备,表示此屏幕在宽度方向有720个像素点,在高度方向有1280个像素点。 屏幕尺寸(英寸inch) 按屏幕对角测量的实际物理尺寸。 屏幕密度(DPI) 就是每英寸的像素点数,数值越高当然显示越清晰,通常 与“正常”或“高”密度屏幕相比,“低”密度屏幕在给定物理区域的像素较少。 密度无关像素 (dp) 在定义 UI 布局时应使用的虚拟像素单位,用于以密度无关方式表示布局维度 或位置。 密度无关像素等于 160 dpi 屏幕上的一个物理像素,这是 系统为“中”密度屏幕假设的基线密度。在运行时,系统 根据使用中屏幕的实际密度按需要以透明方式处理 dp 单位的任何缩放 。 dp 单位转换为屏幕像素很简单: px = dp * (dpi / 160)。 例如,在 240 dpi 屏幕上,1 dp 等于 1.5 物理像素。
然后根据上面的公式得出: 总设备像素 = 总 css 像素 2 = 375 667 2 。然而实际上总的设备像素是 750 x 1334 个像素点。 其实 DPR = 设备像素 / 设备独立像 (是在同一个方向,一维的) 设备像素(DP) 定义: 设备像素又称物理像素,其尺寸大小是不会变的,从显示屏从工厂出来的那刻起,物理像素点就不会变了。 设备独立像素(DIP) 定义:设备独立像素又称逻辑像素,其尺寸大小是相对的。是一种物理测量单位,基于计算机控制的坐标系统和抽象像素。 其实这个也很好理解,逻辑像素嘛,不就是我们平时用的 CSS 像素么,在 Android 中交设备独立像素。所以 设备独立像素 = CSS 像素。 设备像素比(DPR) 设备像素比 DPR(devicePixelRatio) 是默认缩放为100%的情况下,设备像素和CSS像素的比值。
UE4官方从4.21版嵌入像素流送插件Pixel Streaming,到了4.24版本插件已经做了很大改善,目前使用像素流技术可以在用户非本机的电脑或者服务器上,远程运行虚幻的应用程序。 说的直白些,通过网页就可以控制服务器上的程序,且像素流可以将在服务器端的渲染结果,直接在终端以视频的形式展示出来,有点像在视屏网站上观看视频,但二者却有本质的区别: 1、在终端看到的虚幻引擎画面流是云端实时渲染帧和音频的效果 C、延迟低 像素流送使用WebRTC点对点通信框架,使用者和虚幻引擎应用程序之间的延迟很低。点量软件像素流产品可以做到5-30ms的延迟,和本地安装的效果几乎一样。 像素流只支持UE4的内容,点量像素流产品是支持所有的内容,不止UE4、Unity,还包括各种软件,比如3DMax、BIM、Flash等。 所以对于UE4像素流使用中浏览器兼容性等问题合作也许是个不错的选择。 像素流应用领域.png
UE4的像素流自4.21推出Beta版后,我们根据官方文档分别在局域网和公有云部署像素流应用进行测试,对跨不同平台、画质、延迟等特性一一测试。 同时我们关注到目前市场上有点量云流化可以提供内容流送的服务,测试后要比UE4像素流更产品化,做的已经比较成熟了。 下面简单介绍云流化对比UE4像素流的优势:1、测试中发现像素流有一些浏览器兼容性问题,比如iOS下的微信、部分chrome版本的浏览器,会出现打不开的问题。 2、像素流是作为引擎的插件,只支持UE4的内容,点量云流化是支持所有的内容,不止UE4、Unity,还包括各种软件,比如3DMax、Flash等。 3、像素流只是引擎的一个功能,缺少产品化功能和服务,比如负载均衡、测速调度、自动更新、发布、后台统计报表、用户状态监控、报警等机制,后续完善需要不少精力和时间。4、像素流没有客户端模式,只支持网页版。
很多开发者在UE程序像素流推流的过程中,会遇到插件1和2版本不兼容、依托WebRTC传输数据字节有限,以及推流并发数受限等问题,以下逐一分析解答。 像素流1和2插件版本迁移问题UE像素流插件支持完成基础的三维程序推流到网页的过程,可以实现单机单并发的演示效果。 实时云渲染技术从底层架构完全兼容各类2D/3D开发引擎,对UE程序无要求,同时支持像素流送1和2,也可无需集成像素流插件,即可实现一键推流,采用松耦合的方式降低风险和开发变更的工作量,UE开发者专注于3D 像素流运行多个实例数量受限根据UE官方文档显示,针对不同系列的NVIDIA显卡,UE像素流推流数量有所不同。 但是Quadro和Tesla的专业级显卡在图形渲染能力和性价比层面远远低于消费级的GeForce显卡,在UE像素流框架下无法达成平衡。
为了实现UE引擎开发的3D/XR程序推流,绝大多数开发者会研究像素流送(Pixel Streaming)的使用方法,并尝试将插件集成在程序中。对于短时、少并发、演示场景而言,像素流送可以满足基本需求。 当3D/XR项目进入落地交付周期后,像素流送本身的弊端凸显,实时云渲染方案是更好的选择。Deepseek初步分析了二者的技术路线,给出了一定的结论匹配:1. 技术原理像素流送(Pixel Streaming)原理: UE的Pixel Streaming通过WebRTC协议将渲染后的画面(像素数据)实时编码为视频流,传输到客户端(如浏览器)。 实时云渲染(Real-time Cloud Rendering)原理: 实时云渲染是一种更广义的技术,通常指在云端完成3D场景的渲染,并将渲染结果以视频流的形式传输到客户端。 特征对比特性像素流送(Pixel Streaming)实时云渲染(Real-time Cloud Rendering)渲染位置服务器端服务器端协议WebRTCWebRTC、RTMP、SRT等客户端支持浏览器
在使用UE/Unity等引擎开发的3D/XR应用时,如何解决大并发商用场景,是一直以来存在的问题。 实时云渲染技术可以解决这一问题,尤其针对高精度、强交互的UE程序,解决了像素流技术无法集群部署、无法定制二次开发等问题,通过PaaS平台级部署,实现多渲染集群的平台级运维。 LarkXR是由Paraverse平行云自主研发的去中心化实时云渲染平台,以其卓越的性能和丰富完备的功能插件,引领3D/XR云化行业风向标。 LarkXR适用于3D/XR开发者、设计师、终端用户等创新用户,可以在零硬件负担下,轻松实现超高清低时延的3D交互体验,覆盖行业包括虚拟仿真、数字孪生、展览展示、元宇宙、设计协作等,只需要一台普通设备即可触达云端算力的巅峰 ,畅游3D虚拟世界。
而作为云推流实时渲染厂家,这正是我所擅长的。 具体实现办法是:将数字人模型放在服务器端,通过点量云流渲染程序,获得可以在网页使用3D数字人模型的链接。注意数字人运行需要的GPU和CPU并没有被省略,只不过由原来需要用户侧提供变成了服务器端提供。 但制作越是精美的数字人,在网页上直接使用越是困难,小芹之前有了解过有些数字人在4090显卡也只能同时运行2-3个,而这个显卡配置对于C端客户来说还是很难实现的。 场景3:大屏数字人讲解 在文旅等场景下,使用大屏数字人形象进行讲解,因为先进的技术可能会更好的吸引用户参与。 而实时云渲染推流的方案,可以在景区机房配置高性能的服务器,将数字人模型推流后再网页、手机平板等设备上使用,可以景区多个热门景点使用,可以更好的满足为游客讲解的需要。
设备像素和 CSS 像素设备像素又称为 物理像素, 是 "物理屏幕" 上真实存在的发光点,只有屏幕一经出厂就固定不会改变。 CSS 像素又称为 逻辑像素,是编程世界中虚拟的东西, 我们通过代码设置的像素都是逻辑像素。 图片图片例如: iPhone3G / iPhone3GS 3.5英寸 / 逻辑像素 320 480 / 设备像素 320 480:图片iPhone4 / 4S 3.5英寸 / 逻辑像素 320 480 在 PC 端,1个 CSS 像素往往都是对应着电脑屏幕的 1 个物理像素, 所以我们无需关心 PC 端的 CSS 像素和设备像素问题,在手机端,最开始其实 1 个 CSS 个像素也是对应着手机屏幕的 1 iPhone4 的屏幕尺寸却没有变化,但是像素点却多了一倍,这就导致了在 1 个CSS个像素等于 1 个物理像素的手机上, 我们设置1个CSS像素只会占用 1 个物理像素,而在1个CSS个像素不等于1个物理像素的手机上
支持超写实数字人智能交互、无需第三方软件即可实现快速直播推流,将视频融合与3D场景无缝对接。实时云渲染LarkXR平台支持公有云托管和私有化部署。 35 UE程序通过网页超低延时交互04:15 LarkXR开发者平台托管UE应用,一键推流到网页端05:30 如何开发并使用中文输入和语音控制功能05:50 超写实数字人云渲染案例,无需第三方推流软件即可直播