?作者｜高立文

1. 行業(yè)現(xiàn)狀和技術(shù)挑戰(zhàn)

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

視頻源方面，因 VR 眼鏡獨(dú)有的 FOV（Field of View，視場角，VR 設(shè)備的重要指標(biāo)之一，反映視野廣度），4K 全景視頻在 VR 眼鏡上看起來也就只相當(dāng)于 540P，所以 8K 分辨率視頻的分發(fā)也僅僅是超高清畫質(zhì)體驗(yàn)的“入門級需求”。另外，一些游戲、體育賽事等內(nèi)容的視頻對幀率也有很高的要求，達(dá)到 120fps 才會有較好的體驗(yàn)；傳輸方面，要實(shí)現(xiàn)對這類「富媒體」的超低延時(shí)傳輸則是個(gè)很大的挑戰(zhàn)，帶寬需達(dá)到 150Mbps 以上。

VR 眼鏡方面，最近兩年 VR 一體機(jī)技術(shù)發(fā)展迅速，它 All-in-one 的設(shè)計(jì)脫離了外部設(shè)備的連線束縛，即開即用，受到了市場的廣泛歡迎，有逐漸代替 VR 頭顯之勢。不過，“便攜”的優(yōu)點(diǎn)也不可避免地會影響它在解碼、渲染、帶寬處理上的性能表現(xiàn)，在處理上述 8K@120fps / 150Mbps 的任務(wù)時(shí)需要進(jìn)行特殊處理。

當(dāng)前行業(yè)使用的一些解決方案在視頻質(zhì)量/幀率/延時(shí)/帶寬等各方面做了取舍，導(dǎo)致最終用戶體驗(yàn)不太理想：要么是無法忍受的圖像質(zhì)量（低畫質(zhì)），或者是低幀率帶來的眩暈（低幀率），又或是無法忍受的延時(shí)（高延時(shí)），以及巨額的帶寬成本（最后一公里全景下發(fā)）等，像業(yè)內(nèi)采用的「直播轉(zhuǎn)碼」+ 「CDN 分發(fā)鏈路」方案，一方面它的延時(shí)較高，無法適用于一些互動(dòng)性較高的場景；另一方面，由于在云端進(jìn)行了一次轉(zhuǎn)碼，對畫質(zhì)會產(chǎn)生一定的損傷，也會影響用戶的“沉浸式”體驗(yàn)。

利用 RTC 傳輸這類「富媒體」到 VR 一體機(jī)可以較好地解決高畫質(zhì)和低延時(shí)的問題，但也面臨著一些難點(diǎn)。

1.1 8K 和 120 fps 難以兼得

上文已提到，在 VR 場景中，像云游戲、大型展會、賽事等內(nèi)容的視頻，「高分辨率」和「高幀率」缺一不可。然而我們發(fā)現(xiàn)，不管是 GPU 還是 VR 一體機(jī)的芯片，其編解碼能力都無法兼顧到「8K」和「120 fps」性能體驗(yàn)。我們使用了 gpu-z 工具和 Nsight 工具分析了 Nvidia Tesla T4 硬件的編碼能力，分析發(fā)現(xiàn)，當(dāng)視頻源達(dá)到 8K 分辨率時(shí)，單張 Nvidia Tesla T4 最高只能支持到 8K@60fps，且存在性能波動(dòng)，一般單張顯卡的性能穩(wěn)定在 8K@50fps。

以下為測試數(shù)據(jù)：

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

以下為測試數(shù)據(jù)：

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

1.2 全解碼方案引起帶寬性能不足

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

以下為三大運(yùn)營商2021年下行速度中值數(shù)據(jù)：

數(shù)據(jù)來源：《2021年全國網(wǎng)絡(luò)速度和質(zhì)量報(bào)告》

從合理性上看，VR 眼鏡由于視角問題，觀看端并不需要同時(shí)解碼全場景的畫面內(nèi)容，全解碼方案浪費(fèi)了大部分的碼流帶寬占用，造成了很大的下行帶寬，給最后一公里帶來了巨大的壓力，不利于互聯(lián)網(wǎng)分發(fā)。

1.3 頭動(dòng)延時(shí)高易引起眩暈

