基于OMAF 的全景視頻傳輸機制分析

金學驥

（上海數(shù)字電視國家工程研究中心有限公司 上海市 200125）

虛擬現(xiàn)實（Virtual reality，簡寫VR）在最近十年爆發(fā)性的增長，其應用范圍也越來越廣泛，全景視頻是最典型的一種VR 應用，全景視頻給用戶提供了沉浸式的視覺體驗，在體育、游戲、教育等領域得到越來越多的應用，大量的在線全景視頻業(yè)務得到廣泛應用。全景視頻的一個顯著特點是分辨率高，數(shù)據(jù)量大，傳輸占用帶寬高，這對全景視頻傳輸帶來了巨大挑戰(zhàn)，另一方面全景視頻在觀看時只需將視窗區(qū)域呈現(xiàn)，因此如何利用全景視頻的特點來有效傳輸是VR 技術關注的一個焦點。全景視頻技術發(fā)展十分迅速，為了統(tǒng)一全景視頻技術標準，運動圖像專家組（Moving Picture Experts Group, MPEG)從2015 年開始制定全景視頻技術了標準，稱為Omnidirectional Media Format (OMAF)，標準中制定了基于三自由度的360 度全景視頻系統(tǒng)架構。OMAF 標準定義了一系列全景視頻傳輸機制，其中視窗依賴的傳輸機制可以減少全景視頻傳輸帶寬，提高傳輸效率。有些傳輸機制可以不降低視窗區(qū)域圖像質(zhì)量時減小視頻的分辨率，在相同的解碼能力下，可提升觀看全景視頻的清晰度。視窗依賴傳輸機制在用戶轉(zhuǎn)頭時不能立即看到高質(zhì)圖像，會先看到低質(zhì)圖像，然后再切換到高質(zhì)圖像，這對用戶體驗有所影響。

1 OMAF標準中傳輸機制介紹

OMAF 標準中在內(nèi)容傳輸策略上提出了多種傳輸機制，各種傳輸機制關系如圖 1 所示。總體上，這些傳輸機制可分為兩類，一種是視窗獨立機制（viewport-independent），另一種是視窗依賴機制（viewport-dependent）。

圖1： OMAF 標準中傳輸機制關系圖

在視窗獨立機制時，全景視頻不用分層或分塊，全景視頻內(nèi)容在360 度方向上保持相同的映射方法，視頻在各個區(qū)域有相同的圖像質(zhì)量，傳輸時將整個全景視頻作為一個比特流，終端不需因觀看視窗不同而去獲取不同的視頻。與視窗獨立機制不同，視窗依賴機制的特點是終端在觀看視窗不同時需要去獲取不同的視頻，這種機制下利用了全景視頻在呈現(xiàn)時并不需要所有區(qū)域都呈現(xiàn)的特點，對視窗區(qū)域內(nèi)的圖像質(zhì)量保持不變，降低視窗區(qū)域外的圖像質(zhì)量，這樣可以降低總體傳輸帶寬。為了實現(xiàn)視窗依賴機制要在源端準備多套視頻源，終端OMAF 播放器需要根據(jù)用戶視窗位置去獲取相應的視頻源。

視窗依賴機制的實現(xiàn)方法有很多，OMAF 標準中將視窗依賴機制分為整體切換與分塊組合兩種機制。在整體切換機制下源端準備多個版本的視頻源，每一個視頻源都包含了360 度的內(nèi)容，只不過每一個視頻源有它偏重的視窗區(qū)域，播放器根據(jù)用戶的視窗角度選擇一個全景視頻。在分塊組合機制下，源端將全景視頻在空間上分割多個矩形分塊，每個分塊可準備多個碼率或分辨率版本，分塊視頻編碼后單獨做為一個分塊軌道，終端獲取分塊軌道后需將分塊軌道組合在一起解碼，解碼后的視頻在視窗區(qū)域具有高質(zhì)量圖像。

