基于主动推送的视频流优化传输算法

汪 静，丁晓梅，赵丽红

(安徽文达信息工程学院 计算机工程学院，安徽 合肥 231201)

1 引言

近年来，随着计算机网络和移动终端设备的不断发展，音视频等多媒体业务在网络流量中占据的比重也在逐年增长。据思科的调查报告显示[1]，2019年全世界的流媒体流量占据了互联网总数据流量的百分之七十五，并在未来将保持持续增长的趋势。流媒体技术的出现，解决了移动通信技术汇总的带宽限制问题，大大缩短了多媒体业务的启动时间，也极大地降低了多媒体业务对客户端硬件的要求[2]。

与此同时，一些基于HTTP协议的流媒体传输协议也得到了迅猛的发展。许多互联网巨头公司为了抢占市场先机，也都推出了自己的流媒体传输协议，如苹果公司提出的HLS(HTTP Live Streaming)协议，微软公司提出的MSS(Microsoft Smooth Streaming)协议，Adobe公司提出的HDS(HTTP Dynamic Streaming)协议等均取得了强烈的反响，但是这些协议只适用于本厂研发的设备和应用软件，并不具备跨平台的通用性，极大地影响了流媒体业务的推广和普及。为此，自2009年起就致力于基于HTTP的流媒体传输协议标准研究的国际标准化组织运动图像专家组(MPEG)，最终与3GPP联合提出了MPEG-DASH(MPEG Dynamic Adaptive Streaming over HTTP)协议，该协议于2011年底正式被批准为ISO标准，即ISO/IEC 23009-1[3]。

2 相关技术简介

2.1 HLS协议

HLS协议是苹果公司推出的一种基于HTTP协议的流媒体传输协议[4]，它可以广泛应用于视频点播、直播、广播等场景，但该协议只适用于苹果公司的IOS系统及相应的设备。HLS协议采用了比较成熟的H.264/AVC编码技术和TS封装的视频流传输格式。HLS的系统架构包括服务端、客户端和内容分发组件三部分。其中服务端主要负责生成内容源，包括视频流的编码和视频流的切片。HLS中的客户端主要负责向web服务器请求m3u8索引文件和视频流数据。内容分发组件由若干提供HTTP服务的web服务器组成，主要负责接收客户端发送的HTTP请求，并对这些请求的视频切片内容进行响应。

2.2 MSS协议

MSS协议是微软公司提供的一种基于HTTP协议的流媒体传输协议[5]，该协议是基于微软的Web服务IIS(Internet Information Service)和终端的Silverlight技术实现的。MSS协议与HLS协议不同，其媒体存储和传输格式均为MP4格式，同时在服务端，MSS协议只是将媒体文件进行虚拟切片，即在服务端存储的还是不同码率的完整流媒体文件，当客户端向服务器请求相应的视频切片时，再将其切割成小的视频切片进行传输。在MSS系统中，Smooth Streaming可以通过web的方式提供高清直播，而Silverlight终端可以根据客户端的若干特性去选择合适的码率，以保证视频播放的流畅性。MSS协议的整体架构中，服务端必须采用微软的IIS服务器，而非通用的HTTP服务器，这给MSS的推广和部署带来了诸多不便。

2.3 HDS协议

HDS协议是Adobe公司提出的一种基于HTTP的动态码率自适应的流媒体传输协议[6]。HDS协议的系统架构包括内容准备、内容分发、客户端等三个组件。内容准备组件主要负责视频流的打包，对于点播业务而言，内容准备组件将FLV格式的视频流切片，并打包成F4F格式的视频片段，同时产生包含视频流切片信息的索引文件。对于直播业务而言，内容准备组件借助Adobe的Flash Media Server媒体服务器，将媒体服务器上的RTMP(Real Time Message Protocol)视频流进行切片并打包成F4F格式的视频片段，同时生成F4M格式的索引文件。内容分发组件主要负责将内容准备组件生成的F4F格式的视频片段和F4M格式的视频流索引文件部署到相应的Web服务器上，用于后续的网络传输。客户端组件通过Adobe的Flash播放器或OSMF播放器，将下载好的F4M文件进行解析，根据当前网络状态和客户端状态，选择相应码率的视频切片，并将下载好的视频切片进行解码和播放。

2.4 DASH协议