MTP（Motion To Photons）是 VR 眼鏡的另一個(gè)重要指標(biāo)，指從頭動(dòng)到顯示出相應(yīng)畫面的時(shí)間，MTP 時(shí)延太大容易引起眩暈，目前公認(rèn)的是，當(dāng) MTP 時(shí)延低于 20ms 就能大幅減少暈動(dòng)癥的發(fā)生。

2. 火山引擎 RTC 做了什么

2.1 總體介紹

為了解決上述難題，火山引擎 RTC 引入了 FoV 方案，即讓接收端只接收視角區(qū)域內(nèi)的高清碼流來解決編解碼性能不足和帶寬不足的問題。另外，我們通過同時(shí)傳輸高清的 tile 碼流和低清的全景背景碼流，避免因快速頭動(dòng)導(dǎo)致視角切換而引起的黑屏。利用火山引擎覆蓋全球的實(shí)時(shí)音視頻網(wǎng)絡(luò)邊緣節(jié)點(diǎn)，最終可實(shí)現(xiàn)低清背景 MTP < 20ms，高清 FoV 流 MTP < 100ms。

如圖所示，首先，編碼端將一路 8K 視頻劃分成若干個(gè) tile（在 HEVC中，從水平和垂直方向?qū)D像分割為若干個(gè)矩形區(qū)域，把這些矩形區(qū)域稱為 tile，每個(gè) tile 都可以獨(dú)立編碼解碼），對每個(gè) tile 使用 nvenc 單獨(dú)進(jìn)行編碼；同時(shí)編碼一個(gè) 2K 的全景圖，它可以在接收端做“兜底”，又不會引入較大的碼率增加導(dǎo)致解碼端性能跟不上；然后，在媒體服務(wù)器側(cè)，上行通過一個(gè) ssrc 同時(shí)接收高清 tile 流和低清背景流，其中下行高清 tile 流按照用戶視場角過濾轉(zhuǎn)發(fā)，下行低清背景流不過濾直接全部轉(zhuǎn)發(fā)；最后，接收端按照 HEVC tile 標(biāo)準(zhǔn)，將所有 tile 按照圖像的位置合并成一路原始大小的編碼視頻，解碼，上屏。

下文詳細(xì)介紹火山引擎 RTC FoV 方案的實(shí)現(xiàn)與優(yōu)化。

2.2 編碼的實(shí)現(xiàn)與優(yōu)化

2.2.1 多 GPU 分布式編碼

上文提到，由于單張 Nvidia Tesla T4 不具備 8K@120fps 的編碼能力，所以需要通過多 GPU 并行編碼來實(shí)現(xiàn)?；鹕揭?RTC 在編碼側(cè)采用多 Nvidia Tesla T4 顯卡并行，將 8K 視頻切割成 72 個(gè) tile，使用 72 個(gè)編碼器進(jìn)行編碼，然后通過 RTP 打包發(fā)送到網(wǎng)絡(luò)。

這里需要注意的是不是所有的顯卡都能創(chuàng)建多個(gè)硬編碼器，個(gè)人消費(fèi)級顯卡對于編碼器的個(gè)數(shù)是有限制的，Nvidia 的顯卡可以在官網(wǎng)進(jìn)行查詢。

2.2.2 碼率控制

碼率的準(zhǔn)確性對下行可接入的 VR 一體機(jī)數(shù)量比較重要，但測試中我們發(fā)現(xiàn)編碼器碼率控制有時(shí)會不準(zhǔn)，且單純調(diào)節(jié)編碼器的編碼參數(shù)并不能解決這個(gè)問題，于是需要在硬編碼器內(nèi)部定時(shí)對編碼器的實(shí)際編碼碼率進(jìn)行監(jiān)控，監(jiān)控頻度設(shè)置為 10s，如果實(shí)際編碼低于預(yù)期碼率則統(tǒng)一調(diào)高所有編碼器的碼率，反之則調(diào)低，調(diào)整粒度為 10%。經(jīng)測試，增加碼率監(jiān)控后能夠穩(wěn)定碼率為預(yù)設(shè)碼率。

2.2.3 編碼器復(fù)雜度調(diào)整

編碼器的復(fù)雜度在默認(rèn)情況下是在創(chuàng)建完成編碼器的時(shí)候確認(rèn)好的，中間不能動(dòng)態(tài)修改，這樣會存在如下問題：

