QoE驅動的VR視頻自適應采集與傳輸

黎潔，馮燃生，楊陽朝，孫偉，李奇越

（1.合肥工業大學 計算機與信息學院，合肥230000； 2.中國電子科技集團公司電子科學研究院，北京100084；3.合肥工業大學 電氣與自動化工程學院，合肥230000）

近年來，隨著交互式應用需求的興起，虛擬現實（Virtual Reality，VR）技術越來越受到用戶的廣泛歡迎，全景視頻流媒體傳輸就是其中最重要的應用之一。根據資料顯示［1］，全球幾大主要的流媒體服務運營商（Facebook、YouTube）已開始提供全景視頻流媒體服務［2］。為了給用戶提供更好的質量體驗（Quality of Experience，QoE），大多數VR視頻的分辨率已經達到了4K（4 096×2 160）甚至更高［3］。然而，由于網絡帶寬的限制，直接傳輸如此高分辨率的視頻不是一個可行的方案。因此，對于研究者來說在帶寬受限的條件下，進一步提高用戶的QoE是一項巨大的挑戰［4］。

當用戶觀看VR視頻時，由于顯示設備視場（Field of View，FoV）的限制，在任一時刻用戶往往只能觀看到整個視頻的某一部分。如果服務器傳輸整個視頻的話，大部分的帶寬資源會被不可避免地浪費掉。因此，基于DASH（Dynamic Adaptive Streaming over HTTP）［5］的自適應分塊傳輸方式是進行VR視頻流媒體傳輸最為提倡的一種方式。在分塊傳輸方式中，一個完整的VR視頻被分割成許多視頻塊，每個視頻塊被編碼成不同的質量等級，服務器根據網絡帶寬等因素為每個視頻塊自適應選擇一種最優的質量等級并傳輸到客戶端［6-8］。

在自適應分塊傳輸方式中，有2個最重要的方案：視角自適應和速率自適應。前者是預測用戶視角變化的核心，后者是服務器進行資源分配的核心。在此基礎上，出現了很多相關的研究［9-12］。Qian等［9］提 出 了 一 種 視 角 自 適 應 的360°視頻傳輸系統，該系統利用機器學習算法進行視角預測。Corbillon等［10］研究了基于通用理論模型的最優全景視頻流媒體傳輸系統，結果顯示所提出的最優系統與一般傳輸系統相比能夠節省45%的帶寬。文獻［11］設計了一種速率自適應算法，該算法可以最大化預定義的360°視頻的QoE值。此外，也有結合視角自適應和速率自適應的研究。Xie等［12］提出了基于概率模型的360°視頻傳輸系統360ProbDASH，該系統通過結合速率和視角自適應解決基于QoE的傳輸優化問題。

然而，上述VR視頻流媒體傳輸系統存在以下關鍵性限制：①只考慮了單個用戶，卻忽略了多用戶的情況。②僅針對下行鏈路（視頻服務器到終端用戶）傳輸，忽略了上行鏈路（VR視頻采集設備到視頻服務器）傳輸。事實上，VR視頻直播是另一種重要的應用，在學術界和工業界都受到越來越多的關注［13-14］。在VR視頻直播中，采集設備用于記錄VR視頻，并將視頻實時傳輸到服務器。多用戶可以使用相關顯示設備請求和觀看VR視頻。顯然，在帶寬有限的約束下，應仔細研究上下行鏈路視頻速率自適應傳輸算法。此外上行視頻和下行視頻是具有相關性的，單獨優化設計會降低系統整體性能，這使得在該VR視頻直播應用中速率自適應算法變得更加困難。因此，本文設計了一種面向多用戶的上下行鏈路聯合全景視頻流媒體采集和傳輸系統。該系統不僅加入了上行和下行鏈路傳輸，還同時考慮了多用戶情況下的速率自適應。此外，在所設計的系統基礎上，定義了一個QoE驅動下的多用戶資源分配問題。

1 上下行鏈路聯合VR視頻流媒體采集和傳輸

