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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　原始分辨率和低分辨率的兩路HEVC Tile視頻流，通過Bitstream Rewriter合成一路HEVC兼容Mix Resolution流�？蛻舳酥恍枰�一個HEVC Decoder即可實現(xiàn)Mix Resolution的解碼。

　　目前的全景視頻采用的OMAF協(xié)議是基于DASH的實現(xiàn)。在這里對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中更是實現(xiàn)了100毫秒~500毫秒以內的延遲；DASH通過多路不同編碼質量的流實現(xiàn)Adaptive Bitrate，而WebRTC則通過帶寬預測調整Bitrate；DASH主要應用于CDN部署，WebRTC則服務于實時應用場景。

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

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

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

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

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

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

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

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

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

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