基于Open WebRTC Toolkit（OWT）的8K全景视频低延时直播系统

photo from Ready Player One

随着5G技术的发展，其高带宽、超低延时的特性为高分辨率全景视频的实现带来了更多的可能。本文来自Open WebRTC Toolkit (OWT)音视频架构师戴建辉在LiveVideoStackCon2019深圳大会的演讲，详细介绍了如何基于Open WebRTC Toolkit (OWT)方案，结合SVT-HEVC tile-based编码等技术实现低延时的8K全景直播系统。

文 / 戴建辉

整理 / LiveVideoStack

大家好，我来自英特尔的WebRTC团队，主要负责Open WebRTC Toolkit（OWT）开源项目中音视频相关的工作。本次分享的主要内容是基于WebRTC技术实现360全景视频直播的一些探索及实践。

2018年5G还处于一个商业试点的阶段。仅仅1年过去，5G手机就已经得到快速的普及。5G技术高带宽及超低延时的特性，为各行各业带来一些颠覆性的变革。

对于视频行业而言，以下几个方向值得关注：首先是360全景视频，也是本次讨论的主题；其次Cloud Gaming（云游戏），是目前高速发展的领域；VR和AR技术；最后，Smart City（智慧城市）：包括无人驾驶技术、IoT技术。

360 Video ingredients

从内容采集来讲，首先是360全景摄像头以及360全景图像拼接技术，这方面目前已经有很多成功的公司。其次是360 projection, 目前比较通用的是EquiRectangular Projection (ERP)和CubeMap Projection (CMP)。行业巨头也纷纷提出各自的映射模型，比如Facebook采用金字塔模型；Google提出的Equi-Angular Cubemap。

8K UHD Video

上图是一个不同分辨率的对比。从到4K发展到8K，更大的分辨率会带来更广阔的视角、更多的细节以及更丰富的视觉体验，同时也带来对网络传输带宽更高的需求。

8K HEVC 30FPS视频流码率通常达到100Mbps。如此高的网络传输带宽即使对于5G网络，也是不小的压力。如果考虑到帧率进一步的提高，到达8K 60FPS；或者8K Stereo 360全景视频，对于网络带宽的需求还会成倍地增长。

Viewport dependent 360 video streaming

根据360全景视频特点，特定时刻的用户视角通常只占据全部图像中一小部分区域。如果对全景图像进行8K的网络传输和视频解码，会造成了极大的网络资源和计算资源的浪费。并且目前主流的VR设备还不具备8K视频解码能力，甚至4K也只是一些高端设备才能支持。

VR设备的视角通常在80~120度。以90度视角为例，用户在特定时刻可见的画面只占据全景图像的1/8左右。因此，仅对用户当前视角之内的图像进行网络传输，在客户端视频解码、渲染，理论上可以节省约70%网络传输带宽。即在一个2K的设备上，就可以具有8K全景视频同样的体验。

Multiple streams coding scheme

8K全景视频的编码方式有很多。Multiple streams的方式，是将8K原始图像划分成若干个独立区域，对每一片区域分别进行编码。客户端只需要根据用户当前视角，选取视角所覆盖区域的多路视频流进行传输。

这种方式特点是可扩展性强。不同时刻不同用户的视角各有不同，如果每一个的用户都采用一个单独的编码器，服务端没有如此多的计算资源实现的；而Multiple streams方式只需要采用固定数量的编码器就可以服务于海量用户。

但是这种方式的缺点也很明显。首先，实现起来比较复杂。在服务端，全景图像的每一个区域的视频流，都需要严格的帧级别时间戳同步；同样，客户端接收到多路视频流解码之后，也需要进行严格的同步渲染。

其次，如果对原始8K视频进行切分的粒度较小，会导致用户视角覆盖的区域比较多；客户端则需要同样多数目的解码器。而很多设备无法支持多个解码器。因此这种方式不太常用。

