您当前的位置:首页 VR开发 平台系统 正文

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

查看: 1766| 评论: 4 2020-4-17 07:44 PM| 发布者: administrator |原作者: 戴建辉

    一篇非常好的实时高清视频流解决方案的文章,52VR推荐给大家 。英特尔的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等技术的深度融合。

52VR.COM微信扫一扫
52vr公众号
专注于VR的学习、开发和人才交流

52VR开发交流

已有 4 人参与

发表评论

您需要登录才可以回帖 登录 | 立即注册

手机版|VR开发网 ( 津ICP备18009691号 ) 统计 网安备12019202000257

GMT+8, 2020-12-6 06:45 AM

返回顶部