曲凯明++张小奕

摘要：针对传统的HTTP动态自适应流媒体（DASH）的邻近用户网络带宽竞争问题，提出一种设备对设备（D2D）协作式DASH系统，该系统采用了D2D协作的方式充分利用邻近用户的网络带宽能力下载和分享视频，客户端以中间件架构实现，使得该系统与主流播放器兼容。针对过度追求高视频质量而忽视智能手机能耗的问题，提出了一种能耗优化码率选择算法应用于D2D协作式DASH系统。根据智能手机当前的能耗、CPU使用率、内存占用率与系统停留时间选出领队设备，领队设备负责视频的下载与D2D自组网的分享。实验测试结果表明：该算法与非合作算法相比在保证相同视频质量的情况下可以最多节省25%的能耗。

关键词：流媒体；能耗；设备对设备；码率选择；移动云计算

中图分类号：TN919.8

文献标识码：A

DOI：10.3969/j.issn.1003-6970.2015.09.002

0 引言

随着智能手机的普及与无线通信技术的成熟，人们可以随时随地用手机、平板或其他移动设备观看视频内容。HTTP动态自适应流媒体（Dynamic Adaptive Streaming over HTTP，DASH）已经成为目前最流行的视频流媒体播放标准。DASH将这个视频文件分割成一系列的可以基于HTTP传输的小切片，切片的大小是固定的，一般在2-10s之间。分割后每个切片都有覆盖各种不同码率的版本，即服务器上具有多码率编码的源内容。当DASH客户端播放网络视频时将基于自身的网络状况例如吞吐量和时延等条件选择下一段切片的码率。

根据最新的统计，将近五分之一的YouTube用户每天在用智能手机观看视频，其中有近一半的人会与他们的朋友一起观看视频。当一组邻近的用户通过移动客户端观看同一段网络视频时，这一组用户的客户端会分别向服务器请求视频资源，这些客户端获得的视频码率总会受到网络限制。而如果这些用户是通过同样的方式接入网络，他们获取的视频质量就会更加糟糕，因为相互竞争的关系，这些客户端都无法达到网络本身的最大能力。

本文提出了一种设备对设备（Device-to-Device，D2D）协作式DASH系统，充分考虑到用户使用的智能手机设备通常具有多个网络接入方式，当设备通过3G/4G连接网络时，就可以考虑利用Wi-Fi连接，即引入D2D的连接使一组客户端相互合作下载和分享视频资源。客户端以中间件架构实现，在中间件内部处理调度视频的下载、分享与切片的拼接，对外暴露传统的DASH接口，即D2D协作式DASH系统对播放器来说是透明的，主流支持DASH协议的播放器都可以兼容D2D协作式DASH。从而用户可以享受更好的视频质量的同时不用去关心播放器的兼容性问题。

本文还提出了一种能耗优化码率选择算法应用在D2D协作式DASH系统。综合考虑智能手机当前的能耗，CPU使用率，内存占用率与系统停留时间选出领队设备，领队设备负责向云服务器发起视频下载请求并基于领队设备提出了一种自适应码率选择算法，下载好的视频通过D2D自组网分享。实验结果表明能耗优化码率选择算法可以降低约25%的能耗同时保证了视频质量。

1 相关工作

对于新兴的协作式流媒体系统有很多相关研究，可分为两类：采用DASH的协作式流媒体系统和不采用DASH的协作式流媒体系统。在不采用DASH的协作式流媒体系统中，Keller等提出了一种采用网络编码的渐进式合作下载系统，但无法适应网络的变化并造成了资源的浪费。一组用户使用不采用DASH的系统从云服务器发起视频下载请求，而这种一组用户全部参与下载的机制会导致较高的能耗。Zhang等提出让一组用户的客户端全部向云服务器发起下载请求，而只有一个用户的客户端可以播放视频。Yaccoub等提出了一种合作机制，该机制将云服务器的所有视频内容推送到组内某个用户的客户端，并通过该客户端将所有视频内容广播分享至所有组员，显然该机制不能充分利用合作的优势来获得更好的视频质量。

我们之前的工作提出了一种DASH系统部署在Android平台上，一组用户通过D2D白组网进行视频分享。然而该系统仅考虑了网络的可用带宽却并没有考虑智能手机的能耗问题，并且该系统与传统DASH不兼容所以主流播放器无法直接使用该系统。

2 D2D协作式DASH系统

2.1 系统结构