1.1 系統模型

圖1為系統應用場景。系統上行端VR采集設備一共有C個相機，下行端共有N個用戶。首先，每個相機拍攝出相同碼率的高清視頻，每個視頻都被編碼成不同的質量等級，獲得不同碼率的視頻，由服務器為C個視頻各選擇一種質量等級進行上行傳輸。然后，服務器將這C個視頻縫合成一個完整的VR視頻，并進行分塊和壓縮處理。最后，處理過的VR視頻會通過下行鏈路傳輸到每個用戶。此外，假設下行鏈路中還存在從用戶到服務器的端到端反饋信道，此反饋信道可以將每個用戶的帶寬信息及實時的視角信息傳輸到服務器，更好地幫助服務器進行視頻速率自適應選擇。

圖1 系統應用場景Fig.1 System application scenario

本文設計系統的結構如圖2所示。系統主要由4部分組成：C個相機、服務器、客戶端和N個用戶。

QoE驅動上行模塊和下行模塊一起完成優化傳輸的工作，即合理進行視頻碼率自適應選擇去最大化所有用戶的QoE。具體來說，服務器的工作流程為：首先，上行處理模塊為C個相機各選擇一種合適的碼率等級，當這些視頻上傳到服務器后，經過縫合、映射等處理生成了一個VR視頻。然后，下行處理模塊把完整的全景視頻分成多塊，并且將每塊視頻編碼成不同的質量等級。此時，在反饋信道中特征數據（用戶實時FoV信息、下行鏈路帶寬信息）的幫助下，下行處理模塊可以確定被傳輸的塊并為每塊視頻選擇最合適的質量等級。最后，這些塊都將通過下行鏈路進行傳輸，在傳輸的同時，下行處理模塊還將為每塊視頻選擇一種合適的調制與編碼策略（Module and Coding Scheme，MCS）。在客戶端中，當所有視頻塊通過下行鏈路傳輸到客戶端，它們經過解碼、映射、渲染等處理，最終通過顯示設備呈現給每個用戶。此外，客戶端的另一個功能是把用戶的實時FoV信息和下行鏈路帶寬信息通過反饋信道傳輸給服務器。

1.2 問題形成

圖2 系統結構Fig.2 System structure

假設系統中在上行端有C個相機（每個相機用c表示），下行端有N個用戶（每個用戶用n表示）。在各個方向上均勻安裝的C個相機能夠形成一個VR視頻采集系統，對每個相機c來說，其能夠拍攝產生D′種不同碼率等級（每種碼率等級為d′）的 視 頻，用表 示 碼 率 等 級 為d′的 相機c產生視頻的碼率。假設上行鏈路總帶寬為BWUL。當C個視頻上傳到服務器，服務器會對其進行縫合以生成一個VR視頻，再將其分成T塊（每塊用t表示），然后每塊被編碼成D種質量等級（d表示每種質量等級）。用表示 質 量 等級為d的視頻塊t的碼率。顯然，下行鏈路中每塊視頻的質量等級必定小于上行鏈路中每個視頻的質量等級。在下行鏈路中，假設一共有YDL個資源塊（RB），同時下行鏈路可以提供M 種MCS方案（每種方案用m表示）。用表示在MCS方案為m時，單個資源塊所能提供的比特率。

通過QoE表達式，本文的QoE驅動上下行鏈路聯合VR流媒體自適應采集和傳輸的問題可以描述為：確定上行鏈路中每個相機所拍攝的視頻的碼率等級，為下行鏈路中全景視頻的視頻塊選擇一種質量等級和一種MCS方案，來最大化整個系統中的所有用戶的QoE值。可以用問題P1來表示。

約束條件（3）和約束條件（4）是上行部分的約束。約束條件（3）表示任何一個相機c只能選擇一種碼率等級，約束條件（4）表示傳輸的C個視頻的總碼率不應當超出整個上行鏈路的總帶寬。

