(追梦无人直播系统)无人直播转码推流软件

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等手艺的深度交融。