该系统包括一个云服务器和一组客户端设备，系统结构如图1所示。云服务器为客户端设备提供流媒体资源，包括响应客户端设备的请求并对请求的视频资源做动态处理。客户端设备通过3G/4G网络连接到云服务器，一组设备互相之间通过Wi-Fi连接作为D2D的接口，使邻近的客户端互相连接起来。在一组客户端设备中采取分层架构，需要预先制定若干个领队设备，作用是承担发起下载请求的任务，而在下载完成后领队设备需要承担D2D分享的任务。由于蜂窝移动网络模块是智能手机中能耗最高的模块之一，大量触发蜂窝移动网络模块的开启与关闭状态会导致能耗的显著增加。本文所提出的D2D协作式DASH系统会在数据传输活跃阶段避免了蜂窝移动网络模块的频繁开启与关闭，从而能耗显著降低。

2.2 服务器模块设计

服务器由资源管理模块、转码模块和HTTP服务器模块等部分组成。基于小组的资源管理模块负责控制系统的云服务器，首先当服务器收到客户端领队设备代表一个小组发起的视频切片列表的请求时，资源管理模块接受请求，记录小组规模Ⅳ并生成一个随机的认证标识返回给这一组客户端，在之后的通信中用来识别一个小组。另外资源管理模块的重要功能是防止D2D自组网的无线信道碰撞，当一个领队设备完成了视频碎片的下载并且尚未通过D2D自组网进行广播分享，领队设备需要向云服务器的资源管理模块发起D2D无线信道占用请求以防止在D2D无线信道下的数据碰撞。当视频碎片被分享之后，领队设备需要向云服务器的资源管理模块发起D2D无线信道解除占用请求。转码模块是系统中应用移动云计算思想的结构，云服务器上存储了原始的视频资源，与传统DASH系统不同的是，所提供的视频资源是根据领队设备客户端所请求的视频码率动态实时转码得到的，利用转码模块实现了扩展客户端上的网络能力。HTTP服务器模块负责处理客户端发起的HTTP请求，不过当一个设备请求某个视频切片时，并不是直接返回用户请求的完整文件，而是将视频切片分割成碎片并通过HTTP协议的206响应指明当前碎片的偏移量。之后的工作就交给客户端，由小组内的领队设备通过D2D连接完成碎片的拼接和视频分享。

2.3 客户端设备模块设计

客户端设备由客户端资源管理模块、下载模块、广播模块和代理服务器模块组成。客户端资源管理模块负责在客户端一侧系统的整体控制，主要任务包括协调下载模块和广播模块，缓存视频切片，文件读写，响应代理服务器的请求等。当代理服务器模块向资源管理模块请求某一视频切片时，客户端资源管理模块会将下载模块和广播模块通过网络或D2D白组网获取的视频碎片组装，获得完整的视频切片文件后将文件交给代理服务器模块。

2.3.1 代理服务器中间件架构

系统的客户端一侧采用中间件的架构设计。客户端设备的资源管理模块、下载模块和广播模块对于客户端的播放器来说是透明的。播放器通过代理服务器提供的传统DASH接口与系统进行交互。对于任何支持传统DASH协议播放器，在播放开始阶段会先向代理服务器发起HTTP GET请求，请求下载视频资源的切片文件列表，这里的切片文件列表相当于DASH协议中的MPD文件。代理服务器此时暂时阻塞切片文件列表请求，同时将该请求转发给客户端资源管理模块。当资源管理模块通过调度下载模块和广播模块从服务器获取到切片文件列表后，需要将切片文件列表的云服务器视频资源一一映射到客户端本地的虚拟文件，代理服务器重新生成一个包含本地虚拟文件的切片文件列表交付给DASH协议播放器，同时解除阻塞状态。当DASH协议播放器根据切片文件列表向代理服务器请求客户端本地的虚拟文件时，如果该虚拟文件所映射的真正视频切片文件已经通过资源管理模块、下载模块和广播模块的协作之下获取到，那么就将真正的视频切片文件交付给DASH协议播放器。如果该虚拟文件所映射的真正视频切片文件尚未获取到，那么代理服务器就暂时阻塞该请求，直到真正的视频切片文件获取到了为止。这种中间件架构的设计避免了对传统DASH播放器的改动，使得本文所提出的系统可以兼容传统的DASH播放器。

2.3.2 自适应码率选择算法

