基於 RTC 的全景 8K@120fps FoV 實踐

動手點關注乾貨不迷路  :point_up_2:

1. 行業現狀和技術挑戰

VR 眼鏡的出現與快速發展讓“賽博朋克”、“未來世界”不再遙遠，通過手柄與音視訊畫面的互動，人們可以在娛樂、健身時體會到一種全面超越現有音視訊的“沉浸式”體驗。而在體驗雲遊戲、大型全景賽事互動等應用時，如果想保持這種“身臨其境”的“沉浸式”體驗，還需要有超高清、高幀率的全景視訊源、強勁的傳輸頻寬和超低頭動延時（MTP）。

視訊源方面，因 VR 眼鏡獨有的 FOV（Field of View，視場角，VR 裝置的重要指標之一， 反映 視野廣度），4K 全景視訊在 VR 眼鏡上看起來也就只相當於 540P，所以 8K 解析度視訊的分發也僅僅是超高清畫質體驗的“入門級需求”。另外，一些遊戲、體育賽事等內容的視訊對幀率也有很高的要求，達到 120fps 才會有較好的體驗；傳輸方面，要實現對這類「富媒體」的超低延時傳輸則是個很大的挑戰，頻寬需達到 150Mbps 以上。

VR 眼鏡方面，最近兩年 VR 一體機技術發展迅速，它 All-in-one 的設計脫離了外部裝置的連線束縛，即開即用，受到了市場的廣泛歡迎，有逐漸代替 VR 頭顯之勢。不過，“便攜”的優點也不可避免地會影響它在解碼、渲染、頻寬處理上的效能表現，在處理上述 8K@120fps / 150Mbps 的任務時需要進行特殊處理。

當前行業使用的一些解決方案在視訊質量/幀率/延時/頻寬等各方面做了取捨，導致終端使用者體驗不太理想：要麼是無法忍受的影象質量（低畫質），或者是低幀率帶來的眩暈（低幀率），又或是無法忍受的延時（高延時），以及鉅額的頻寬成本（最後一公里全景下發）等，像業內採用的「直播轉碼」+ 「CDN 分發鏈路」方案，一方面它的延時較高，無法適用於一些互動性較高的場景；另一方面，由於在雲端進行了一次轉碼，對畫質會產生一定的損傷，也會影響使用者的“沉浸式”體驗。

利用 RTC 傳輸這類「富媒體」到 VR 一體機可以較好地解決高畫質和低延時的問題，但也面臨著一些難點。

1.1 8K 和 120 fps 難以兼得

上文已提到，在 VR 場景中，像雲遊戲、大型展會、賽事等內容的視訊，「高解析度」和「高幀率」缺一不可。然而我們發現，不管是 GPU 還是 VR 一體機的晶片，其編解碼能力都無法兼顧到「8K」和「120 fps」效能體驗。我們使用了 gpu-z 工具和 Nsight 工具分析了 Nvidia Tesla T4 硬體的編碼能力，分析發現，當視訊源達到 8K 解析度時，單張 Nvidia Tesla T4 最高只能支援到 8K@60fps，且存在效能波動，一般單張顯示卡的效能穩定在 8K@50fps。

以下為測試資料：

從解碼能力看，目前市場上主流的 VR 一體機（價位1500-2000元）基本都選用 高通 XR2 晶片，該晶片對外宣稱的解碼能力為 8K@60fps 或 4k@120fps，實測下來發現，8K@60fps 也是上限數值，實際難以穩定在 8K@60fps。

以下為測試資料：

因此，編解碼的效能成為了支援 8K@120fps 最大的瓶頸。

1.2 全解碼方案引起頻寬效能不足

傳輸 8K@120fps 全景視訊需要 150Mbps 的頻寬，目前 5G 滲透率還不高，寬頻下載網速無法滿足這樣的傳輸條件。

以下為三大運營商2021年下行速度中值資料：

資料來源：《2021年全國網路速度和質量報告》

從合理性上看，VR 眼鏡由於視角問題，觀看端並不需要同時解碼全場景的畫面內容，全解碼方案浪費了大部分的碼流頻寬佔用，造成了很大的下行頻寬，給最後一公里帶來了巨大的壓力，不利於網際網路分發。

1.3 頭動延時高易引起眩暈

MTP（Motion To Photons）是 VR 眼鏡的另一個重要指標，指從頭動到顯示出相應畫面的時間，MTP 時延太大容易引起眩暈，目前公認的是，當 MTP 時延低於 20ms 就能大幅減少暈動症的發生。

2. 火山引擎 RTC 做了什麼

2.1 總體介紹