約束條件（5）～約束條件（7）是下行部分的約束。約束條件（5）和約束條件（6）分別表示任意視頻塊只能選擇一種MCS方案、一種質量等級。約束條件（7）確保了傳輸的所有視頻塊的總碼率不超過整個下行鏈路所有資源塊所能提供的比特率。

約束條件（8）是整個系統上下行鏈路聯合的約束，表示下行鏈路中任意視頻塊的碼率不大于上行鏈路中任意相機產生的視頻的碼率。

2 基于聯合KKT條件和分支定界法的速率自適應選擇算法

顯然，問題P1是一個非線性整數規劃（NIP）問題。通過分析該問題的性質，若將問題P1的求解變量松弛為連續變量后，其目標函數和約束條件均為便于求解的凸函數。因此，先將問題P1進行連續松弛，將非線性整數規劃問題變成非線性規劃問題，用KKT條件［15］求出該非線性規劃問題的解；再采用分支定界法求解出原問題P1的0-1變量解。

2.1 松弛后非線性規劃問題的KKT條件

該問題的拉格朗日函數為

式中：

因此，可以得到相關的KKT條件為

通過聯合KKT條件相關的公式（式（16）～式（21））進行求解，可以得出經過松弛的非線性問題的最優解，記為χrelax，接下來使用分支定界法求出原始問題的0-1變量解。

2.2 基于分支定界的上下行鏈路VR視頻速率自適應選擇算法

起始輸入為χrelax和Zrelax，Zrelax表示χrelax對應的最優目標函數值。輸出結果為所求的0-1變量解χ0-1和相應的最優目標函數值Z0-1。

算法1 上下行鏈路VR視頻速率自適應選擇算法。

輸入：用KKT條件求解出的對應松弛問題的解χrelax和松弛問題的最優目標函數值Zrelax。

輸出：問題P1的符合0-1約束條件的最優解χ0-1和問題P1的最優0-1解對應的最優目標函數值Z0-1。

初始化：k=0，L=0，U=Zrelax。

1.從χrelax中任意選則一個不符合0-1約束條件的解χj，在（0，1）范圍內隨機產生一個隨機數ε。

2.IF 0≤χj＜ε，THEN將約束條件χj=0加入到問題P1中，形成子問題Ⅰ。

3.ELSE，將約束條件χj=1加入到問題P1中，形成子問題Ⅱ。

4.END IF

5.繼續求出子問題Ⅰ和子問題Ⅱ的松弛問題解，記為χk，并將對應最優目標函數值記為Zk。

6.U=max｛Zk｝，χk∈［0，1］。

7.L=max｛Zk｝，χk∈｛0，1｝。

8.IF Zk＜L，THEN剪掉這個分支。

9.ELSE IF Zk＞L，THEN回到分支步驟并重復。

10.ELSE Zk=L，THEN問題P1的最優解已經找到，Z0-1=Zk，χ0-1=χk。

11.END IF

3 仿真實驗與結果

3.1 仿真實驗

為了驗證本文算法的有效性，選擇了6個用Insta 360 Pro2全景相機所拍攝的視頻作為上行鏈路的原始視頻，每個視頻的分辨率都為960×720，長度為35 s，幀率為30 fps（fps為幀/s）。圖3為所采用的6個原始視頻的縮略圖。采用HEVC（High Efficiency Video Coding）編碼器對每個原始視頻進行壓縮，分別以17，20，23，26這4種量化參數（Quantization Parameter，QP）壓縮，為每個視頻設置4種碼率等級：｛1.5，2，2.5，3｝Mbit/s。使用VR視頻合成軟件AVP（Kolor Autopano Video Pro）完成全景視頻的合成工作。把VR視頻分成4×4=16塊，每塊覆蓋視角為90°×45°。為每塊下行視頻設置6種不同碼率等級以供選擇：｛0.2，0.4，0.6，0.8，1，1.2｝Mbit/s。圖4為使用6個原始視頻所合成的VR視頻縮略圖。實驗中，用戶端使用VR頭戴式顯示設備HTC Vive，使用戶進行觀看以此來獲得不同用戶的FoV。具體選擇了100個用戶和48個的VR視頻［16］，用戶觀看不同的VR視頻，通過所獲得的100個用戶FoV數據，經過計算分析得出有60%的用戶FoV大約為120°×90°，這說明大多數用戶在觀看實驗所用全景視頻時，視角都會在這個范圍內。因此，將FoV設置為120°×90°。在下行傳輸過程中，為每塊視頻提供4種MCS方案。具體見表1。在仿真實驗中，使用所設計的算法平均求解一次最優解需要1 min。

