基于浏览器客户端的流式渲染技术难点一览

更新日期: 2019-07-23阅读: 2.1k标签: 客户端

流式渲染技术,不同于传统意义上前端领域的服务端渲染(即 SSR),指的是云端性能强劲的机器进行画面渲染,将渲染完成的数据传送至客户端,客户端只负责播放及处理和上传用户输入信号至服务端的一种技术,谷歌的云游戏平台即是使用案例之一。在开源社区也有一些相关的方案,在拜读了 Parsec 公司的这篇博文——A Look at Game Streaming Tech in the Browser后,对整个技术体系中尤其是客户端(此处即浏览器)方面可能遇到的难点有了一个初步的认识,以下是一些相关的记录。


总体流程

  1. 通过 WebRTC 技术实现点对点(更常见的说法:P2P)连接;
  2. 将客户端配置发送至服务端,初始化流;
  3. 开始接收服务端发来的视频、音频及控制信息;
  4. 使用 Opus 音频格式对音频进行解码并通过 Web Audio api 播放;
  5. 使用 Media Source Extensions 将视频内容塞进 <video> 元素中;
  6. 采集输入事件,将其打包为二进制形式并发送至服务端。


网络

浏览器中的 P2P 连接只能依赖 WebRTC 实现,WebSockets 不适合的原因是其在 NAT 遍历及基于 TCP 的拥塞控制等多方面存在劣势。parsec 的 web 客户端使用 RTCDataChannels 与服务端通信。RTCDataChannel 被 UDP 封装于 STCP 流中。出于安全考虑,STCP 流又被 DTLS 封装。

NAT 遍历和 P2P 的初次连接(后来发现其可以归结为 UDP 穿孔过程中的一部分,就是一个简单的 STUN ping/pong)在技术实现上很复杂。初次握手需要预先交换安全凭证,这一操作通过 WebSocket 发送信号实现。

parsec 的原生客户端采用了自己基于 UDP 封装的 BUD 协议。出于开放心态,web 客户端使用了默认的 DTLS/SCTP。虽然可以保证理想状况下的使用,但其显然没有 BUD 协议来的鲁棒性好,所以后期可能会被 BUD 替换。


视频

在浏览器中(实际上只在 Chrome 中),我们使用 Media Source Extensions 将视频帧装载进 html <video> 元素。Chrome 为 MSE 实现了『低延迟』模式,该模式使用视频流推送模型以支持任意低延迟视频流。


音频

音频以原始 Opus 编码格式传入,然后通过由 Web Assembly 编译而来的 Opus 库进行解码,最后由 Web Audio API 播放。Chrome 在 70 版本后会支持通过 MSE 处理 mp4/opus,采用这一方式将是更好的解决方案,实现上就类似视频推送,只不过是推送到了 <audio> 元素中。


输入/信号

输入事件(包括键盘、鼠标、游戏手柄)以及任意信息(光标、对话)都在各自信道处理。各种信息被打包为二进制格式发送至服务端。


个人总结

  1. 网络
    网络是非常重要的一点,关系到是否能够保证整个应用正常使用。为了适应流式渲染技术对网络高吞吐、零缓冲的特点,可能需要对现有网络协议进行改造(主要针对 UDP)。此外,公网环境下需要面对的 NAT 遍历问题,如果前期只考虑局域网环境,该难点可以被绕过。
  2. 视频
    基于 Chrome 的 MSE,视频在客户端的播放会相对较为容易。只需要熟悉 MSE API。
  3. 音频
    同样可以基于 Chrome MSE 实现。
  4. 输入/信号
    各自隔离处理即可,浏览器端对常见的输入信号几乎都有支持。


浏览器为 web 客户端的实现做了大量的工作,前期如果以快速落地为主要诉求,可以考虑基于浏览器的 web 客户端实现。

原文来自:https://fecoding.cn/2019/07/22/a-look-at-the-browser-based-client-streaming-tech/?utm_source=tuicool&utm_medium=referral


链接: https://fly63.com/article/detial/4334

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!