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%。