下载模块负责向云服务器的HTTP服务器模块发起请求。组内的领队设备负责下载合适码率的视频切片。为了让用户获得更好的视频质量，客户端需要应对多变的网络状况以获取合适的视频码率。如果客户端所请求的视频码率超过了当前的网络带宽会导致播放缓存不足，就会出现播放停顿。如果客户端所请求的视频码率过于保守则会导致较差的视频质量。所以关键问题是如何根据多变的网络带宽选择合适的视频码率。本文提出了一种自适应码率选择算法来应对多变的网络带宽。该算法会以组内所有领队设备的平均缓存大小作为考虑因素。该算法会持续监测所有领队设备的播放缓存状态，通过组内所有领队设备当前平均缓存大小与设定的两个阈值的比较，可以确定下一个视频切片的合适码率。每当一个视频切片下载完成，就会执行该算法来计算下一个切片的码率。为了保证不卡顿的情况，也就是要保证缓存始终处于安全的阈值之上，定义一个缓存大小的下限，称为低阈值P₀另一方面，要保证为用户提供较高的视频质量，那么当缓存大小足够大的时候需要考虑提高视频质量，定义一个缓存大小的正常阈值C₀当缓存小于低阈值P，意味着马上就将因为缓存不足而导致播放停止，该算法会尽可能地选择最低码率的视频切片来保证视频流畅性。当缓存大于低阈值P小于正常阈值C，该算法将采取平稳的码率选择策略，因此会选择与前一个视频切片一样的码率等级g。如果缓冲区大于正常阈值C，即缓存足够大的时候，该算法会根据缓存大小的变化趋势来选择合适的视频码率。如果缓存呈增长趋势，那么该算法会选择q或q+l码率等级的视频切片，反之则会选择q或q-1码率等级的视频切片。每次码率调整只会变动一个等级，避免码率变化跨度过大，引起用户反感。白适应码率选择算法的具体实现算法如下：

算法1 自适应码率选择算法

1）buffer←Calculate the current buffer which is the average of all captain devices'huffer

2）q←O（the quality to download）

3）while new video segment do

4）if buffer>common threshold C then

5）q←q+l

6）if buffer

7）q←O （the poorest video quality）

8）else if huffer is decreasing rapidly then

9）q←q-1

10）Download the segment with quality q

11）end while

算法中的第1）行是算法开始计算所有领队设备的平均缓存；第2）行对码率等级进行初始化；第3）-11）行开始进行视频切片的下载与视频码率的选择；第4）-5）行判断如果缓冲区大于正常阈值C则会选择q+l等级的视频切片；第6）-7）行判断如果缓存小于低阈值尸则选择最低等级的视频切片；第8）-9）行判断如果缓存区大小下降过快则会选择q-1等级的视频切片；第10）行表示如果缓存大于低阈值P小于正常阈值C时会选择与前一个视频切片一样的码率等级q。

2.3.3 D2D自组网的视频分享

广播模块负责系统在客户端设备一侧的核心功能，实现设备对设备的连接。当组内的各个领队设备下载完视频碎片之后，通过D2D自组网将视频碎片广播给其他领队设备和所有的组员设备。虽然组内的各个领队设备只负责下载很小一部分的视频碎片，但是广播模块使得每个设备都能获得领队设备下载的内容，这样就实现了对单个设备网络能力的扩展。当领队设备向云服务器请求视频切片时，云服务器的转码模块将视频切片分割成j个碎片并被领队设备所下载。针对组内的每个超级节点分别建立队列长度为L的任务队列。如果该领队设备的任务队列所积压的任务没有超过队列长度并且该视频切片尚未被下载完全，则一个新的碎片任务会被分配至该领队设备。当遇到下载碎片失败的情况，失败的碎片bi将会被重新放入云服务器的任务池。

3 能耗优化码率选择算法

考虑到一组用户的参与向云端下载视频切片的领队设备数目是在不断变化的，从而组内的可用带宽也是在不断波动的，导致了组内用户观看的视频质量和能耗也是在不断变化。如果一组用户观看的视频切片的视频质量较高，这时对视频切片的视频质量的些许提升就会导致严重的能耗损失，综合视频质量的提升与损失的能耗来看这样做是不必要的。因此D2D协作式DASH系统将从一组用户中选出m个领队设备负责向云服务器下载视频切片，在保证可接受的视频质量前提下尽可能降低能耗。当选择领队设备时，一组用户内每个用户设备的电量、CPU利用率、内存占用和用户在组内停留的时间都将被考虑在内。当m个领队设备选择完毕，m个领队设备将代表该组内的所有用户向云服务器发起视频切片下载的请求，根据领队设备平均缓冲和网络带宽来选择下载合适码率的视频切片。

3.1 领队设备