• 編碼器計(jì)算資源過剩的時(shí)候不能充分利用編碼器，如果編碼器的使用率很低是可以提高編碼器的編碼復(fù)雜度，從而提高畫質(zhì)。
• 編碼器可能會受到整個(gè)系統(tǒng)的性能影響而出現(xiàn)性能下降，如系統(tǒng)的時(shí)鐘頻率被降頻會影響編碼器的性能，如果此時(shí)能夠降低編碼器的復(fù)雜度，從而保障整個(gè)視頻的流程會對整體體驗(yàn)有所提高。

編碼器的復(fù)雜度可以通過 preset 來劃分，不同的 preset 表示了不同的復(fù)雜度（對于 preset 的詳細(xì)說明可參考 Nvidia 官網(wǎng)的資料），我們實(shí)測數(shù)據(jù)如下：

通過測試數(shù)據(jù)，我們發(fā)現(xiàn) preset p1 和 p4 是兩個(gè)性能臨界，可以通過動(dòng)態(tài)調(diào)整 preset 來提升編碼復(fù)雜度，進(jìn)而提升編碼的畫質(zhì)（preset 的動(dòng)態(tài)設(shè)置耗時(shí)不大，不會導(dǎo)致畫面卡頓）。因此，我們將當(dāng)前默認(rèn)設(shè)置的 preset 調(diào)整為 p4，如果 p4 性能不能保障實(shí)時(shí)性，則回退到 p1。

2.3 解碼的實(shí)現(xiàn)與優(yōu)化

2.3.1 按 FoV 視場角下發(fā)視頻

一些直播場景中已經(jīng)開始使用 FoV 方案，但目前還沒有 RTC 廠商來按視場角下發(fā)視頻內(nèi)容。

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

2.3.2 投影方式的選擇

球面和平面之間圖像的映射問題，是一個(gè)從古時(shí)候起就一直困擾著地圖測繪員的問題。今天，隨著 VR 全景視頻的發(fā)展，又將這一問題擺在了開發(fā)者面前。VR 全景視頻需要傳輸，涉及到帶寬占用和畫質(zhì)損傷的問題， 不同的投影方式會對畫質(zhì)及碼率造成較大的影響。

引用自：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ù)接收，且更利于視頻編碼器做畫質(zhì)優(yōu)化。

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

｜

2.3.3 從姿態(tài)信息計(jì)算視場角范圍內(nèi) tile

定義正前方是零點(diǎn)向量，視場角邊界是 tile 向量，零點(diǎn)向量和 tile 向量夾角小于 X° 范圍內(nèi)的 tile，都是視場角范圍內(nèi)的 tile。

如上圖所示，粉色+黃色是全景的視頻，劃分成了 72 個(gè) 640x640 的區(qū)域，黃色區(qū)域是根據(jù)向量夾角計(jì)算出來的視場角范圍內(nèi)的 tile，然后接收端向 RTC 邊緣媒體服務(wù)器請求，下發(fā)這些 tile。

2.3.4 合成

接收端按照 HEVC tile 標(biāo)準(zhǔn)，將所有 tile 按照圖像的位置合并成一路原始大小的編碼視頻；同時(shí)，將 2K 低清流進(jìn)行放大，并將高清 FoV 流在渲染前貼到對應(yīng)的坐標(biāo)位置。

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

如果頭動(dòng)較慢，VR 頭顯中看到的都是高清的視野范圍，所以不會對實(shí)際體驗(yàn)造成影響；如果產(chǎn)生快速的頭動(dòng)，那就無法避免在視野范圍內(nèi)看到一些低清的圖像，此時(shí)播放端會根據(jù)頭動(dòng)范圍重新請求高清 FoV 碼流，此時(shí)會有短暫的時(shí)間看到低清圖像，等到高清 FoV 范圍的碼流下發(fā)下來之后，畫面就會恢復(fù)高清 8K 效果。

2.4 頭動(dòng)延時(shí)優(yōu)化

2.4.1 頭動(dòng)延時(shí)

頭動(dòng)延時(shí) = 最后一公里網(wǎng)絡(luò)rtt + GOP/2 + jitter_buffer + 解碼 + 上屏

