新的視訊會議模式：StarlineProject

目錄

• ​​效果展示部分​​
• ​​使用者參與度部分​​
• ​​技術細節​​

• ​​機械裝置以及硬體配置。​​
• ​​視訊系統​​

• ​​照明​​
• ​​人臉跟蹤​​
• ​​壓縮和傳輸​​
• ​​圖像渲染​​

• ​​音頻系統​​

• ​​step1：捕獲音頻​​
• ​​step2：音頻去噪處理​​
• ​​step3：壓縮、傳輸、解壓​​
• ​​step4：渲染​​

• ​​可以改進的點​​

效果展示部分

〔映維網〕谷歌光場顯示屏Project Starline

Starline 本質上是一個 3D 視訊聊天室，旨在取代一對一的 2D 視訊電話會議，讓使用者感覺就像坐在真人面前一樣。

互相視訊的人，不需要佩戴任何眼鏡或者頭盔，真實的就像坐在對面聊天。

使用者參與度部分

google組織了117名參與者在九個月期間共舉行308次會議，平均持續時間為35.2分鐘，并産生了共有296份調查回複。

超過87%的調查回複Starline項目在在場感、注意力、個人聯系、反應評估四個方面，比傳統視訊會議略好或好得多。

(W-P)統計表明，所有情緒改善在統計上顯著

他們回憶的會議内容相較于傳統視訊回憶大約多了28% ，參與者在我們的系統中也顯著地表現出更多的非語言行為(手勢、點頭和眉毛運動)，這有利于促進融洽的人際關系。

觀察到的平均延遲為105.8 ms(标準偏差9.1 ms)，在人類參與者感覺同步對話所需的250 ms上限之内。

綜合表明，即使Starline的3D重建在視覺上存在缺陷，仍然提供了一場更投入的交流體驗。

技術細節

機械裝置以及硬體配置。

首先來看看機械裝置以及硬體配置。

Project Starline 系統圍繞一個以 60Hz 運作的大型 65 英寸 8K 面闆建構， 三個用于捕獲彩色圖像和深度資料的「捕獲 pod」 ， 還包括四個額外的追蹤攝像頭、四個麥克風、兩個揚聲器和一個紅外投影儀 。

系統需要捕獲來自四個視角的彩色圖像以及三個深度圖，共計七個視訊流。系統還需要捕獲 44.1 kHz 的音頻，并以 256 Kbps 編碼。

Project Starline 配備了四塊高端 Nvidia 顯示卡（兩塊 Quadro RTX 6000 卡和兩塊 Titan RTX）來對所有這些資料進行編碼和解碼。

基于螢幕的系統的原因：

1、目前大多數AR和VR頭盔的重量和不适

2、還消除了通過耳機捕捉人臉的困難

3、目前沒有一款AR頭盔有足夠的視野跨越人體坐姿的寬度和高度。

是以選擇了基于65英寸8K面闆、33.1M全彩像素在60赫茲更新的頭跟蹤自動立體顯示器。

視訊系統

照明

選擇漫射源的原因：

1、這種擴充的光線也比明亮的led直接照明更舒适。

2、完全一緻的入射光線使人臉和其他3D形狀看起來扁平和人造，阻礙了系統中的其他3D線索。

人臉跟蹤

3D人臉追蹤的重點在于定位眼睛、嘴巴、耳朵的位置。

眼睛的位置決定了渲染的立體視點，并且在顯示的時候我們是需要引導左右視圖指向對應的眼睛的。

嘴巴的位置使得音頻捕獲中的波束形成成為可能。

嘴和耳朵的位置有助于空間化音頻渲染和串擾消除

3D人臉追蹤的延遲大約是33ms，通過預測跟蹤功能緩解延遲，但是又會放大噪聲，導緻渲染的視點抖動。采用雙指數平滑 + 遲滞濾波器解決這個問題。

壓縮和傳輸

對于壓縮和傳輸方面

我們使用的是傳統視訊壓縮傳輸多幅圖像+立體重構的深度圖。延遲融合，直到在接受端才渲染出左右眼視圖。

顔色資料流和深度資料流使用H265編解碼器 和 YUV420色度分采樣進行編碼。

顔色流每個channel使用8位，深度流每個channel10位。

省略雙向編碼(B)幀來減少編碼和解碼延遲。

這樣就有7個視訊流 + 跟蹤的人臉點。将這個視訊包到一個單一資料負載，使用WebRTC傳輸。

若傳輸逾時，發送所有7個視訊流的内部(I)幀來重新初始化。

最終效果：産生的傳輸帶寬在30~100Mbit/s，這取決于使用者衣服中的紋理細節和他們手勢的大小

圖像渲染

每個立體深度圖像的貢獻以及由此産生的融合表面

我們将每一幅彩色圖像投射到融合表面上，并使用從表面法線确定的混合權重(黃色)來組合這些圖像

