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等技術的深度融合。
閱讀更多 LiveVideoStack 的文章
