大家好，我來自英特爾的WebRTC團(tuán)隊(duì)，主要負(fù)責(zé)Open WebRTC Toolkit（OWT）開源項(xiàng)目中音視頻相關(guān)的工作。本次分享的主要內(nèi)容是基于WebRTC技術(shù)實(shí)現(xiàn)360全景視頻直播的一些探索及實(shí)踐。

　　2018年5G還處于一個(gè)商業(yè)試點(diǎn)的階段。僅僅1年過去，5G手機(jī)就已經(jīng)得到快速的普及。5G技術(shù)高帶寬及超低延時(shí)的特性，為各行各業(yè)帶來一些顛覆性的變革。

　　對于視頻行業(yè)而言，以下幾個(gè)方向值得關(guān)注：首先是360全景視頻，也是本次討論的主題；其次Cloud Gaming（云游戲），是目前高速發(fā)展的領(lǐng)域；VR和AR技術(shù)；最后，Smart City（智慧城市）：包括無人駕駛技術(shù)、IoT技術(shù)。
　　360 Video ingredients

　　從內(nèi)容采集來講，首先是360全景攝像頭以及360全景圖像拼接技術(shù)，這方面目前已經(jīng)有很多成功的公司。其次是360 projection, 目前比較通用的是EquiRectangular Projection （ERP）和CubeMap Projection （CMP）。行業(yè)巨頭也紛紛提出各自的映射模型，比如Facebook采用金字塔模型；Google提出的Equi-Angular Cubemap。

　　上圖是一個(gè)不同分辨率的對比。從到4K發(fā)展到8K，更大的分辨率會帶來更廣闊的視角、更多的細(xì)節(jié)以及更豐富的視覺體驗(yàn)，同時(shí)也帶來對網(wǎng)絡(luò)傳輸帶寬更高的需求。

　　8K HEVC 30FPS視頻流碼率通常達(dá)到100Mbps。如此高的網(wǎng)絡(luò)傳輸帶寬即使對于5G網(wǎng)絡(luò)，也是不小的壓力。如果考慮到幀率進(jìn)一步的提高，到達(dá)8K 60FPS；或者8K Stereo 360全景視頻，對于網(wǎng)絡(luò)帶寬的需求還會成倍地增長。

 

　　根據(jù)360全景視頻特點(diǎn)，特定時(shí)刻的用戶視角通常只占據(jù)全部圖像中一小部分區(qū)域。如果對全景圖像進(jìn)行8K的網(wǎng)絡(luò)傳輸和視頻解碼，會造成了極大的網(wǎng)絡(luò)資源和計(jì)算資源的浪費(fèi)。并且目前主流的VR設(shè)備還不具備8K視頻解碼能力，甚至4K也只是一些高端設(shè)備才能支持。

　　VR設(shè)備的視角通常在80~120度。以90度視角為例，用戶在特定時(shí)刻可見的畫面只占據(jù)全景圖像的1/8左右。因此，僅對用戶當(dāng)前視角之內(nèi)的圖像進(jìn)行網(wǎng)絡(luò)傳輸，在客戶端視頻解碼、渲染，理論上可以節(jié)省約70%網(wǎng)絡(luò)傳輸帶寬。即在一個(gè)2K的設(shè)備上，就可以具有8K全景視頻同樣的體驗(yàn)。

　　8K全景視頻的編碼方式有很多。Multiple streams的方式，是將8K原始圖像劃分成若干個(gè)獨(dú)立區(qū)域，對每一片區(qū)域分別進(jìn)行編碼�？蛻舳酥恍枰�根據(jù)用戶當(dāng)前視角，選取視角所覆蓋區(qū)域的多路視頻流進(jìn)行傳輸。

　　這種方式特點(diǎn)是可擴(kuò)展性強(qiáng)。不同時(shí)刻不同用戶的視角各有不同，如果每一個(gè)的用戶都采用一個(gè)單獨(dú)的編碼器，服務(wù)端沒有如此多的計(jì)算資源實(shí)現(xiàn)的；而Multiple streams方式只需要采用固定數(shù)量的編碼器就可以服務(wù)于海量用戶。

　　但是這種方式的缺點(diǎn)也很明顯。首先，實(shí)現(xiàn)起來比較復(fù)雜。在服務(wù)端，全景圖像的每一個(gè)區(qū)域的視頻流，都需要嚴(yán)格的幀級別時(shí)間戳同步；同樣，客戶端接收到多路視頻流解碼之后，也需要進(jìn)行嚴(yán)格的同步渲染。

　　其次，如果對原始8K視頻進(jìn)行切分的粒度較小，會導(dǎo)致用戶視角覆蓋的區(qū)域比較多；客戶端則需要同樣多數(shù)目的解碼器。而很多設(shè)備無法支持多個(gè)解碼器。因此這種方式不太常用。

　　針對上述不足，OMAF標(biāo)準(zhǔn)提出了基于HEVC Tile來實(shí)現(xiàn)的全景視頻。類似于H264 Slice，Tile是HEVC中引入的并行化編碼工具。兩者的區(qū)別在于Slice僅支持橫向劃分的，而Tile支持橫向縱向的矩形的劃分。那么Tile有什么優(yōu)點(diǎn)呢？