DASH协议是基于HTTP的动态自适应流媒体传输协议[3]，其灵活的结合了HTTP协议渐进式下载的优势，顺应了时代发展的需求。如图1所示，在DASH系统的服务器端，视频流被提前编码为多种码率的视频流，同时，这些不同码率的视频流被切成固定长度的视频片段，这些不同码率、不同片段的视频片段被存放在HTTP视频服务器上。在DASH系统的客户端，ABR算法(码率自适应算法)根据网络状况以及播放器本地缓冲区的特性，请求相应码率的视频切片，从而尽可能地提高网络带宽的利用率，并保证视频播放的流畅性。最后这些请求以HTTP Request的方式向服务器请求视频切片，服务器收到这些请求后以HTTP Response的方式向客户端响应相应的视频切片。在客户端和服务器建立会话连接后，客户端会首先向服务器请求MPD清单文件，然后将解析MPD清单文件，并根据清单文件的信息和本地网络、缓冲区等信息，向服务器请求视频切片。MPD清单文件包含一个或多个连续的视频片段信息，一个单独的视频片段信息包括码率、帧率、分辨率等信息。

图1 DASH系统核心架构图

如图2所示，视频流内容被存储在HTTP服务器上，视频流在HTTP服务器和DASH客户端之间通过HTTP1.1协议进行传输。其中HTTP服务器上的文件内容包括两个部分，一部分是MPD清单文件，用于描述视频片段的码率、持续时长、URL地址等信息；另一部分是视频切片，该部分包含了实际的视频片段数据。一个视频文件代表一种码率，每个文件包含若干视频片段，代表同一种码率下对应若干固定时长的视频片段。

图2 DASH应用场景

在播放过程中，DASH客户端首先通过HTTP获取MPD清单文件，通过对MPD文件的解析，可以获取存储在服务器上的视频编码格式、编码码率、切片时长等基本信息，结合对当前网络带宽的预测，或对未来播放器中缓冲区占用率的预测选择合适的码率，并通过HTTP的GET请求获取该码率视频切片。经过一段时间的缓冲，即客户端缓冲区中有一定数据量后，客户端可以应对网络带宽的一般性波动，客户端可以一边检测网络带宽的波动情况，一边从服务器下载后续的视频切片。客户端根据网络带宽的预测、本地缓冲区的占用率等信息，动态地选择合适的码率，以维持足够的客户端缓存来保证视频播放的流畅性，同时尽可能地提高视频的整体码率，降低视频块之间的切换频率[7]。

3 算法设计

3.1 服务器主动推送

在DASH系统中，不管是点播还是直播场景下，视频流文件或者摄像机采集到的视频流都被按照规定的格式分割为MPD索引文件[8]，init.mp4初始分片和一系列m4s格式的连续视频切片，这些视频数据都被存放在HTTP服务器上[9]。我们通过本地客户端播放视频时，会先输入MPD清单文件的URL地址，让播放器首先请求得到MPD清单文件，随后解析MPD清单文件，并根据ABR算法(动态码率自适应算法)请求响应码率的初始分片和后续分片。客户端在接收到服务端的响应数据后，将视频分片按照索引顺序组织，并在播放模块解码播放。整个过程是一个完整的发出请求并收到响应的标准HTTP请求响应过程。这种模式会在视频启动的时候获取索引文件并解析，然后向服务器发送对相应视频切片的请求，这将会导致较大的延时。同时较大的视频切片在传输过程中会消耗较长的时间，严重影响视频的播放流畅性，较小的视频切片则会导致单位时间内，客户端对服务器请求访问的次数增加，进而导致较长的请求RTT，这也会严重影响网络的传输效率。之前的HTTP协议，如HTTP 1.0，HTTP1.1等，在客户端和服务器之间采用拉(pull)的模式，即客户端主动向服务器拉取视频切片。而HTTP2.0作为新一代的HTTP协议标准，其主动推送的特性允许服务器在收到某个视频切片的请求后，无须等待后续若干视频切片的客户端请求而主动推送到客户端。这种服务器主动推送的模式，可以大大缩减客户端和服务器之间通过HTTP交互的延时，可以在有限网络资源的情况下，提高视频播放的流畅性[10]。

3.2 基于缓冲区的动态码率推送算法

在DASH系统中，本地播放器的缓冲区满溢程度可以间接反映网络状况的实时波动情况，当网络状况较差时，本地播放器的缓冲区中数据量较小，当网络状况较好时，本地播放器的缓冲区中数据量较大。在DASH的一个推送周期内，播放器会收到若干视频切片。在这个周期内，获取网络带宽的实时波动情况非常复杂，但是本地缓冲区的满溢程度可以轻松获取，因此我们可以考虑通过本地播放器的缓冲区满溢程度动态调整主动推送的过程。如图3所示，我们将播放器的缓冲区划分为如下阶段：BufMin阶段，BufLow阶段，BufHigh阶段，BufMax阶段。服务器根据本地缓冲区中的数据量处于不同的阶段，进而执行不同的主动推送策略。播放器的缓冲区类似于一个队列，下载好的视频切片从左边进入缓冲区队列，而待播放的视频切片从右边解码并出队列[11-12]。

图3 本地客户端缓冲区模型