分塊組合機制分為源端綁定機制（Author-driven binding）與終端綁定機制（Late binding）兩種。源端綁定機制是指在源端準備了多套視頻源，每一套視頻源由許多分塊組成，視窗內(nèi)的分塊圖像質(zhì)量高，視窗外的分塊圖像質(zhì)量低，源端提供提取軌道（Extractor Track）來指示如何將分塊數(shù)據(jù)提取并組合成一個比特流，終端根據(jù)用戶觀察的視窗位置選擇某一套視頻源，并按提取軌道來完成分塊數(shù)據(jù)組合并解碼。終端綁定機制與源端綁定機制相比，終端OMAF播放器有更大的自由度，終端OMAF 播放器來選擇哪些分塊需要下載，分塊下載后，OMAF 播放器從分塊中提取出Slice，并改寫Slice 頭，再將Slice 組合成一個新的比特流。

源端綁定機制可以再細分為兩種形式：固定視窗源端綁定（Viewport-specific author-driven binding）與自由視窗源端綁定（Free-viewport author-driven binding）。在固定視窗源端綁定時，源端將全景視頻在空間上分割多個矩形分塊，每個分塊使用運動約束圖塊集（HEVC Motion Constrained Tile Sets，MCTS）對視頻進行編碼，每個分塊可準備多個碼率或分辨率版本，同時源端提供了多種提取軌道（Extractor Track）用于將分塊數(shù)據(jù)組合在一起，每一種提取軌道有固定的高質(zhì)視窗區(qū)域，終端根據(jù)視窗區(qū)域選擇一種提取軌道與相關的分塊軌道，將分塊軌道組合成一個比特流交給解碼器解碼。

OMAF 標準中提供了多種固定視窗源端綁定機制方案，圖 2 為OMAF 標準提供的一種方案，該方案中原始視頻分辨率為（6144×3072），基于ERP 映射全景視頻，以下簡稱該方案為6K ERP 方案。源端在準備工作時需將全景視頻按四種方法進行分割，分別是靠近赤道中心區(qū)域的分辨率為6K和3K的分割方法，用于南北極區(qū)域的分辨率為3K和1.5K的分割方法。視窗內(nèi)取自6K 版本，而視窗外區(qū)域部分來自3K（3072×1536）版本或1.5K（1536×768）版本。南北兩極的條紋（緯度值高于60 或低于-60 度）以1.5K 和3K 分辨率進行編碼，而中心部分（緯度值在-60 至60 度之間）覆蓋緯度范圍120°的角度以3K 和6K 分辨率編碼，在編碼中使用了運動受限（MCTS）的編碼方式。編碼后的分塊比特流序列與提取軌道組合在一起提供16 種不同的視窗觀看方向，每個方向都對應于從6K 比特流中選擇四個相鄰的分塊，以及在赤道上方或下方的觀看方向。提取軌道指示分塊區(qū)域如何組合，組合的視頻是終端最終解碼視頻，其分辨率為3840×2304。

圖2： 固定視窗源端綁定機制示例

自由視窗源端綁定機制中，源端提供一個提取軌道，但提取軌道在每一個區(qū)域上提供了多個分塊軌道選擇，每一個區(qū)域選擇哪一種質(zhì)量的分塊軌道由終端OMAF 播放器來決定。圖 3 為自由視窗源端綁定機制的一個例子，全視視頻按8×4 進行分塊編碼，分別編碼成高碼率分塊與低碼率分塊，每一個分塊編碼序列存成一個分塊軌道。提取軌道中每一個分塊所在區(qū)域提供兩個可選項，分別對應高碼率與低碼率的分塊軌道，終端可以在某些區(qū)域選擇高碼率分塊軌道，其他區(qū)域選擇低碼率分塊軌道。

圖3： 自由視窗源端綁定機制示例

2 OMAF標準的全景視頻系統(tǒng)流程

