?作者｜高立文
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 全景視頻需要傳輸，涉及到帶寬占用和畫質損傷的問題， 不同的投影方式會對畫質及碼率造成較大的影響。
引用自：https://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、視頻來源：https://www.youtube.com/watch?v=L_tqK4eqelA
當頭動速度較慢時，視場角范圍內只能看到高清的圖，看不到綠色的低清圖。
當頭動速到較快時，才會偶爾有綠色的低清 tile 塊進入到視場角范圍內（想象一下，如果沒有低清視頻流兜底，用戶看到的將是缺失的畫面）。
4. 總結與展望
4.1 總結
火山引擎 RTC FoV 方案通過如下的技術優化，實現了 8K@120fps 全景視頻的實時傳輸：
- 對 8k 高清視頻進行分片，支持多 GPU 分布式并行編碼；
- 按需下發和解碼視場角范圍的視頻分片，極大程度降低了下行帶寬要求，并且實現基于 4K 解碼器能力達到全景 8K 的畫質體驗；
- 通過視角預測，極大地降低了高清視頻的頭動延時（MTP）< 100ms；
4.2 后續優化
當前方案仍有不少優化空間。
比如當前在解碼端將 2K 低清背景流到放大到 8K 高清流的采用的是傳統的縮放算法，會對畫質造成一定的損失，使用超分算法會極大的提高低清背景的優化體驗。
AI 頭動預測，利用多個用戶的頭動數據學習得到具有群體共性的頭動模式，從而能在未來一段時間內加快內容預取，進行預測。
另外，目前 Nvidia 和高通主流芯片平臺均已支持 HDR 10 的編碼和解碼 (High-Dynamic Range，是一種提高影像亮度和對比度的處理技術，它可以將每個暗部的細節變亮，暗的地方更暗，豐富更多細節色彩) ，我們后續也將引入 HDR 10 技術來進一步提升畫質體驗，讓用戶更接近真實環境中的視覺感受。