选择更多的领队设备参与视频切片下载和分享会获取更高的视频质量，同时也导致了更大的能耗损失。然而视频质量的提升与能耗损失并不成正比。本文通过计算分析峰值信噪比（Peak Sig-nal-to-Noise Ratio.PSNR）和能耗的关系来决定一组用户需要多少领队设备参与视频切片的下载和分享。考虑这样一个场景，一组用户观看一个码率为br的视频，每个视频切片时长ts，则每个视频切片的数据量为。

峰值信噪比由于它与主观视频质量的高相关性被广泛用于评估视频质量，峰值信噪比取值越大表示信号越清晰而噪声越小，亦即拥有更高的视频质量。选取某一段视频切片为例，将其转码到不同的码率等级，从200kbps到3000kbps，以lOOkbps的粒度分为29个等级，然后分别与转码前的原始资源对比计算峰值信噪比，如图2可以看出，当视频码率大于lOOOkbps后峰值信噪比提升不明显。

由于蜂窝移动网络模块即无线网卡是智能手机中能耗最高的模块之一，本文采用一种线性能耗模型来计算该模块的能耗，通过无线网卡（NIC）发送数据的能耗与接收数据的能耗可认为大体相等。所以无线网卡的能耗可以由网卡工作状态的能耗和发送接收数据的能耗组成，如式（l）所示：

图3表示客户端从云服务器下载不同码率视频的能耗与lOOOkbps码率视频的能耗之比。从图3可以看出能耗与码率呈线性关系。由于峰值信噪比与能耗均与码率相关，并且当码率较高时能耗的增长显著高于视频质量的提升，所以需要综合考虑能耗与视频质量的关系来选择合适的码率。

4 实验结果与性能分析

4.1 实验环境

本文采用8核Intel Xeon E51620 CPU和16GBRAM配置的主机作为云服务器，7个Android平台的智能手机组成一组。预先选好一段实验视频，将其转码到不同的码率等级，从200kbps到3000kbps，以1OOkbps的粒度分为29个等级，然后转码成不同目标码率的视频切片。每个视频切片包含2s的视频内容。原始视频的码率为5000kbps。

4.2影响因子c

根据式（10），影响因子c、峰值信噪比和能耗共同影响视频码率的选择。当c趋近于1时，视频质量对码率的影响会越来越重要。同理当c趋近于0时，能耗对码率的影响会加重。图4显示了c对码率选择的影响，其中N=7，t=2，w=4。

当c的取值由0到l变化时，br的最优解将会趋近更高的视频码率。如图5显示了归一化后的峰值信噪比与能耗分别在P=0.25，0.35，0.5，0.65，0.75的极值点。当c取值0.5时，可以获得较高的视频质量的同时降低能耗。

4.3 协作式与非协作式流媒体系统对比

本文在进一步研究对比协作式与非协作式流媒体系统时，参考了微软的平滑式流媒体技术（Microsoft Smooth Streaming，MSS）。MSS是微软的流媒体技术方案可作为传统DASH系统。考虑一组用户规模为7。能耗优化码率选择算法的影响因子c设为0.5。由图6可以得出，在网络带宽波动剧烈的环境下，与MSS系统相比较，本文提出的D2D协作式DASH系统对可用带宽的利用率有着显著的提升。同样的如图7所示，与MSS系统相比，本文提出的D2D协作式DASH系统可以获取更高的视频质量。由t=2可知每个视频切片时长2秒，本文对组内的所有组员进行间隔2秒的采样来获取当前的能耗状况。同样的，采用MSS系统的对照组采取同样的采样间隔对能耗状况进行检测。表1表示了各系统的能耗与观看lOOOkbps码率视频所消耗的能耗相对值。由表1可以得出，D2D协作式DASH所采用的能耗优化码率选择算法与MSS系统相比较，可以减少约25%的平均能耗损失。

5 结论

考虑到DASH系统导致的邻近用户网络带宽竞争问题，本文提出一种D2D协作式DASH系统，领队设备通过移动网络下载视频并通过Wi-Fi广播分享视频从而充分利用了组内用户的网络带宽。客户端以中间件架构在Android平台上实现，使得主流支持DASH协议的播放器都可以兼容D2D协作式DASH。从而用户可以享受更好的视频质量的同时不用去关心播放器的兼容性问题。为了保证高视频质量的同时兼顾能耗问题，本文提出了一种能耗优化码率选择算法应用在D2D协作式DASH系统，该算法综合考虑智能手机当前的能耗，CPU使用率，内存占用率与系统停留时间动态选择领队设备，由领队设备承担额外的链路能耗，使得D2D协作式DASH系统可以在降低约25%的平均能耗同时保证了较高的视频质量。