　　第一，   與Slice相比，它保留了縱向像素點(diǎn)的關(guān)聯(lián)度，比Slice壓縮效率更高。第二，   Tile header size在bitstream中比Slice header更小，進(jìn)一步提升了編碼效率。

　　在全景視頻編碼中，對原始圖像的切分使用HEVC Tile來實(shí)現(xiàn)。

　　在編碼端，對每一個(gè)HEVC Tile的預(yù)測編碼進(jìn)行一定約束。幀內(nèi)預(yù)測只在當(dāng)前Tile進(jìn)行，禁止tile間預(yù)測編碼； 同樣，幀間預(yù)測也約束在同樣空間位置，不同時(shí)間序列的Tile中。通過對預(yù)測編碼的這些約束，就可以實(shí)現(xiàn)每一個(gè)Tile的序列，不依賴于其它位置Tiles的獨(dú)立解碼。

　　經(jīng)過MCTS編碼后，根據(jù)用戶當(dāng)前的視角，選擇多個(gè)Tiles生成一個(gè)HEVC兼容的Bitstream。這種方式可以實(shí)現(xiàn)一次編碼，根據(jù)不同Tiles的組合，產(chǎn)生多個(gè)不同視角的Bitstreams服務(wù)于不同的用戶。極大的節(jié)省了服務(wù)端的視頻編碼計(jì)算資源。在客戶端，也僅需要一路標(biāo)準(zhǔn)HEVC解碼器。當(dāng)用戶視角改變導(dǎo)致Tiles的組合發(fā)生變化時(shí)，需要等到最近的IDR Frame即GOP邊界，才能產(chǎn)生對應(yīng)新的Bitstream。

　　上圖是所采用的HEVC Tile編碼的方式。對8K原始圖像進(jìn)行原始分辨率的HEVC Tile編碼；同時(shí)，把原始圖像縮放到一個(gè)較小分辨率，進(jìn)行另一路低分辨率HEVC Tile的編碼。

　　由于用戶視角可以在任意時(shí)刻發(fā)生切換，然而HEVC Tile視頻流只能在GOP的邊界才能重新組合不同區(qū)域的Tiles。當(dāng)用戶切換到新的視角，而新區(qū)域的HEVC Tiles還來不及傳輸時(shí)，用戶會體驗(yàn)到短時(shí)間的黑屏現(xiàn)象。為了避免視角快速切換中的黑屏，除了產(chǎn)生原始分辨率HEVC Tiles流之外，會額外傳輸覆蓋全部區(qū)域的較低分辨率的流，作為原始分辨率HEVC Tiles的后備。

　　當(dāng)用戶快速轉(zhuǎn)動視角時(shí)，如果客戶端還沒有接收到原始分辨率的HEVC Tiles，這部分缺失的區(qū)域會使用低分辨率的HEVC Tiles呈現(xiàn)給用戶。用戶會體驗(yàn)到一個(gè)短暫的圖像從模糊到清晰的過渡，避免了黑屏的體驗(yàn)。

　　原始分辨率和低分辨率的兩路HEVC Tile視頻流，通過Bitstream Rewriter合成一路HEVC兼容Mix Resolution流。客戶端只需要一個(gè)HEVC Decoder即可實(shí)現(xiàn)Mix Resolution的解碼。

　　目前的全景視頻采用的OMAF協(xié)議是基于DASH的實(shí)現(xiàn)。在這里對DASH和WebRTC進(jìn)行簡單的比較。DASH是基于HTTP/TCP的可靠傳輸，而WebRTC是基于UDP的實(shí)時(shí)傳輸。DASH通過Segment的方式，通常以多個(gè)GOP為最小單元，進(jìn)行傳輸。而較新的CMAF則是通過更小的Trunk來降低延遲。而WebRTC是通過Frame傳輸，降低了Frame Buffering產(chǎn)生的延時(shí)；根據(jù)不同的Segment/Trunk配置，DASH的延遲在3~60秒。WebRTC的延遲基本上在1秒以內(nèi)，在Cloud Gaming中更是實(shí)現(xiàn)了100毫秒~500毫秒以內(nèi)的延遲；DASH通過多路不同編碼質(zhì)量的流實(shí)現(xiàn)Adaptive Bitrate，而WebRTC則通過帶寬預(yù)測調(diào)整Bitrate；DASH主要應(yīng)用于CDN部署，WebRTC則服務(wù)于實(shí)時(shí)應(yīng)用場景。

　　基于Open WebRTC Toolkit的8K全景視頻低延時(shí)直播系統(tǒng)，通過采用英特爾開源的SVT-HEVC進(jìn)行HEVC Tile編碼，降低對網(wǎng)絡(luò)傳輸帶寬的要求，提高用戶感知Resolution；并且結(jié)合英特爾5G技術(shù)中Edge Server的部署，進(jìn)一步降低整體的延遲；8K HEVC Tile轉(zhuǎn)碼Media Server運(yùn)行于Intel? Xeon? Platinum processor。

