?作者｜高立文
1. 行業(yè)現(xiàn)狀和技術挑戰(zhàn)
VR 眼鏡的出現(xiàn)與快速發(fā)展讓“賽博朋克”、“未來世界”不再遙遠，通過手柄與音視頻畫面的互動，人們可以在娛樂、健身時體會到一種全面超越現(xiàn)有音視頻的“沉浸式”體驗。而在體驗云游戲、大型全景賽事互動等應用時，如果想保持這種“身臨其境”的“沉浸式”體驗，還需要有超高清、高幀率的全景視頻源、強勁的傳輸帶寬和超低頭動延時（MTP）。
視頻源方面，因 VR 眼鏡獨有的 FOV（Field of View，視場角，VR 設備的重要指標之一，反映視野廣度），4K 全景視頻在 VR 眼鏡上看起來也就只相當于 540P，所以 8K 分辨率視頻的分發(fā)也僅僅是超高清畫質體驗的“入門級需求”。另外，一些游戲、體育賽事等內容的視頻對幀率也有很高的要求，達到 120fps 才會有較好的體驗；傳輸方面，要實現(xiàn)對這類「富媒體」的超低延時傳輸則是個很大的挑戰(zhàn)，帶寬需達到 150Mbps 以上。
VR 眼鏡方面，最近兩年 VR 一體機技術發(fā)展迅速，它 All-in-one 的設計脫離了外部設備的連線束縛，即開即用，受到了市場的廣泛歡迎，有逐漸代替 VR 頭顯之勢。不過，“便攜”的優(yōu)點也不可避免地會影響它在解碼、渲染、帶寬處理上的性能表現(xiàn)，在處理上述 8K@120fps / 150Mbps 的任務時需要進行特殊處理。
當前行業(yè)使用的一些解決方案在視頻質量/幀率/延時/帶寬等各方面做了取舍，導致最終用戶體驗不太理想：要么是無法忍受的圖像質量（低畫質），或者是低幀率帶來的眩暈（低幀率），又或是無法忍受的延時（高延時），以及巨額的帶寬成本（最后一公里全景下發(fā)）等，像業(yè)內采用的「直播轉碼」+ 「CDN 分發(fā)鏈路」方案，一方面它的延時較高，無法適用于一些互動性較高的場景；另一方面，由于在云端進行了一次轉碼，對畫質會產生一定的損傷，也會影響用戶的“沉浸式”體驗。
利用 RTC 傳輸這類「富媒體」到 VR 一體機可以較好地解決高畫質和低延時的問題，但也面臨著一些難點。
1.1 8K 和 120 fps 難以兼得
上文已提到，在 VR 場景中，像云游戲、大型展會、賽事等內容的視頻，「高分辨率」和「高幀率」缺一不可。然而我們發(fā)現(xiàn)，不管是 GPU 還是 VR 一體機的芯片，其編解碼能力都無法兼顧到「8K」和「120 fps」性能體驗。我們使用了 gpu-z 工具和 Nsight 工具分析了 Nvidia Tesla T4 硬件的編碼能力，分析發(fā)現(xiàn)，當視頻源達到 8K 分辨率時，單張 Nvidia Tesla T4 最高只能支持到 8K@60fps，且存在性能波動，一般單張顯卡的性能穩(wěn)定在 8K@50fps。
以下為測試數(shù)據(jù)：
從解碼能力看，目前市場上主流的 VR 一體機（價位1500-2000元）基本都選用 高通 XR2 芯片，該芯片對外宣稱的解碼能力為 8K@60fps 或 4k@120fps，實測下來發(fā)現(xiàn)，8K@60fps 也是上限數(shù)值，實際難以穩(wěn)定在 8K@60fps。
以下為測試數(shù)據(jù)：
因此，編解碼的性能成為了支持 8K@120fps 最大的瓶頸。
1.2 全解碼方案引起帶寬性能不足
傳輸 8K@120fps 全景視頻需要 150Mbps 的帶寬，目前 5G 滲透率還不高，寬帶下載網(wǎng)速無法滿足這樣的傳輸條件。
以下為三大運營商2021年下行速度中值數(shù)據(jù)：
數(shù)據(jù)來源：《2021年全國網(wǎng)絡速度和質量報告》
從合理性上看，VR 眼鏡由于視角問題，觀看端并不需要同時解碼全場景的畫面內容，全解碼方案浪費了大部分的碼流帶寬占用，造成了很大的下行帶寬，給最后一公里帶來了巨大的壓力，不利于互聯(lián)網(wǎng)分發(fā)。
1.3 頭動延時高易引起眩暈
MTP（Motion To Photons）是 VR 眼鏡的另一個重要指標，指從頭動到顯示出相應畫面的時間，MTP 時延太大容易引起眩暈，目前公認的是，當 MTP 時延低于 20ms 就能大幅減少暈動癥的發(fā)生。
2. 火山引擎 RTC 做了什么
2.1 總體介紹
為了解決上述難題，火山引擎 RTC 引入了 FoV 方案，即讓接收端只接收視角區(qū)域內的高清碼流來解決編解碼性能不足和帶寬不足的問題。另外，我們通過同時傳輸高清的 tile 碼流和低清的全景背景碼流，避免因快速頭動導致視角切換而引起的黑屏。利用火山引擎覆蓋全球的實時音視頻網(wǎng)絡邊緣節(jié)點，最終可實現(xiàn)低清背景 MTP < 20ms，高清 FoV 流 MTP < 100ms。
如圖所示，首先，編碼端將一路 8K 視頻劃分成若干個 tile（在 HEVC中，從水平和垂直方向將圖像分割為若干個矩形區(qū)域，把這些矩形區(qū)域稱為 tile，每個 tile 都可以獨立編碼解碼），對每個 tile 使用 nvenc 單獨進行編碼；同時編碼一個 2K 的全景圖，它可以在接收端做“兜底”，又不會引入較大的碼率增加導致解碼端性能跟不上；然后，在媒體服務器側，上行通過一個 ssrc 同時接收高清 tile 流和低清背景流，其中下行高清 tile 流按照用戶視場角過濾轉發(fā)，下行低清背景流不過濾直接全部轉發(fā)；最后，接收端按照 HEVC tile 標準，將所有 tile 按照圖像的位置合并成一路原始大小的編碼視頻，解碼，上屏。
下文詳細介紹火山引擎 RTC FoV 方案的實現(xiàn)與優(yōu)化。
2.2 編碼的實現(xiàn)與優(yōu)化
2.2.1 多 GPU 分布式編碼
上文提到，由于單張 Nvidia Tesla T4 不具備 8K@120fps 的編碼能力，所以需要通過多 GPU 并行編碼來實現(xiàn)?；鹕揭?RTC 在編碼側采用多 Nvidia Tesla T4 顯卡并行，將 8K 視頻切割成 72 個 tile，使用 72 個編碼器進行編碼，然后通過 RTP 打包發(fā)送到網(wǎng)絡。
這里需要注意的是不是所有的顯卡都能創(chuàng)建多個硬編碼器，個人消費級顯卡對于編碼器的個數(shù)是有限制的，Nvidia 的顯卡可以在官網(wǎng)進行查詢。
2.2.2 碼率控制
碼率的準確性對下行可接入的 VR 一體機數(shù)量比較重要，但測試中我們發(fā)現(xiàn)編碼器碼率控制有時會不準，且單純調節(jié)編碼器的編碼參數(shù)并不能解決這個問題，于是需要在硬編碼器內部定時對編碼器的實際編碼碼率進行監(jiān)控，監(jiān)控頻度設置為 10s，如果實際編碼低于預期碼率則統(tǒng)一調高所有編碼器的碼率，反之則調低，調整粒度為 10%。經測試，增加碼率監(jiān)控后能夠穩(wěn)定碼率為預設碼率。
2.2.3 編碼器復雜度調整
編碼器的復雜度在默認情況下是在創(chuàng)建完成編碼器的時候確認好的，中間不能動態(tài)修改，這樣會存在如下問題：
- 編碼器計算資源過剩的時候不能充分利用編碼器，如果編碼器的使用率很低是可以提高編碼器的編碼復雜度，從而提高畫質。
- 編碼器可能會受到整個系統(tǒng)的性能影響而出現(xiàn)性能下降，如系統(tǒng)的時鐘頻率被降頻會影響編碼器的性能，如果此時能夠降低編碼器的復雜度，從而保障整個視頻的流程會對整體體驗有所提高。
編碼器的復雜度可以通過 preset 來劃分，不同的 preset 表示了不同的復雜度（對于 preset 的詳細說明可參考 Nvidia 官網(wǎng)的資料），我們實測數(shù)據(jù)如下：
通過測試數(shù)據(jù)，我們發(fā)現(xiàn) preset p1 和 p4 是兩個性能臨界，可以通過動態(tài)調整 preset 來提升編碼復雜度，進而提升編碼的畫質（preset 的動態(tài)設置耗時不大，不會導致畫面卡頓）。因此，我們將當前默認設置的 preset 調整為 p4，如果 p4 性能不能保障實時性，則回退到 p1。
2.3 解碼的實現(xiàn)與優(yōu)化
2.3.1 按 FoV 視場角下發(fā)視頻
一些直播場景中已經開始使用 FoV 方案，但目前還沒有 RTC 廠商來按視場角下發(fā)視頻內容。
為什么不用 SVC 或 Simulcast 做視頻下發(fā)？SVC 和 Simulcast 只能針對視頻全畫幅進行接收和解碼，會引起帶寬的增加或畫質的損失。而火山引擎的 FoV 方案中，一路高清視頻流按視角場異步下發(fā)和渲染，一路低清視頻流全量下發(fā)，既可以節(jié)省帶寬，也沒有降低畫質，還能避免因視角快速切換、高清視頻來不及傳輸導致看不到畫面。
2.3.2 投影方式的選擇
球面和平面之間圖像的映射問題，是一個從古時候起就一直困擾著地圖測繪員的問題。今天，隨著 VR 全景視頻的發(fā)展，又將這一問題擺在了開發(fā)者面前。VR 全景視頻需要傳輸，涉及到帶寬占用和畫質損傷的問題， 不同的投影方式會對畫質及碼率造成較大的影響。
引用自：https://leohope.com/%E8%A7%A3%E9%97%AE%E9%A2%98/2019/07/15/VR-mapping/
我們使用了 EAC 的投影方式，相對于簡單直觀的 ERP 投影，EAC 投影比 ERP 投影節(jié)省了 25% 的面積，接收端降低約 15% 的數(shù)據(jù)接收，且更利于視頻編碼器做畫質優(yōu)化。
下面兩組照片中，上圖為 ERP 投影，像素為 7680x3840 ；下圖為 EAC 投影，像素僅為 5760x3840。
｜
2.3.3 從姿態(tài)信息計算視場角范圍內 tile
定義正前方是零點向量，視場角邊界是 tile 向量，零點向量和 tile 向量夾角小于 X° 范圍內的 tile，都是視場角范圍內的 tile。
如上圖所示，粉色+黃色是全景的視頻，劃分成了 72 個 640x640 的區(qū)域，黃色區(qū)域是根據(jù)向量夾角計算出來的視場角范圍內的 tile，然后接收端向 RTC 邊緣媒體服務器請求，下發(fā)這些 tile。
2.3.4 合成
接收端按照 HEVC tile 標準，將所有 tile 按照圖像的位置合并成一路原始大小的編碼視頻；同時，將 2K 低清流進行放大，并將高清 FoV 流在渲染前貼到對應的坐標位置。
放大后效果如上圖，橙色部分為低清流，放大成為 8K；綠色部分為高清 FoV 流，為原始的 8K。
如果頭動較慢，VR 頭顯中看到的都是高清的視野范圍，所以不會對實際體驗造成影響；如果產生快速的頭動，那就無法避免在視野范圍內看到一些低清的圖像，此時播放端會根據(jù)頭動范圍重新請求高清 FoV 碼流，此時會有短暫的時間看到低清圖像，等到高清 FoV 范圍的碼流下發(fā)下來之后，畫面就會恢復高清 8K 效果。
2.4 頭動延時優(yōu)化
2.4.1 頭動延時
頭動延時 = 最后一公里網(wǎng)絡rtt + GOP/2 + jitter_buffer + 解碼 + 上屏
2.4.2 視場角預測
下圖說明了“視場角預測”的流程，即，用戶當前 FoV -> 轉頭 -> 控制信令（攜帶預測結果） -> RTC 邊緣媒體服務器 -> 下發(fā)新的 tile -> 更新 FoV 內容。
行業(yè)中已經有一些比較成熟的視角預測方案，當用戶頭部旋轉時，可以根據(jù)旋轉加速度進行預測未來旋轉的角度位置，甚至可以根據(jù)用戶的動作預測轉動角度和方向，再根據(jù)預測進行拉取相應數(shù)據(jù)，可以達到很好的預判以及降低延時效果。
首先，這里僅采用本用戶自身的歷史數(shù)據(jù)來預測其未來視角，其次，為了適應用戶的較快速頭動模式，選擇了速度較快的 ML 算法來預測。
3. 方案落地體驗
上述方案在實際落地中的表現(xiàn)如下：
在 GOP=15 的情況下，8K 高清頭動延時在 100ms，端到端延時為 130ms+，下行碼率約 20Mbps，數(shù)據(jù)表現(xiàn)理想。
實際體驗效果如下：
注：
1、為了表現(xiàn)高清 FoV 視頻和低清背景視頻的區(qū)別，我們給低清視頻添加了綠色濾鏡
2、視頻來源：https://www.youtube.com/watch?v=L_tqK4eqelA
當頭動速度較慢時，視場角范圍內只能看到高清的圖，看不到綠色的低清圖。
當頭動速到較快時，才會偶爾有綠色的低清 tile 塊進入到視場角范圍內（想象一下，如果沒有低清視頻流兜底，用戶看到的將是缺失的畫面）。
4. 總結與展望
4.1 總結
火山引擎 RTC FoV 方案通過如下的技術優(yōu)化，實現(xiàn)了 8K@120fps 全景視頻的實時傳輸：
- 對 8k 高清視頻進行分片，支持多 GPU 分布式并行編碼；
- 按需下發(fā)和解碼視場角范圍的視頻分片，極大程度降低了下行帶寬要求，并且實現(xiàn)基于 4K 解碼器能力達到全景 8K 的畫質體驗；
- 通過視角預測，極大地降低了高清視頻的頭動延時（MTP）< 100ms；
4.2 后續(xù)優(yōu)化
當前方案仍有不少優(yōu)化空間。
比如當前在解碼端將 2K 低清背景流到放大到 8K 高清流的采用的是傳統(tǒng)的縮放算法，會對畫質造成一定的損失，使用超分算法會極大的提高低清背景的優(yōu)化體驗。
AI 頭動預測，利用多個用戶的頭動數(shù)據(jù)學習得到具有群體共性的頭動模式，從而能在未來一段時間內加快內容預取，進行預測。
另外，目前 Nvidia 和高通主流芯片平臺均已支持 HDR 10 的編碼和解碼 (High-Dynamic Range，是一種提高影像亮度和對比度的處理技術，它可以將每個暗部的細節(jié)變亮，暗的地方更暗，豐富更多細節(jié)色彩) ，我們后續(xù)也將引入 HDR 10 技術來進一步提升畫質體驗，讓用戶更接近真實環(huán)境中的視覺感受。