2.4.2 視場角預(yù)測

下圖說明了“視場角預(yù)測”的流程，即，用戶當(dāng)前 FoV -> 轉(zhuǎn)頭 -> 控制信令（攜帶預(yù)測結(jié)果） -> RTC 邊緣媒體服務(wù)器 -> 下發(fā)新的 tile -> 更新 FoV 內(nèi)容。

行業(yè)中已經(jīng)有一些比較成熟的視角預(yù)測方案，當(dāng)用戶頭部旋轉(zhuǎn)時(shí)，可以根據(jù)旋轉(zhuǎn)加速度進(jìn)行預(yù)測未來旋轉(zhuǎn)的角度位置，甚至可以根據(jù)用戶的動(dòng)作預(yù)測轉(zhuǎn)動(dòng)角度和方向，再根據(jù)預(yù)測進(jìn)行拉取相應(yīng)數(shù)據(jù)，可以達(dá)到很好的預(yù)判以及降低延時(shí)效果。

首先，這里僅采用本用戶自身的歷史數(shù)據(jù)來預(yù)測其未來視角，其次，為了適應(yīng)用戶的較快速頭動(dòng)模式，選擇了速度較快的 ML 算法來預(yù)測。

3. 方案落地體驗(yàn)

上述方案在實(shí)際落地中的表現(xiàn)如下：

在 GOP=15 的情況下，8K 高清頭動(dòng)延時(shí)在 100ms，端到端延時(shí)為 130ms+，下行碼率約 20Mbps，數(shù)據(jù)表現(xiàn)理想。

實(shí)際體驗(yàn)效果如下：

注：

1、為了表現(xiàn)高清 FoV 視頻和低清背景視頻的區(qū)別，我們給低清視頻添加了綠色濾鏡

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

當(dāng)頭動(dòng)速度較慢時(shí)，視場角范圍內(nèi)只能看到高清的圖，看不到綠色的低清圖。

當(dāng)頭動(dòng)速到較快時(shí)，才會偶爾有綠色的低清 tile 塊進(jìn)入到視場角范圍內(nèi)（想象一下，如果沒有低清視頻流兜底，用戶看到的將是缺失的畫面）。

4. 總結(jié)與展望

4.1 總結(jié)

火山引擎 RTC FoV 方案通過如下的技術(shù)優(yōu)化，實(shí)現(xiàn)了 8K@120fps 全景視頻的實(shí)時(shí)傳輸：

1. 對 8k 高清視頻進(jìn)行分片，支持多 GPU 分布式并行編碼；
2. 按需下發(fā)和解碼視場角范圍的視頻分片，極大程度降低了下行帶寬要求，并且實(shí)現(xiàn)基于 4K 解碼器能力達(dá)到全景 8K 的畫質(zhì)體驗(yàn)；
3. 通過視角預(yù)測，極大地降低了高清視頻的頭動(dòng)延時(shí)（MTP）< 100ms；

4.2 后續(xù)優(yōu)化

當(dāng)前方案仍有不少優(yōu)化空間。

比如當(dāng)前在解碼端將 2K 低清背景流到放大到 8K 高清流的采用的是傳統(tǒng)的縮放算法，會對畫質(zhì)造成一定的損失，使用超分算法會極大的提高低清背景的優(yōu)化體驗(yàn)。

AI 頭動(dòng)預(yù)測，利用多個(gè)用戶的頭動(dòng)數(shù)據(jù)學(xué)習(xí)得到具有群體共性的頭動(dòng)模式，從而能在未來一段時(shí)間內(nèi)加快內(nèi)容預(yù)取，進(jìn)行預(yù)測。

另外，目前 Nvidia 和高通主流芯片平臺均已支持 HDR 10 的編碼和解碼 (High-Dynamic Range，是一種提高影像亮度和對比度的處理技術(shù)，它可以將每個(gè)暗部的細(xì)節(jié)變亮，暗的地方更暗，豐富更多細(xì)節(jié)色彩) ，我們后續(xù)也將引入 HDR 10 技術(shù)來進(jìn)一步提升畫質(zhì)體驗(yàn)，讓用戶更接近真實(shí)環(huán)境中的視覺感受。