Tiles in HEVC

针对上述不足，OMAF标准提出了基于HEVC Tile来实现的全景视频。类似于H264 Slice，Tile是HEVC中引入的并行化编码工具。两者的区别在于Slice仅支持横向划分的，而Tile支持横向纵向的矩形的划分。那么Tile有什么优点呢？

第一，   与Slice相比，它保留了纵向像素点的关联度，比Slice压缩效率更高。第二，   Tile header size在bitstream中比Slice header更小，进一步提升了编码效率。

在全景视频编码中，对原始图像的切分使用HEVC Tile来实现。

Motion-Constrained Tile Set (MCTS)

在编码端，对每一个HEVC Tile的预测编码进行一定约束。帧内预测只在当前Tile进行，禁止tile间预测编码; 同样，帧间预测也约束在同样空间位置，不同时间序列的Tile中。通过对预测编码的这些约束，就可以实现每一个Tile的序列，不依赖于其它位置Tiles的独立解码。

经过MCTS编码后，根据用户当前的视角，选择多个Tiles生成一个HEVC兼容的Bitstream。这种方式可以实现一次编码，根据不同Tiles的组合，产生多个不同视角的Bitstreams服务于不同的用户。极大的节省了服务端的视频编码计算资源。在客户端，也仅需要一路标准HEVC解码器。当用户视角改变导致Tiles的组合发生变化时，需要等到最近的IDR Frame即GOP边界，才能产生对应新的Bitstream。

HEVC MCTS-based coding scheme

上图是所采用的HEVC Tile编码的方式。对8K原始图像进行原始分辨率的HEVC Tile编码；同时，把原始图像缩放到一个较小分辨率，进行另一路低分辨率HEVC Tile的编码。

由于用户视角可以在任意时刻发生切换，然而HEVC Tile视频流只能在GOP的边界才能重新组合不同区域的Tiles。当用户切换到新的视角，而新区域的HEVC Tiles还来不及传输时，用户会体验到短时间的黑屏现象。为了避免视角快速切换中的黑屏，除了产生原始分辨率HEVC Tiles流之外，会额外传输覆盖全部区域的较低分辨率的流，作为原始分辨率HEVC Tiles的后备。

当用户快速转动视角时，如果客户端还没有接收到原始分辨率的HEVC Tiles，这部分缺失的区域会使用低分辨率的HEVC Tiles呈现给用户。用户会体验到一个短暂的图像从模糊到清晰的过渡，避免了黑屏的体验。

原始分辨率和低分辨率的两路HEVC Tile视频流，通过Bitstream Rewriter合成一路HEVC兼容Mix Resolution流。客户端只需要一个HEVC Decoder即可实现Mix Resolution的解码。

DASH vs WebRTC

目前的全景视频采用的OMAF协议是基于DASH的实现。在这里对DASH和WebRTC进行简单的比较。DASH是基于HTTP/TCP的可靠传输，而WebRTC是基于UDP的实时传输。DASH通过Segment的方式，通常以多个GOP为最小单元，进行传输。而较新的CMAF则是通过更小的Trunk来降低延迟。而WebRTC是通过Frame传输，降低了Frame Buffering产生的延时；根据不同的Segment/Trunk配置，DASH的延迟在3~60秒。WebRTC的延迟基本上在1秒以内，在Cloud Gaming中更是实现了100毫秒~500毫秒以内的延迟；DASH通过多路不同编码质量的流实现Adaptive Bitrate，而WebRTC则通过带宽预测调整Bitrate；DASH主要应用于CDN部署，WebRTC则服务于实时应用场景。

基于Open WebRTC Toolkit (OWT) 8K全景视频低延时直播系统

基于Open WebRTC Toolkit的8K全景视频低延时直播系统，通过采用英特尔开源的SVT-HEVC进行HEVC Tile编码，降低对网络传输带宽的要求，提高用户感知Resolution；并且结合英特尔5G技术中Edge Server的部署，进一步降低整体的延迟；8K HEVC Tile转码Media Server运行于Intel® Xeon® Platinum processor。