圖3 6個原始視頻的縮略圖Fig.3 Thumbnail of six original videos

圖4 采用分塊后的全景視頻Fig.4 Tiled panoramic video

表1 MCS方案Table 1 MCS scheme

3.2 仿真結果

為了證明本文算法的性能，采用3種算法來對比。第1種算法是在上行部分中采用平均分配資源，即把上行鏈路中的網絡帶寬資源平均分配到不同的相機中。第2種算法是下行速率自適應算法，該算法與傳統的VR視頻傳輸算法相同，都是基于DASH的自適應分塊傳輸算法，只考慮從服務器到用戶的下行部分自適應傳輸。第3種是下行視角自適應算法，該算法通過結合用戶視角預測和網絡帶寬預測，來實時地進行從服務器到用戶的下行部分自適應傳輸。

分析不同上行鏈路帶寬條件下所有用戶的QoE值，性能如圖5所示。能夠清楚地發現，當上行鏈路帶寬相同時，本文算法能夠達到更高的QoE值，說明在上行部分有著更好的性能。此外，下行速率自適應算法在不同上行帶寬條件下，在4種算法之中性能較差。

對比下行鏈路中不同資源塊數量對系統整體QoE的影響，如圖6所示。可以發現，在4種算法中，本文算法在不同下行鏈路資源塊數量條件下仍有較高的QoE值，性能要遠高于下行速率自適應算法和上行平均分配資源算法，略高于下行視角自適應算法。同時可以發現，下行視角自適應算法的性能要優于下行速率自適應算法，這也體現出了視角預測與網絡帶寬預測在VR視頻自適應傳輸中的重要性。下行視角自適應算法的性能仍要略低于本文算法，這也說明了上下行傳輸一體化的優良性。

表2給出了4種算法在相同上下行鏈路帶寬、用戶數目時的系統QoE值和比較情況。可以發現，本文算法的QoE值比上行平均分配資源算法提高了14.27%，比下行視角自適應算法提高了11.58%，比下行速率自適應算法提高了23.47%。

圖5 上行鏈路與系統QoE值的關系Fig.5 Relationship between uplink and system QoE value

圖6 下行鏈路與系統QoE值的關系Fig.6 Relationship between downlink and system QoE value

表2 不同算法QoE值比較Table 2 QoE value comparison among different algorithms

圖7 用戶數目與系統QoE值的關系Fig.7 Relationship between user number and system QoE value

圖7為用戶數目與系統QoE值的關系。可以發現，系統QoE值隨總用戶數的增加而一直增加，但是增加的速度會逐漸下降，甚至會降低。這是因為當用戶數目增加到一定程度時，系統為了確保每個用戶都能正常地觀看視頻，犧牲了每個用戶所得到的碼率等級，即下降了每塊視頻的碼率等級。

4 結 論

本文提出了一種基于QoE的多用戶自適應傳輸系統，通過對仿真結果的分析可以得出如下結論：

1）提出的VR視頻傳輸系統與傳統的360°全景視頻傳輸系統相比，不僅考慮了下行傳輸也考慮了上行傳輸部分。

2）提出的基于聯合KKT條件和分支定界法的速率自適應選擇算法可以解決所提出的傳輸系統中的資源分配問題。

3）提出的速率自適應選擇算法與上行鏈路平均分配資源算法相比系統QoE 值提高了14.27%，與傳統的VR視頻速率自適應算法相比系統QoE值提高了23.47%。