為了解決上述難題，火山引擎 RTC 引入了 FoV 方案，即讓接收端只接收視角區域內的高清碼流來解決編解碼效能不足和頻寬不足的問題。另外，我們通過同時傳輸高清的 tile 碼流和低清的全景背景碼流，避免因快速頭動導致視角切換而引起的黑屏。利用火山引擎覆蓋全球的實時音視訊網路邊緣節點，最終可實現低清背景 MTP < 20ms，高清 FoV 流 MTP < 100ms。

如圖所示，首先，編碼端將一路 8K 視訊劃分成若干個 tile（在 HEVC中，從水平和垂直方向將影象分割為若干個矩形區域，把這些矩形區域稱為 tile，每個 tile 都可以獨立編碼解碼），對每個 tile 使用 nvenc 單獨進行編碼；同時編碼一個 2K 的全景圖，它可以在接收端做“兜底”，又不會引入較大的位元速率增加導致解碼端效能跟不上；然後，在媒體伺服器側，上行通過一個 ssrc 同時接收高清 tile 流和低清背景流，其中下行高清 tile 流按照使用者視場角過濾轉發，下行低清背景流不過濾直接全部轉發；最後，接收端按照 HEVC tile 標準，將所有 tile 按照影象的位置合併成一路原始大小的編碼視訊，解碼，上屏。

下文詳細介紹火山引擎 RTC FoV 方案的實現與優化。

2.2 編碼的實現與優化

2.2.1 多 GPU 分散式編碼

上文提到，由於單張 Nvidia Tesla T4 不具備 8K@120fps 的編碼能力，所以需要通過多 GPU 並行編碼來實現。火山引擎 RTC 在編碼側採用多 Nvidia Tesla T4 顯示卡並行，將 8K 視訊切割成 72 個 tile，使用 72 個編碼器進行編碼，然後通過 RTP 打包傳送到網路。

這裡需要注意的是不是所有的顯示卡都能建立多個硬編碼器，個人消費級顯示卡對於編碼器的個數是有限制的，Nvidia 的顯示卡可以在官網進行查詢。

2.2.2 位元速率控制

位元速率的準確性對下行可接入的 VR 一體機數量比較重要，但測試中我們發現編碼器位元速率控制有時會不準，且單純調節編碼器的編碼引數並不能解決這個問題，於是需要在硬編碼器內部定時對編碼器的實際編碼位元速率進行監控，監控頻度設定為 10s，如果實際編碼低於預期位元速率則統一調高所有編碼器的位元速率，反之則調低，調整粒度為 10%。經測試，增加位元速率監控後能夠穩定位元速率為預設位元速率。

2.2.3 編碼器複雜度調整

編碼器的複雜度在預設情況下是在建立完成編碼器的時候確認好的，中間不能動態修改，這樣會存在如下問題：

• 編碼器計算資源過剩的時候不能充分利用編碼器，如果編碼器的使用率很低是可以提高編碼器的編碼複雜度，從而提高畫質。

• 編碼器可能會受到整個系統的效能影響而出現效能下降，如系統的時鐘頻率被降頻會影響編碼器的效能，如果此時能夠降低編碼器的複雜度，從而保障整個視訊的流程會對整體體驗有所提高。

編碼器的複雜度可以通過 preset 來劃分，不同的 preset 表示了不同的複雜度（對於 preset 的詳細說明可參考 Nvidia 官網的資料），我們實測資料如下：

通過測試資料，我們發現 preset p1 和 p4 是兩個效能臨界，可以通過動態調整 preset 來提升編碼複雜度，進而提升編碼的畫質（preset 的動態設定耗時不大，不會導致畫面卡頓）。 因此，我們將當前預設設定的 preset 調整為 p4，如果 p4 效能不能保障實時性，則回退到 p1。

2.3 解碼的實現與優化

2.3.1 按 FoV 視場角下發視訊

一些直播場景中已經開始使用 FoV 方案，但目前還沒有 RTC 廠商來按視場角下發視訊內容。

為什麼不用 SVC 或 Simulcast 做視訊下發？SVC 和 Simulcast 只能針對視訊全畫幅進行接收和解碼，會引起頻寬的增加或畫質的損失。而火山引擎的 FoV 方案中，一路高清視訊流按視角場非同步下發和渲染，一路低清視訊流全量下發，既可以節省頻寬，也沒有降低畫質，還能避免因視角快速切換、高清視訊來不及傳輸導致看不到畫面。

2.3.2 投影方式的選擇

球面和平面之間影象的對映問題，是一個從古時候起就一直困擾著地圖測繪員的問題。今天，隨著 VR 全景視訊的發展，又將這一問題擺在了開發者面前。VR 全景視訊需要傳輸，涉及到頻寬佔用和畫質損傷的問題， 不同的投影方式會對畫質及位元速率造成較大的影響。

引用自： http://leohope.com/%E8%A7%A3%E9%97%AE%E9%A2%98/2019/07/15/VR-mapping/