　　英特爾SVT-HEVC是Open Visual Cloud開源項(xiàng)目中的一部分，目前實(shí)時(shí)編碼可以達(dá)到8K 60FPS。另外它是一個(gè)可擴(kuò)展的技術(shù)方案，針對英特爾至強(qiáng)系列處理器的多核架構(gòu)進(jìn)行優(yōu)化。在同一框架下除SVT-HEVC外，還實(shí)現(xiàn)了SVT-VP9，SVT-AV1以及SVT-AVS3。圖中是SVT-HEVC和X265編碼性能的對比。

　　Open WebRTC Toolkit是英特爾在Github上開源的流媒體發(fā)布平臺�；�于WebRTC技術(shù)，并兼容目前主流的HLS，RTP，RTMP，DASH。項(xiàng)目主要是分成服務(wù)端和客戶端兩部分，客戶端支持所有主流的瀏覽器，包括Chrome、Firefox 、Edge Browser等；移動端支持Android，iOS；以及對于Windows和Linux的Native SDK支持。

　　服務(wù)端具有分布式部署、高可用性等特點(diǎn)，可以實(shí)現(xiàn)各種流協(xié)議的接入接出，包括音視頻的轉(zhuǎn)碼，混流和服務(wù)端推流的功能�；�于至強(qiáng)處理器和英特爾Graphics視頻編解碼的軟件和硬件的優(yōu)化。

　　為了增加對360全景視頻的支持，擴(kuò)展了原生WebRTC Stack并加入了HEVC Codec和HEVC Tile的支持，以及HEVC RTP的Packetizer和De-packetizer；第二，Media Server對8K的轉(zhuǎn)碼進(jìn)行了優(yōu)化。第三，實(shí)現(xiàn)了基于FoV（Field of View）反饋的HEVC Bitstream Rewriter的功能；第四，基于RTC本身實(shí)時(shí)低延時(shí)的傳輸效果，實(shí)施了用戶FoV到Server的低延時(shí)反饋通道。最后整個(gè)Server是分布式部署的（Media Server和Edge Server），并且支持Android、iOS、Window等不同客戶端。

　　上圖是大型體育賽事直播應(yīng)用場景的部署圖。在體育場的360全景攝像機(jī)，通過5G網(wǎng)絡(luò)把360全景視頻，接入到體育場邊緣的Media Server。Media Server進(jìn)行HEVC Tile轉(zhuǎn)碼，產(chǎn)生原始分辨率和低分辨率的兩路HEVC Tile流。兩路HEVC Tile流由核心網(wǎng)絡(luò)傳送到各個(gè)Edge Server。Edge Server根據(jù)用戶反饋的不同視角，通過Bitstream Rewriter產(chǎn)生Mix Resolution的HEVC Tile流，通過5G網(wǎng)絡(luò)發(fā)送到各個(gè)客戶端。

　　360全景攝像頭可以通過RTSP或者RTMP協(xié)議來接入到Media Server，接入的原始8K視頻碼率是100Mbps�？拷鼉�(nèi)容產(chǎn)生端的Media Server進(jìn)行HEVC Tile轉(zhuǎn)碼后，產(chǎn)生的原始分辨率和低分辨率兩路流，通過內(nèi)部節(jié)點(diǎn)間的QUIC或者TCP協(xié)議傳輸各個(gè)Edge節(jié)點(diǎn)。Edge Server會根據(jù)每一個(gè)用戶的FoV反饋，對原始分辨率和低分辨率流進(jìn)行拼接，產(chǎn)生Mix Resolution流。新產(chǎn)生的Mix Resolution流通過WebRTC協(xié)議連接對應(yīng)的客戶端�？蛻舳送ㄟ^單路HEVC解碼，還原為符合用戶當(dāng)前視角的360全景視頻。

　　目前方案中Media Server在體育場邊緣主要做HEVC Tile轉(zhuǎn)碼，并沒有包括360全景圖像拼接（360 Image Stitching）。需要在360全景攝像頭和Media Server之間，部署額外的圖像拼接服務(wù)器，這引入了拼接圖像的轉(zhuǎn)發(fā)延時(shí)。未來通過集成360全景圖像拼接算法到Media Server，可以進(jìn)一步降低端到端延時(shí)以及服務(wù)器部署成本。

　　其次，目前的方案中采用的原始分辨率和低分辨率兩路流的方式中，不能很好的做的FoV的快速切換和Adaptive Bitrate。未來可以通過實(shí)現(xiàn)高、中、低多種分辨率和不同GOP的組合，優(yōu)化FoV切換延時(shí)和Network Adaption。

　　多數(shù)瀏覽器對于HEVC編碼標(biāo)準(zhǔn)兼容性存在缺陷。隨著AV1編碼器的逐漸成熟，可以通過基于AV1的360全景視頻實(shí)現(xiàn)達(dá)到與瀏覽器、WebRTC以及WebXR等技術(shù)的深度融合。