SVT-HEVC

英特尔SVT-HEVC是Open Visual Cloud开源项目中的一部分，目前实时编码可以达到8K 60FPS。另外它是一个可扩展的技术方案，针对英特尔至强系列处理器的多核架构进行优化。在同一框架下除SVT-HEVC外，还实现了SVT-VP9，SVT-AV1以及SVT-AVS3。图中是SVT-HEVC和X265编码性能的对比。

Open WebRTC Toolkit (OWT)

Open WebRTC Toolkit是英特尔在Github上开源的流媒体发布平台。基于WebRTC技术，并兼容目前主流的HLS，RTP，RTMP，DASH。项目主要是分成服务端和客户端两部分，客户端支持所有主流的浏览器，包括Chrome、Firefox 、Edge Browser等；移动端支持Android，iOS；以及对于Windows和Linux的Native SDK支持。

服务端具有分布式部署、高可用性等特点，可以实现各种流协议的接入接出，包括音视频的转码，混流和服务端推流的功能。基于至强处理器和英特尔Graphics视频编解码的软件和硬件的优化。

为了增加对360全景视频的支持，扩展了原生WebRTC Stack并加入了HEVC Codec和HEVC Tile的支持，以及HEVC RTP的Packetizer和De-packetizer；第二，Media Server对8K的转码进行了优化。第三，实现了基于FoV（Field of View）反馈的HEVC Bitstream Rewriter的功能；第四，基于RTC本身实时低延时的传输效果，实施了用户FoV到Server的低延时反馈通道。最后整个Server是分布式部署的（Media Server和Edge Server），并且支持Android、iOS、Window等不同客户端。

Distributed deployment

上图是大型体育赛事直播应用场景的部署图。在体育场的360全景摄像机，通过5G网络把360全景视频，接入到体育场边缘的Media Server。Media Server进行HEVC Tile转码，产生原始分辨率和低分辨率的两路HEVC Tile流。两路HEVC Tile流由核心网络传送到各个Edge Server。Edge Server根据用户反馈的不同视角，通过Bitstream Rewriter产生Mix Resolution的HEVC Tile流，通过5G网络发送到各个客户端。

End-to-end workflow

360全景摄像头可以通过RTSP或者RTMP协议来接入到Media Server，接入的原始8K视频码率是100Mbps。靠近内容产生端的Media Server进行HEVC Tile转码后，产生的原始分辨率和低分辨率两路流，通过内部节点间的QUIC或者TCP协议传输各个Edge节点。Edge Server会根据每一个用户的FoV反馈，对原始分辨率和低分辨率流进行拼接，产生Mix Resolution流。新产生的Mix Resolution流通过WebRTC协议连接对应的客户端。客户端通过单路HEVC解码，还原为符合用户当前视角的360全景视频。

Future Work

目前方案中Media Server在体育场边缘主要做HEVC Tile转码，并没有包括360全景图像拼接（360 Image Stitching）。需要在360全景摄像头和Media Server之间，部署额外的图像拼接服务器，这引入了拼接图像的转发延时。未来通过集成360全景图像拼接算法到Media Server，可以进一步降低端到端延时以及服务器部署成本。

其次，目前的方案中采用的原始分辨率和低分辨率两路流的方式中，不能很好的做的FoV的快速切换和Adaptive Bitrate。未来可以通过实现高、中、低多种分辨率和不同GOP的组合，优化FoV切换延时和Network Adaption。

多数浏览器对于HEVC编码标准兼容性存在缺陷。随着AV1编码器的逐渐成熟，可以通过基于AV1的360全景视频实现达到与浏览器、WebRTC以及WebXR等技术的深度融合。

点击【阅读原文】访问购票页面