基于OMAF 標準的系統(tǒng)流程如圖 4 所示，在源端流程包括獲取視頻源、視頻預處理、編碼、封裝等流程。封裝后的視頻數(shù)據(jù)以MMT 協(xié)議或DASH 協(xié)議進行傳輸，終端流程包括解封裝、視頻流組裝、解碼、映射和渲染等流程。終端上的OMAF 播放器需要根據(jù)OMAF 傳輸機制不同而實現(xiàn)不同的流程，以源端綁定傳輸機制下終端為例，終端上的OMAF 播放器播放VR 視頻的一般流程如圖 5 所示。

圖4： 基于OMAF 標準的全景視頻系統(tǒng)流程圖

圖5： 終端OMAF 播放器播放流程

OMAF 播放器播放VR 視頻的一般流程描述如下：

（1）終端OMAF 播放器根據(jù)uri 下載mpd 文件。

（2）終端OMAF 播放器在mpd 中找合適的提取軌道。mpd 中codecs="resv.podv+ercm.hvc2.1.6.L153.80" 表 示 是 提取軌道的描述信息。描述信息中都有srqr 信息，根據(jù)這些srqr 信息與當前的觀察視察，選擇一個合適的提取軌道。

（3）終端OMAF 播放器下載提取軌道與相關分塊軌道，根據(jù)SegmentTemplate 中的uri 下載提取軌道（包括

initialization）中的value 指示了哪些關聯(lián)分塊軌道對應的adaptationSetid。

（4）終端OMAF 播放器解析提取軌道，得到track id順序，解析媒體分塊軌道文件，知道該文件的track id，把各分塊軌道按順序拼接，然后送入解碼器。

（5）終端OMAF 播放器解碼時將組裝后的碼流進行解碼。

（6）終端OMAF 播放器對某些分塊進行映射操作，這時需要使用rwpk 信息，rwpk 信息可能從提取軌道的initialization 文件中獲取。

（7）終端OMAF 播放器最終將2D 的圖像變換到3D空間，并將視窗區(qū)域呈現(xiàn)到屏幕上來。

3 OMAF標準中實驗與分析

OMAF 傳輸機制中的視頻依賴傳輸機制結合了全景視頻傳輸特點，能減少全景視頻傳輸帶寬，提高傳輸效率。除了傳輸碼率的變化，視窗依賴傳輸機制對全景視頻的分辨率與交互延時帶來變化。本文從傳輸碼率、分辨率與交互延時三個方面對OMAF 標準中的典型機制進行實驗與分析。

3.1 OMAF傳輸機制的視頻生成

本節(jié)列出實驗視頻生成的方法，包括視窗獨立機制、自由視窗源端綁定機制與固定視窗源端綁定機制下視頻生成方法。方法中使用了ffmpeg 對原始視頻進行解碼，用kvazaar對YUV 格式視頻進行編碼，使用MP4Box 生成mp4 文件，使用omafvi 與omafvd 實現(xiàn)OMAF 封裝。

3.1.1 視窗獨立機制視頻生成

3.2 傳輸碼率分析

本文對視窗獨立傳輸機制、固定視窗源端綁定機制與自由視窗源端綁定機制進行了對比實驗。為了進行對比，三種機制下原始視頻的分辨率都為6K（6144x3072），通過wireshark 軟件進行抓包，并通過該wireshark 中的I/O Graphs 功能得到實測碼率數(shù)據(jù)，再計算出各種傳輸機制下的平均碼率如表1 所示。

表1： 三種傳輸機制實測平均碼率

從實驗結果上看，視窗獨立傳輸機制、固定視窗源端綁定機制與自由視窗源端綁定機制三種實測碼率分別為11.6Mbps、6.7Mbps 與7.7Mbps。固定視窗源端綁定機制與自由視窗源端綁定機制都是視窗依賴機制，視窗依賴機制相對于視窗獨立機制傳輸碼率上都有降低。固定視窗源端綁定機制能降低解碼視頻的分辨率，從6144x3072 降到了3840×2304，因此能顯著降低傳輸碼率。