我們使用了 EAC 的投影方式，相對於簡單直觀的 ERP 投影，EAC 投影比 ERP 投影節省了 25% 的面積，接收端降低約 15% 的資料接收，且更利於視訊編碼器做畫質優化。

下面兩組照片中 ， 上圖為 ERP 投影，畫素為 7680x3840 ； 下圖為 EAC 投影，畫素僅為 5760x3840。

2.3.3 從姿態資訊計算視場角範圍內 tile

定義正前方是零點向量，視場角邊界是 tile 向量，零點向量和 tile 向量夾角小於 X° 範圍內的 tile，都是視場角範圍內的 tile。

如上圖所示，粉色+黃色是全景的視訊，劃分成了 72 個 640x640 的區域，黃色區域是根據向量夾角計算出來的視場角範圍內的 tile，然後接收端向 RTC 邊緣媒體伺服器請求，下發這些 tile。

2.3.4 合成

接收端按照 HEVC tile 標準，將所有 tile 按照影象的位置合併成一路原始大小的編碼視訊；同時，將 2K 低清流進行放大，並將高清 FoV 流在渲染前貼到對應的座標位置。

放大後效果如上圖，橙色部分為低清流，放大成為 8K；綠色部分為高清 FoV 流，為原始的 8K。

如果頭動較慢，VR 頭顯中看到的都是高清的視野範圍，所以不會對實際體驗造成影響；如果產生快速的頭動，那就無法避免在視野範圍內看到一些低清的影象，此時播放端會根據頭動範圍重新請求高清 FoV 碼流，此時會有短暫的時間看到低清影象，等到高清 FoV 範圍的碼流下發下來之後，畫面就會恢復高清 8K 效果。

2.4 頭動延時優化

2.4.1 頭動延時

頭動延時 = 最後一公里網路rtt + GOP/2 + jitter_buffer + 解碼 + 上屏

2.4.2 視場角預測

下圖說明了“視場角預測”的流程，即，使用者當前 FoV -> 轉頭 -> 控制信令（攜帶預測結果） -> RTC 邊緣媒體伺服器 -> 下發新的 tile -> 更新 FoV 內容。

行業中已經有一些比較成熟的視角預測方案，當用戶頭部旋轉時，可以根據旋轉加速度進行預測未來旋轉的角度位置，甚至可以根據使用者的動作預測轉動角度和方向，再根據預測進行拉取相應資料，可以達到很好的預判以及降低延時效果。

首先，這裡僅採用本使用者自身的歷史資料來預測其未來視角，其次，為了適應使用者的較快速頭動模式，選擇了速度較快的 ML 演算法來預測。

3. 方案落地體驗

上述方案在實際落地中的表現如下：

在 GOP=15 的情況下，8K 高清頭動延時在 100ms，端到端延時為 130ms+，下行位元速率約 20Mbps，資料表現理想。

實際體驗效果如下：

注：1、為了表現高清 FoV 視訊和低清背景視訊的區別，我們給低清視訊添加了綠色濾鏡

2、視訊來源：http://www.youtube.com/watch?v=L_tqK4eqelA

當頭動速度較慢時，視場角範圍內只能看到高清的圖，看不到綠色的低清圖。

當頭動速到較快時，才會偶爾有綠色的低清 tile 塊進入到視場角範圍內（想象一下，如果沒有低清視訊流兜底，使用者看到的將是缺失的畫面）。

4. 總結與展望

4.1 總結

火山引擎 RTC FoV 方案通過如下的技術優化，實現了 8K@120fps 全景視訊的實時傳輸：

1. 對 8k 高清視訊進行分片，支援多 GPU 分散式並行編碼；

2. 按需下發和解碼視場角範圍的視訊分片，極大程度降低了下行頻寬要求，並且實現基於 4K 解碼器能力達到全景 8K 的畫質體驗；

3. 通過視角預測，極大地降低了高清視訊的頭動延時（MTP）< 100ms；

4.2 後續優化

當前方案仍有不少優化空間。

比如當前在解碼端將 2K 低清背景流到放大到 8K 高清流的採用的是傳統的縮放演算法，會對畫質造成一定的損失，使用超分演算法會極大的提高低清背景的優化體驗。

AI 頭動預測，利用多個使用者的頭動資料學習得到具有群體共性的頭動模式，從而能在未來一段時間內加快內容預取，進行預測。

另外，目前 Nvidia 和高通主流晶片平臺均已支援 HDR 10 的編碼和解碼 (High-Dynamic Range，是一種提高影像亮度和對比度的處理技術，它可以將每個暗部的細節變亮，暗的地方更暗，豐富更多細節色彩) ，我們後續也將引入 HDR 10 技術來進一步提升畫質體驗，讓使用者更接近真實環境中的視覺感受。