当客户端向服务器请求第i个视频切片时，服务器在响应第i个视频切片的同时会主动推送k-1个视频切片，即客户端发送一个请求，总共收到k个视频切片。整个推送的逻辑功能位于服务器端，当推送的视频切片数量k较小时，客户端和服务器交互的次数没有明显的减少。当推送的视频切片数量k较大时，单个推送周期会持续较长的时间，在这期间，网络状况和本地播放器的缓冲区可能发生较大的变化，因此，需要根据上述指标，动态调整主动推送的视频切片质量，避免播放器缓冲区中的数据量耗尽，造成播放中断。

pushBR(ci)=

(1)

主动推送过程中，动态调整视频切片质量的逻辑如公式(1)所示，pushBR(ci)代表主动推送的第i个视频切片的码率，其中第一个被主动推送的视频切片码率为客户端请求的视频切片码率，后续视频切片的码率均由上述逻辑判断，buf代表播放器缓冲区中当前的缓冲满溢度，以时间为计量单位。

若当前的缓冲满溢度低于BufMin，说明当前播放器缓冲区的数据量过小，处于数据量耗尽的危险区，有较高的rebuffer风险，为了避免视频播放过程中的卡顿现象，服务器将主动推送的视频切片码率调整为当前索引位置视频切片的最小码率minBR，以便尽快填充播放器缓冲区的数据量。

若当前的缓冲满溢度位于BufMin和BufLow之间时，说明当前播放器缓冲区的数据量较小，服务器将主动推送的视频切片码率调整为上一个视频切片码率的一半。

若当前的缓冲满溢度位于BufLow和BufHigh之间时，说明当前播放器缓冲区的数据量正常，服务器将主动推送的视频切片码率调整为与上一个视频切片码率一致，这样的调整可以降低视频切片之间的码率切换值，进而提升用户的观影体验。

若当前的缓冲满溢度大于BufHigh时，说明当前播放器缓冲区的数据量较大，视频rebuffer风险较小，可以考虑适当提高待推送视频切片的码率，从而提高视频的整体码率水平及用户的观影体验。

4 实验评估

本实验使用了由JavaScript开发的开源播放器dash.js，其中动态码率自适应算法在ABRRulesCollection.js文件中，实验通过ThroughputRule模块统计过去五个视频切片的下载参数来预估未来一个视频切片在下载时的网络状况，进而选择低于该网络吞吐量的最大码率。实验通过InsufficientBufferRule模块来计算播放器缓冲区的缓冲满溢度，当缓冲满溢度较低时，播放器保守的请求低码率视频切片，以快速填充缓冲区；当缓冲区满溢度较高时，播放器激进的请求高码率视频切片，以提高视频流的整体码率。同时AbandonRequestRule模块可以在视频切片下载过程中不断预估其最终下载完成时间，若预估的下载时间超过播放其对应的播放进度，即代表播放器有卡顿的风险，此时播放器应主动放弃该视频切片的下载，取而代之的是更低码率的视频切片[13]。最后，在接收来自服务器主动推送的视频切片时，实时监测播放器当前缓冲区的满溢程度，利用动态推送调整算法不断修正后续视频切片的码率。

当视频切片的时间较短，代表着当前视频切片包含的数据量较小，即网络中传输的速度更快，可以更加灵活地适应网络的动态变化。但是过小的视频切片会导致视频客户端和服务器之间的请求数激增，这在多客户端场景下尤为明显，严重时会导致服务器宕机。而服务器主动推送可以很好地解决此类问题，在该部分，我们比较了传统的请求响应模型中的请求数目和服务器主动推送(k-push，其中k=4)的请求数目，如图4所示，可以看到服务器主动推送模型的请求数目随时间没有明显的变化，而传统的请求响应模型的请求数目随时间有线性增长的趋势。

图4 请求响应模型和服务器主动推送模型的请求数

在上述实验条件的基础上，我们测试了服务器主动推送算法对不同视频切片时长的性能影响。如图5所示，与传统的请求响应模型相比，服务器主动推送模型的传输延时分别缩短了42.24%、50.63%、46.24%和58.48%，可见服务器主动推送模型可明显缩短传输时延。

图5 服务器主动推送算法对不同切片时长的性能影响

5 结论

人们对观看网络视频质量的要求在日益提升，希望获得高质量、低切换、不卡顿的观影体验。为此，文章分析了当前主流码率自适应算法对用户观影体验的影响，并将HTTP2.0的主动推送功能与DASH技术相结合，提出了一种全新的基于主动推送的视频流优化传输算法。该算法根据播放器中缓冲区占用率的反馈信息，为k个视频块选择合适的码率，并将k个视频块主动推送给客户端。经过本地的模拟实验以及真实环境的实验，可以看出本文提出的基于主动推送的视频流优化传输算法可以明显减少客户端与服务器之间的交互次数，对于那些要求低延时的直播场景，该算法具有明显的提升。