大家好，我來自英特爾的WebRTC團隊，主要負責Open WebRTC Toolkit（OWT）開源項目中音視頻相關(guān)的工作。本次分享的主要內(nèi)容是基于WebRTC技術(shù)實現(xiàn)360全景視頻直播的一些探索及實踐。
2018年5G還處于一個商業(yè)試點的階段。僅僅1年過去，5G手機就已經(jīng)得到快速的普及。5G技術(shù)高帶寬及超低延時的特性，為各行各業(yè)帶來一些顛覆性的變革。
對于視頻行業(yè)而言，以下幾個方向值得關(guān)注：首先是360全景視頻，也是本次討論的主題；其次Cloud Gaming（云游戲），是目前高速發(fā)展的領(lǐng)域；VR和AR技術(shù)；最后，Smart City（智慧城市）：包括無人駕駛技術(shù)、IoT技術(shù)。
360 Video ingredients
360 Video ingredients
從內(nèi)容采集來講，首先是360全景攝像頭以及360全景圖像拼接技術(shù)，這方面目前已經(jīng)有很多成功的公司。其次是360 projection, 目前比較通用的是EquiRectangular Projection （ERP）和CubeMap Projection （CMP）。行業(yè)巨頭也紛紛提出各自的映射模型，比如Facebook采用金字塔模型；Google提出的Equi-Angular Cubemap。
8K UHD Video
上圖是一個不同分辨率的對比。從到4K發(fā)展到8K，更大的分辨率會帶來更廣闊的視角、更多的細節(jié)以及更豐富的視覺體驗，同時也帶來對網(wǎng)絡(luò)傳輸帶寬更高的需求。
8K HEVC 30FPS視頻流碼率通常達到100Mbps。如此高的網(wǎng)絡(luò)傳輸帶寬即使對于5G網(wǎng)絡(luò)，也是不小的壓力。如果考慮到幀率進一步的提高，到達8K 60FPS；或者8K Stereo 360全景視頻，對于網(wǎng)絡(luò)帶寬的需求還會成倍地增長。
Viewport dependent 360 video streaming
根據(jù)360全景視頻特點，特定時刻的用戶視角通常只占據(jù)全部圖像中一小部分區(qū)域。如果對全景圖像進行8K的網(wǎng)絡(luò)傳輸和視頻解碼，會造成了極大的網(wǎng)絡(luò)資源和計算資源的浪費。并且目前主流的VR設(shè)備還不具備8K視頻解碼能力，甚至4K也只是一些高端設(shè)備才能支持。
VR設(shè)備的視角通常在80~120度。以90度視角為例，用戶在特定時刻可見的畫面只占據(jù)全景圖像的1/8左右。因此，僅對用戶當前視角之內(nèi)的圖像進行網(wǎng)絡(luò)傳輸，在客戶端視頻解碼、渲染，理論上可以節(jié)省約70%網(wǎng)絡(luò)傳輸帶寬。即在一個2K的設(shè)備上，就可以具有8K全景視頻同樣的體驗。
Multiple streams coding scheme
8K全景視頻的編碼方式有很多。Multiple streams的方式，是將8K原始圖像劃分成若干個獨立區(qū)域，對每一片區(qū)域分別進行編碼�？蛻舳酥恍枰鶕�(jù)用戶當前視角，選取視角所覆蓋區(qū)域的多路視頻流進行傳輸。
這種方式特點是可擴展性強。不同時刻不同用戶的視角各有不同，如果每一個的用戶都采用一個單獨的編碼器，服務(wù)端沒有如此多的計算資源實現(xiàn)的；而Multiple streams方式只需要采用固定數(shù)量的編碼器就可以服務(wù)于海量用戶。
但是這種方式的缺點也很明顯。首先，實現(xiàn)起來比較復(fù)雜。在服務(wù)端，全景圖像的每一個區(qū)域的視頻流，都需要嚴格的幀級別時間戳同步；同樣，客戶端接收到多路視頻流解碼之后，也需要進行嚴格的同步渲染。
其次，如果對原始8K視頻進行切分的粒度較小，會導致用戶視角覆蓋的區(qū)域比較多；客戶端則需要同樣多數(shù)目的解碼器。而很多設(shè)備無法支持多個解碼器。因此這種方式不太常用。
Tiles in HEVC
針對上述不足，OMAF標準提出了基于HEVC Tile來實現(xiàn)的全景視頻。類似于H264 Slice，Tile是HEVC中引入的并行化編碼工具。兩者的區(qū)別在于Slice僅支持橫向劃分的，而Tile支持橫向縱向的矩形的劃分。那么Tile有什么優(yōu)點呢？
第一， 與Slice相比，它保留了縱向像素點的關(guān)聯(lián)度，比Slice壓縮效率更高。第二， Tile header size在bitstream中比Slice header更小，進一步提升了編碼效率。
在全景視頻編碼中，對原始圖像的切分使用HEVC Tile來實現(xiàn)。
Motion-Constrained Tile Set （MCTS）
在編碼端，對每一個HEVC Tile的預(yù)測編碼進行一定約束。幀內(nèi)預(yù)測只在當前Tile進行，禁止tile間預(yù)測編碼； 同樣，幀間預(yù)測也約束在同樣空間位置，不同時間序列的Tile中。通過對預(yù)測編碼的這些約束，就可以實現(xiàn)每一個Tile的序列，不依賴于其它位置Tiles的獨立解碼。
經(jīng)過MCTS編碼后，根據(jù)用戶當前的視角，選擇多個Tiles生成一個HEVC兼容的Bitstream。這種方式可以實現(xiàn)一次編碼，根據(jù)不同Tiles的組合，產(chǎn)生多個不同視角的Bitstreams服務(wù)于不同的用戶。極大的節(jié)省了服務(wù)端的視頻編碼計算資源。在客戶端，也僅需要一路標準HEVC解碼器。當用戶視角改變導致Tiles的組合發(fā)生變化時，需要等到最近的IDR Frame即GOP邊界，才能產(chǎn)生對應(yīng)新的Bitstream。
HEVC MCTS-based coding scheme
上圖是所采用的HEVC Tile編碼的方式。對8K原始圖像進行原始分辨率的HEVC Tile編碼；同時，把原始圖像縮放到一個較小分辨率，進行另一路低分辨率HEVC Tile的編碼。
由于用戶視角可以在任意時刻發(fā)生切換，然而HEVC Tile視頻流只能在GOP的邊界才能重新組合不同區(qū)域的Tiles。當用戶切換到新的視角，而新區(qū)域的HEVC Tiles還來不及傳輸時，用戶會體驗到短時間的黑屏現(xiàn)象。為了避免視角快速切換中的黑屏，除了產(chǎn)生原始分辨率HEVC Tiles流之外，會額外傳輸覆蓋全部區(qū)域的較低分辨率的流，作為原始分辨率HEVC Tiles的后備。
當用戶快速轉(zhuǎn)動視角時，如果客戶端還沒有接收到原始分辨率的HEVC Tiles，這部分缺失的區(qū)域會使用低分辨率的HEVC Tiles呈現(xiàn)給用戶。用戶會體驗到一個短暫的圖像從模糊到清晰的過渡，避免了黑屏的體驗。
原始分辨率和低分辨率的兩路HEVC Tile視頻流，通過Bitstream Rewriter合成一路HEVC兼容Mix Resolution流�？蛻舳酥恍枰粋�HEVC Decoder即可實現(xiàn)Mix Resolution的解碼。
DASH vs WebRTC
目前的全景視頻采用的OMAF協(xié)議是基于DASH的實現(xiàn)。在這里對DASH和WebRTC進行簡單的比較。DASH是基于HTTP/TCP的可靠傳輸，而WebRTC是基于UDP的實時傳輸。DASH通過Segment的方式，通常以多個GOP為最小單元，進行傳輸。而較新的CMAF則是通過更小的Trunk來降低延遲。而WebRTC是通過Frame傳輸，降低了Frame Buffering產(chǎn)生的延時；根據(jù)不同的Segment/Trunk配置，DASH的延遲在3~60秒。WebRTC的延遲基本上在1秒以內(nèi)，在Cloud Gaming中更是實現(xiàn)了100毫秒~500毫秒以內(nèi)的延遲；DASH通過多路不同編碼質(zhì)量的流實現(xiàn)Adaptive Bitrate，而WebRTC則通過帶寬預(yù)測調(diào)整Bitrate；DASH主要應(yīng)用于CDN部署，WebRTC則服務(wù)于實時應(yīng)用場景。
基于Open WebRTC Toolkit （OWT） 8K全景視頻低延時直播系統(tǒng)
基于Open WebRTC Toolkit的8K全景視頻低延時直播系統(tǒng)，通過采用英特爾開源的SVT-HEVC進行HEVC Tile編碼，降低對網(wǎng)絡(luò)傳輸帶寬的要求，提高用戶感知Resolution；并且結(jié)合英特爾5G技術(shù)中Edge Server的部署，進一步降低整體的延遲；8K HEVC Tile轉(zhuǎn)碼Media Server運行于Intel? Xeon? Platinum processor。
SVT-HEVC
英特爾SVT-HEVC是Open Visual Cloud開源項目中的一部分，目前實時編碼可以達到8K 60FPS。另外它是一個可擴展的技術(shù)方案，針對英特爾至強系列處理器的多核架構(gòu)進行優(yōu)化。在同一框架下除SVT-HEVC外，還實現(xiàn)了SVT-VP9，SVT-AV1以及SVT-AVS3。圖中是SVT-HEVC和X265編碼性能的對比。
Open WebRTC Toolkit （OWT）
Open WebRTC Toolkit是英特爾在Github上開源的流媒體發(fā)布平臺�；赪ebRTC技術(shù)，并兼容目前主流的HLS，RTP，RTMP，DASH。項目主要是分成服務(wù)端和客戶端兩部分，客戶端支持所有主流的瀏覽器，包括Chrome、Firefox 、Edge Browser等；移動端支持Android，iOS；以及對于Windows和Linux的Native SDK支持。
服務(wù)端具有分布式部署、高可用性等特點，可以實現(xiàn)各種流協(xié)議的接入接出，包括音視頻的轉(zhuǎn)碼，混流和服務(wù)端推流的功能�；谥翉娞幚砥骱陀⑻貭朑raphics視頻編解碼的軟件和硬件的優(yōu)化。
為了增加對360全景視頻的支持，擴展了原生WebRTC Stack并加入了HEVC Codec和HEVC Tile的支持，以及HEVC RTP的Packetizer和De-packetizer；第二，Media Server對8K的轉(zhuǎn)碼進行了優(yōu)化。第三，實現(xiàn)了基于FoV（Field of View）反饋的HEVC Bitstream Rewriter的功能；第四，基于RTC本身實時低延時的傳輸效果，實施了用戶FoV到Server的低延時反饋通道。最后整個Server是分布式部署的（Media Server和Edge Server），并且支持Android、iOS、Window等不同客戶端。
Distributed deployment
上圖是大型體育賽事直播應(yīng)用場景的部署圖。在體育場的360全景攝像機，通過5G網(wǎng)絡(luò)把360全景視頻，接入到體育場邊緣的Media Server。Media Server進行HEVC Tile轉(zhuǎn)碼，產(chǎn)生原始分辨率和低分辨率的兩路HEVC Tile流。兩路HEVC Tile流由核心網(wǎng)絡(luò)傳送到各個Edge Server。Edge Server根據(jù)用戶反饋的不同視角，通過Bitstream Rewriter產(chǎn)生Mix Resolution的HEVC Tile流，通過5G網(wǎng)絡(luò)發(fā)送到各個客戶端。
End-to-end workflow
360全景攝像頭可以通過RTSP或者RTMP協(xié)議來接入到Media Server，接入的原始8K視頻碼率是100Mbps。靠近內(nèi)容產(chǎn)生端的Media Server進行HEVC Tile轉(zhuǎn)碼后，產(chǎn)生的原始分辨率和低分辨率兩路流，通過內(nèi)部節(jié)點間的QUIC或者TCP協(xié)議傳輸各個Edge節(jié)點。Edge Server會根據(jù)每一個用戶的FoV反饋，對原始分辨率和低分辨率流進行拼接，產(chǎn)生Mix Resolution流。新產(chǎn)生的Mix Resolution流通過WebRTC協(xié)議連接對應(yīng)的客戶端�？蛻舳送ㄟ^單路HEVC解碼，還原為符合用戶當前視角的360全景視頻。
Future Work
目前方案中Media Server在體育場邊緣主要做HEVC Tile轉(zhuǎn)碼，并沒有包括360全景圖像拼接（360 Image Stitching）。需要在360全景攝像頭和Media Server之間，部署額外的圖像拼接服務(wù)器，這引入了拼接圖像的轉(zhuǎn)發(fā)延時。未來通過集成360全景圖像拼接算法到Media Server，可以進一步降低端到端延時以及服務(wù)器部署成本。
其次，目前的方案中采用的原始分辨率和低分辨率兩路流的方式中，不能很好的做的FoV的快速切換和Adaptive Bitrate。未來可以通過實現(xiàn)高、中、低多種分辨率和不同GOP的組合，優(yōu)化FoV切換延時和Network Adaption。
多數(shù)瀏覽器對于HEVC編碼標準兼容性存在缺陷。隨著AV1編碼器的逐漸成熟，可以通過基于AV1的360全景視頻實現(xiàn)達到與瀏覽器、WebRTC以及WebXR等技術(shù)的深度融合。