然後使用高斯濾波器自适應地沿深度不連續面模糊合成圖像

而傳統的3D圖像模組化渲染并非如此。

傳統的TSDF步驟是這樣的：

step1：在GPU顯存中建構出一大塊空區域volume，由多個voxel體素構成

step2：計算每個體素的TSDF值以及權重。SDF指的是它到最近的表面的距離，S代表截斷

step3：得到一幀圖像的TSDF結果，為0的體素表示物體的表面

step4：使用栅格更新法，也就是多個圖檔觀測融合 。（其實是一個疊代形式的權重最小二乘解，通過不斷按照上式融合觀測值，可以構造出整個地圖的 TSDF 場，并插值求出障礙物曲面 ）

傳統的體素融合是光線投射疊代采樣預先計算的TSDF體素網格。

而Google的基于圖像的方法通過投影采樣輸入深度圖像并取權重平均值來實時評估融合的符号距離。

該方法在沿着光線前進時就進行了即時的TSDF融合，并使用CUDA将計算在光線上并行化，是以這個算法更加快速。

又因為它時讀取緩存的2D紋理，避免建立了體素網格，是以這種方法相較于傳統的計算TSDF來說更加節省顯示卡記憶體。

音頻系統

音頻子系統的設計目的是為了從聲音環境中高品質地捕捉每個說話人的聲音，高保真地壓縮、傳輸和解壓提取的聲音，并将每個說話人的聲音精确地、自然地三維空間化渲染給對方的聽衆。

step1：捕獲音頻

音頻以44.1 kHz的采樣率被采集，使用四個心型麥克風作為線性陣列排列在中間牆的下部捕獲艙

音頻捕獲系統并沒有執行“盲”聲源分離來提取目标說話者，而是使用3D口部跟蹤系統在自然對話過程中引導波束形成到說話者的嘴部。

step2：音頻去噪處理

捕獲之後依次執行下面的步驟：

1、環境降噪:系統隻将兩個參與者的聲音從一端傳到另一端

2、混響降低:收發雙方均接受室内混響

3、聲回波消除(AEC):揚聲器播放的音頻必須從麥克風捕獲的信号中删除

那麼我們是如何實作的呢？

• 四個單向，心髒型麥克風是面向說話者的一般方向，建立了一個基本的方向接收模式，初始的噪聲和混響減少。
• 跟蹤導向、超定向和噪聲限制的最佳方向性波束形成。使用麥克風陣列來銳化定向接收，并進一步降低噪聲和混響。
• 自适應權重預測誤差處理，進一步降低混響
• WebRTC提供單通道降噪和AEC

step3：壓縮、傳輸、解壓

WebRTC可以進行壓縮、傳輸和解壓。

單通道44.1 kHz音頻使用Opus編解碼器(http://opus-codec.org/)以256 Kbps的目标速率進行編碼。

WebRTC/Opus解碼器處理傳輸相關因素，如采樣率不比對和丢包隐藏。

step4：渲染

音頻捕獲和渲染。立體聲揚聲器發出一個虛拟的雙耳信号，利用串擾消除和振幅平移的混合組合，持續跟蹤說話者和聽者的位置。

首先，跟蹤的說話者和聽者的位置動态地結合一個通用的頭部相關傳遞函數(HRTF)來産生一個實時跟蹤的雙耳信号。

頭相關傳輸函數（Head Related Transfer Function；HRTF）用于描述聲波從聲源到雙耳的傳輸過程，是一種聲音定位算法。當聲音向我們傳輸而來時，HRTF将對應于我們頭部的相位與頻率響應。

對于頭相關傳輸函數HRTF，它們描述了人類解剖結構對來自任何給定位置的聲音所産生的影響。

然後，利用聽者跟蹤雙耳串擾消除将雙耳信号轉換為立體聲揚聲器輸出具有相同的HRTF模型。

如果耳朵位置跟蹤不準确，會導緻人耳可聽的高頻噪聲。

是以我們的處理是這樣的：

• 小于1500hz，耳間時差(ITD)提示主導感覺聲音定位
• 大于1500hz，使用基于矢量的振幅平移的泛化方法對揚聲器輸出進行權重

左右耳朵的音量差異據取決于耳間水準差（interaural level difference；ILD），其中的延遲則稱作耳間時間差（interaural time difference；ITD）或雙耳時間差（binaural time difference）。

可以改進的點

1、在圖像系統中，對于稀薄和半透明的幾何形狀(如頭發和眼鏡)、深凹和快速運動可能會導緻重構深度圖中的錯誤或空洞，進而導緻不正确的幾何和紋理錯誤。需要進行進一步的工作來克服這種僞迹。可以在渲染端部署相關去僞迹算法。

2、目前的視訊壓縮标準會利用視圖中備援減少總體帶寬，但是主要是針對于相機陣列，缺乏實時編碼實作。