3.3 清晰度分析

全景視頻清晰度以單位角度的像素數(shù) (pixel per degree,PPD) 來衡量，人眼能達到的理想分辨率大約為60PPD（每度像素數(shù)），在工業(yè)和信息化部印發(fā)的《關于加快推進虛擬現(xiàn)實產(chǎn)業(yè)發(fā)展的指導意見》中提出“實現(xiàn)30PPD（每度像素數(shù)）單眼角分辨率、100Hz 以上刷新率、毫秒級響應時間的新型顯示器件及配套驅(qū)動芯片的規(guī)模量產(chǎn)”，所以達到30PPD是目前全景視頻清晰度的一個目標。從表 2 可以看到要達到30PPD 的效果全景視頻需要12K 的分辨率，這對于目前的VR 頭盔是無法達到的一個高度，如何充分利用VR 頭盔硬件能力，達到最佳的呈現(xiàn)效果對全景視頻體驗至關重要。

表2： 全景視頻分辨率與PPD 的對應關系

對于VR 頭盔，解碼能力與屏幕分辨率是制約最終顯示清晰度的兩大因素。以Pico G2 4K 為例，該VR 頭盔可以解碼4K 分辨率的全景視頻，全景視頻為ERP 映射方式時，PPD 可以達到10.67。Pico G2 4K 屏幕分辨率為3840x2160，左右視場角為101 度，屏幕可以顯示的PPD 為(3840/2)/101=19。結合兩方面的數(shù)據(jù)，呈現(xiàn)ERP 映射的全景視頻，最高的清晰度只能達到10.67，屏幕顯示能力還未允分發(fā)揮。

在不降低視窗區(qū)域內(nèi)的圖像質(zhì)量下減小全景視頻的分辨率，可允分利用頭盔的解碼與屏幕顯示能力，如圖 2 的6K ERP 方案中，原始視頻的分辨率為6144×3072，通過區(qū)域封裝后，在終端組合的視頻分辨率為3840×2304，達到4K 水平，但視窗區(qū)域內(nèi)的圖像質(zhì)量保持原始6K 的效果，這樣可使最終觀看的像素密度由原來10.67 提高到17。

3.4 交互延時分析

OMAF 視窗依賴傳輸機制下，但當用戶轉(zhuǎn)頭離開了高質(zhì)的視窗區(qū)域，用戶先看到低質(zhì)圖像，經(jīng)過一個時延再看到高質(zhì)圖像，這一切換過程就是交互延時。這個時間與MTP(Motion To Photons)不同，MTP 是指用戶開始轉(zhuǎn)頭到呈現(xiàn)出圖像的時間差。在OMAF 視窗依賴傳輸機制下，用戶轉(zhuǎn)頭后會在MTP 時間里先看到低質(zhì)圖像，然后再切換高質(zhì)圖像。交互時間太長會使用戶無法忍耐，當切換時間超過1秒后，用戶很可能認為無法切換到高質(zhì)圖像，而導致轉(zhuǎn)看其他視角或放棄觀看全景視頻。

本文對視窗依賴傳輸機制時，不同分辨率視頻交互延時進行了測試，結果如表 3 所示，交互延時隨全景視頻分辨率提高而變長，在8K 分辨率時切換時間達到1.48 秒，用戶明顯感覺切換時間比較長。

表3： 高質(zhì)視頻恢復時間

4 結束語

OMAF 標準提供了多種傳輸機制，這些傳輸機制各有特點，為終端提供了多種全景視頻傳輸與呈現(xiàn)選擇。在帶寬受限的情況下可以采用視窗依賴機制，尤其固定視窗源端綁定機制可以節(jié)約更多的帶寬。若終端設備的解碼能力有限時，為了充分利用設備的屏幕顯示能力，可以選擇一些固定視窗源端綁定機制，如6KERP 方案。但使用OMAF 傳輸機制時需要注意到采用OMAF 標準后帶來的交互延時，盡量避免交互延時過長。