CN102413379A - 流媒体直播系统启动时延方法 - Google Patents

Abstract

流媒体直播系统启动时延算法涉及互联网的流媒体直播领域，关注于解决互联网流媒体直播系统客户端的启动时延问题。随着互联网多媒体技术的发展，互联网流媒体技术的应用越来越广泛，但是由于现在的网络带宽和速度的限制，流媒体技术的优势并不能完全发挥出来。本次发明提出了三种动态启动时延策略，分别是根据播放中断密度动态启动时延策略、根据网络状况动态启动时延策略和混合型动态启动时延策略。通过实验结果观察了在流媒体直播系统中部署这三种启动时延算法的工作效果及性能对比。本次发明通过向流媒体技术中加入动态启动时延策略达到在终端降低播放中断频率，保证平滑播放保护用户的感官体验的目的。

Description

流媒体直播系统启动时延方法

技术领域

本发明主要涉及互联网的流媒体直播系统，主要考虑互联网流媒体直播系统客户端的启动时延问题。

背景技术

本课题得到教育部新世纪优秀人才支持计划资助项目(项目号NCET-09-0709)、国家自然科学基金项目(项目号：60970127)和教育部科学技术研究重点项目(项目号：109029)的支持。

进入21世纪，互联网已经成为人们获取信息的主要媒介之一。由于网络本身架构、关键技术的欠缺，以及对多媒体内容处理技术的不成熟，早期的互联网大多只能传递文字、图片等静态信息，随着个人计算机性能的提升、多媒体技术的发展以及互联网的快速崛起，人们通过互联网提高学习、工作以及娱乐的质量的需求日益增大，因此获取网络上海量音视频等多媒体信息出现了新的模式——流媒体技术。

简单而言，流媒体就是指用户通过网络一边下载并一边观看多媒体节目的一种服务方式。流媒体应用的一个最大的好处是用户不需要花费很长时间将视频文件完整下载到本地后才能播放，而仅需缓存空间数秒后就可以开始播放，后面收到的数据会源源不断输入到该缓存空间，从而维持播放的连续性。

虽然流媒体技术的应用越来越广泛，目前的网络带宽和速度，还无法完全发挥流媒体技术优势，我们知道，流媒体在传输前，要将一个实时音视频源文件编码为许多的数据包，而数据包由于受网络状况影响可能会无法到达目标节点，形成网络层的丢包。目标节点由于缺少连贯的数据包从而播放出现中断。高质量的流媒体应用需要很小的丢包率，以尽可能的减少流媒体的播放中断次数，保护用户的感官体验，然而流媒体作为终端应用技术是无法达到降低网络丢包率的作用的，以至于较差的网络状况和其他因素会导致在终端的播放过程中频繁的发生中断。目前，市场上成熟的流媒体直播系统往往使用传统的启动时延策略，而这往往难以很好满足视频直播系统的内容实时性和时间同步性。传统流媒体启动时延策略是在缓存区中达到固定数量的数据包亦或是缓冲固定时间然后开始播放，这样在网络状况好的时候无法到达用户尽快播放的心理需求，在网络状况差的时候则会造成频繁的中断。

由此可见，启动时延策略的好坏对于流媒体直播系统的播放质量有着很大的影响。本文通过向流媒体技术引入动态启动时延策略以达到在终端降低播放中断频率，尽量保证平滑播放，保护用户的感官体验的效果。

本发明所提出的三种动态启动时延策略就属于以用户体验QoE为中心的容错控制策略。QoE即Quality of Experience是通信领域的概念。它可以理解为用户体验或者用户感知，即终端用户对移动网络提供的业务性能的主观感受。它可以通过接近量化的方法来表示终端用户对业务与网络的体验和感受，并反映当前业务和网络的质量与用户期望间的差距。QoE管理是衡量一个网络和业务品质的最根本的标准在于用户的体验质量，它主要指的是用户对于网络的满意度。它定义为一个应用或业务的总体可接受性，是终端用户的主观感受。

发明内容

本发明不考虑网络中的各种因素，通过根据终端的连接速率、中断情况等因素动态控制启动时延的大小，保证用户体验质量。传统的启动时延策略是当缓存中接收到预设数量的数据包时就开始进行播放，这样做的缺点是无法自适应不断变化的网络状况。

本发明提出的三种启动时延策略如下：

1)根据播放中断密度动态启动时延策略

中断密度定义为pi＝n/T，n表示播放中断的次数，T表示整个媒体流的时间长度。由于直播系统媒体流的播放时间长度理论上是无限大的，即T里面包含了无限个时间长度为N的时段，所以整个媒体流的中断密度等价为一个时段内的中断密度：pw＝n/N。

当在某个长度为N的时间段内，如果没有达到n次播放中断，则保持启动时延的最小值，但不动态增加；如果达到n次播放中断，则动态增加启动时延，动态增加启动时延到最大值；调整过启动时延后，如果在长度为N的时间段内没有再达到n次播放中断，就将启动时延恢复到最小值。上述最小值、最大值均为经验值。其中最小值为流媒体系统单位缓存值(因不同系统有不同的缓存值)的5至10倍；最大值为刘媒体系统单位缓存值的20至30倍；

2)根据网络状况动态启动时延策略

此处网络状况的优劣，是通过比较长度为N的时段内播放终端的数据包接收速率a与播放速率b的大小来衡量的；

如果接收速率a持续大于等于播放速率b，就将启动时延调整为最小值；如果接收速率a持续小于播放速率b，则动态增加启动时延；增加启动时延到最大值；调整过启动时延后，如果在长度为N的时间段内如果接收速率a持续大于等于播放速率b，就将启动时延恢复到最小值。上述最小值、最大值均为经验值。其中最小值为流媒体系统单位缓存值(因不同系统有不同的缓存值)的5至10倍；最大值为刘媒体系统单位缓存值的20至30倍。

3)混合型动态启动时延策略

通过不断统计终端的接收速率，以判断下一时刻启动时延的大小。在长度为N的时段内，如果接收速率持续大于等于播放速率，则维持启动时延的最小值；当接收速率持续小于等于播放速率时，则判断长度为N的时段内的中断次数，如果未达到n次播放中断，则将启动时延固定在最小值；如果达到n次播放中断，则动态增加启动时延至最大值。上述最小值、最大值均为经验值。其中最小值为流媒体系统单位缓存值(因不同系统有不同的缓存值)的5至10倍；最大值为流媒体系统单位缓存值的20至30倍。

一般的，最小值、最大值均为经验值，分别是163840Byte、3932160Byte。

具体原理如下：

1)根据播放中断密度动态启动时延策略

根据播放中断密度动态调整启动时延，以达到在终端减少播放中断次数的目的。流媒体播放需要维持较小中断频率以达到较好的播放效果。中断频率定义为p_i＝n/T，n表示播放中断的次数，T则代表整个媒体流的时间长度，T里面包含了N个时段。由于直播系统所播放的媒体流的时间长度理论上是无限大的，所以中断频率可以等价为一个时段内中断的密度：p_w＝n/N。当在时间段N内如果没有达到n次播放中断，则保持最小的启动时延以达到尽快播放；当发生第一次中断时，启动时延回复到初始值，但不动态增加，如果到达了n次播放中断，则动态增加启动时延，以缓解由于网络问题无法缓冲足够数据包维持下一时刻播放而导致的频繁中断的情况，达到减少播放中断次数的目的；调整过启动时延后，如果较长一段时间内没有再次达到中断频率，说明网络状况已恢复到满足流媒体传输的状态，这时将启动时延恢复到最小预设状态，以达到尽快播放。

2)根据网络状况动态启动时延策略

根据在不同网络状况下到达中断的数据包的个数动态调整启动时延，已达到在中断减少播放中断次数的目的。在这里的根据网络状况并不是主动去探测网络带宽的行为，那样将违背以终端为中心的目的，这里所提到的网络状况是根据在单位时间内统计终端是否接收到足够数据包(接受速率a)满足播放速率b来动态调整启动时延，当网络状况差时接受速率可能会下降，当网络状况好时接受速率基本等于播放速率。当接受速率a近似等于播放速率b时，我们认为网络状况足够好以保证尽快播放，所以将启动时延动态调整为当前接受速率下的最小状态；当一段时间内，接受速率a一直小于播放速率b时，说明网络状况下降(一段时间内避免了网络抖动时计算出接收速率小的情况)，这时将极有可能在下一时刻发生中断，所以将启动时延进行调整以应对将要发生的中断。具体的调整策略实现为：以秒为单位，每一秒都比对接收速率与播放速率的状态加以统计，当接收速率小于播放速率的状况维持一段时间时，则认为这段时间网络状况无法满足传输流媒体，将会在未来较近的时刻发生中断，这时将动态增加启动时延，以缓冲足够的数据包维持下一时刻的播放；当接收速率大于或等于播放速率的状况维持一段时间时，说明网络状况已恢复到足够满足流媒体传输的状态，则动态恢复启动时延为最小状态。在此策略中，启动时延始终根据接收速率主动进行调整，其与中断密度控制策略的主要区别是：中断密度控制策略是被动的根据中断密度来调整启动时延，而该策略则是主动探测数据包的接受速率以自适应网络状况，并不一定在下一时刻会发生中断。

3)混合型动态启动时延策略

根据网络状况动态调整启动时延策略可以主动根据网络状况对下一时刻的缓冲时间进行调整，以应对未来将要发生的播放中断，他可以有效的使节点自适应网络条件，极大减少中断次数。但是这种策略也存在着一些不足，主要表现在当较长时间网络状况持续不佳的情况下，启动时延会累加到一个很大的值，用户必须等待很长一段时间才能进行播放，严重影响用户体验。因此，混合型动态启动时延策略营运而生，它是将以上两种策略在一定程度上相结合的产物。当发生播放中断时，将根据当前统计的接受速率以及这段时间所发生中断的密度加权计算出启动时延的大小并加以实施。具体策略实现为：通过不断统计终端的接受速率，以判断下一时刻启动时延的大小，如果一段时间内接收速率近似等于播放速率，则维持最小的启动时延；当接收速率小于播放速率时，首先判断最近一段时间内的中断密度，如果小于预设值，则将启动时延变更为满足下一时刻播放的数据包个数；如果大于预设的中断密度值，则动态增加启动时延。这样就可以即主动对启动时延进行调整，对于频繁发生中断的情况作出相应，又可以避免无限制增长所造成的过长的启动时延。

附图说明

附图1是实验一中在节点上运行部署根据中断密度调整启动时延的策略的客户端后，根据中断密度控制策略客户端启动时延包个数与中断间隔随时间变化部分曲线。附图1a为根据中断密度控制策略客户端启动时延包个数，附图1b为根据中断密度控制策略客户端中断间隔随时间变化部分曲线。从附图1中可以看到，当中断间隔小于10秒时，启动时延包个数Startup会不断增加，当中断间隔大于10秒时，则启动时延恢复到初始值。因此从统计结果我们可以看到，所编写的代码已经实现了根据中断密度调整启动时延客户端基本的功能。并且，在1030秒的实验时间内，部署了中断密度启动时延的客户端共出现了112次中断，中断密度为0.11，符合设计预期。

附图2是实验一中在节点上运行部署根据网络状况调整启动时延的策略的客户端后，根据网络状况控制策略客户端启动时延包个数与网络状况不佳累积时间随时间变化部分曲线。附图2a是服务器端与客户端之间的网络状况图，附图2b是网络抖动图，附图2c是根据网络状况控制策略客户端启动时延包个数。在图2中，网络抖动为接收速率与播放速率的差值。当网络状况好时，差值基本维持在0附近；当网络状况不佳时，差值会变为负值，启动时延包个数Startup会随着差值不断变化，由于持续的网络状况不佳，所以导致启动时延包个数Startup达到了设置的上限(上限设置为240，以避免缓冲数据溢出缓存覆盖数据)，所以后面即使网络状况依然不好，Startup也不再增加。所以从统计结果我们可以看到，所编写的代码还是已经实现了根据网络状况调整启动时延客户端基本的功能。

附图3是实验一中在节点上运行部署混合启动时延策略的客户端后的实验结果测量曲线。附图3a是服务器端到客户端的网络状况图，附图3b是网络抖动图，附图3c是中断间隔随时间变化部分曲线，附图3d是混合控制策略客户端启动时延包个数。从图3中我们可以看到，当网络状况不佳时，会根据此时刻中断间隔的大小来判断是否增加启动时延包个数Startup，当中断间隔小于10秒时，Startup会不断增加；当中断间隔大于10秒时，则将Startup固定为20个包。由于持续的网络状况不佳，所以无法看到Startup由于网络状况变好而恢复默认值，但是通过中断间隔的判断，即使在网络状况持续不好的情况下也不会一直增加Startup，很好的改善了网络状况调整启动时延客户端始终保持较大启动时延的情况。因此从统计结果我们可以看到，所编写的代码已经实现了混合启动时延策略客户端基本的功能。

附图4是实验二中不同启动时延策略下中断随时间变化曲线。从图中可以看出，三种启动时延策略相比没有使用策略的情况下，都很好的降低了中断的次数，其中，而四条曲线稳定的斜率很好的表现出在相同网络环境下不同策略的变化趋势，根据中断密度调整启动时延策略降低中断次数的程度相对较低，而根据网络状况调整启动时延策略总体中断次数最少，减少中断能力最强，混合启动时延策略则趋于另外两种策略之间，这些都符合我们设计的预期情况。

附图5是实验二不同启动时延策略下启动时延随时间的变化。总体上，启动时延的大小大致呈现为：根据网络状况调整启动时延策略＞混合启动时延策略＞根据中断密度调整启动时延策略＞不使用启动时延策略。由附图6(时间刻度缩小到100秒的局部数据)以及附图7(平均启动时延)可以看出，由于没有部署任何启动时延策略客户端的启动时延始终保持在很低的时间，这样在网络状况好的情况下会表现出很好的实时性，但是当网络状况的持续不佳(如附图8所示，0.5-2Mb切不断抖动的带宽状况已经无法满足4条编码率为288kbps的流媒体以及一条Iperf带宽监测流)，则会带来频繁的中断。而部署了启动时延的三个改进后的客户端则不同程度的动态调整了启动时延，其中根据中断密度调整启动时延策略的客户端由于是被动监测中断情况来调整启动时延，所以时延并未增加太大；由于网络状况的持续不佳，根据网络状况调整启动时延策略的客户端监测到的节点接收速率会持续不满足播放速率，所以会不断的增加启动时延，从而导致启动时延在某些时间段变的巨大；而混合启动时延策略由于融合了另外两种策略，即使在网络状况不佳的情况下，由于考虑到中断密度是否符合调整要求，所以启动时延的增加程度相对适中，大部分维持在另外两种策略的中间。

附图6是实验二中不同启动时延策略下启动时延随时间变化的部分曲线。

附图7是实验二中整段实验时间内各实验用客户端的平均启动时延。

附图8是实验二中服务器到节点的带宽状况随时间的变化。

附图9是实验二中不同启动时延策略下缓存中数据包个数随时间变化部分曲线。由于频繁的中断表示缓存中长时间的出现无数据包可读的情况，会导致长时间缓存利用率过低。附图9为缓存中数据包个数随时间变化的部分曲线，从中我们可以看到，由于没有部署启动时延策略，客户端的缓存中数据包个数始终维持在一个很低的状况，而部署了根据中断密度调整启动时延策略和混合启动时延策略的客户端缓存中数据包个数虽然有所增长，但大部分时间缓存利用率也未过半，而部署了根据网络状况调整启动时延策略的客户端在网络状况不佳的情况下，能够最大限度的利用缓存空间。

附图10是实验二中不同启动时延策略下的平均缓存利用率。通过附图10我们进一步看到，在网络状况持续不佳时，根据网络状况调整启动时延策略的平均缓存利用率最高；根据中断密度和混合启动时延策略的平均缓存利用率则稍差些；而没有部署任何启动时延策略的原始客户端的平均缓存利用率最差。

具体实施方式

下面我们将通过实验来观察在流媒体直播系统中部署这三种启动时延算法的工作效果。

在客户端上部署中断密度启动时延策略时，将中断密度控制阀值定位10秒，也就是说允许11秒钟内最多出现2次中断，中断密度控制为0.18；在客户端上部署网络状况启动时延策略时，由于编码率随画面内容波动，所以我们将判断的播放速率锁定为每秒23个包，网络状况不佳持续时长设为2秒；在客户端上部署混合策略时，根据网络状况方面，播放速率锁定为每秒23个包，网络状况不佳持续时长设为1秒，而中断密度方面各项参数则与单独在客户端上部署中断密度启动时延策略时保持一致；所有实验用客户端默认的初始启动时延设为10个包，启动时延的增长步长也都设为10个包，而其他相关参数则如表1所示。我们将分别部署他们在实验所需的服务器与节点上。

表4.2.1实验用各客户端所应用启动时延策略及缓存大小

利用PlanetLab(参考文献：PlanetLab官方网址http: //www.planet-lab.org/)上的节点进行三个实验，分别评估三种策略各自完成设计预期的情况、节点自身改善播放中断状况以及节点身处整个覆盖网络中改善播放中断状况，统计启动时延随时间的变化状况以及各个节点中缓存利用率的情况。

我们在中国传媒大学网络中心的一个具有公网IP的服务器60.247.40.39上，将一个WMV视频文件用Windows Media Encoder编码成流媒体，由于需要排除其他干扰因素对于结果的影响，所以在源服务器上只选择固定编码率288kbps对媒体文件进行编码，排除了通过动态编码率对网络状况的自适应而减少的中断情况。并在服务器上开启四个相同服务器端程序，利用四个端口7144、7244、7344以及7444分别发送四条同样质量的媒体流，这样可以保证实验中媒体流不会互相干扰，影响实验结果。实验所涉及的所有节点均来着PlanetLab平台，每个节点上分别开启原始的客户端程序监听7144端口、部署了中断密度启动时延策略的客户端监听7244端口、部署了网络状况启动时延策略的客户端监听7344端口以及部署了混合策略的客户端监听7444端口，并让四个实验用客户端手动去寻找它们对应的源服务器或父节点上端口对应的服务器端。通过一系列实验，记录随时间变化的中断次数，启动时延变化情况以及缓存利用率等一系列数据。

在实验一中，主要评估三种启动时延策略各自设计预期的基本功能完成情况。在部署的实验一中，我们选择从PlanetLab上选择斯坦福大学提供的一个节点planet2.scs.stanford.edu，实验分三部分进行，每一部分都在节点上单独开启一个部署了启动时延策略的实验用客户端监听不同的端口；在源服务器上编码一个WMV视频为媒体流后分发给服务器端，通过不同的端口向斯坦福节点对应的客户端进行传输，同时利用Iperf(参考文献：Iperf官方网站http: //dast.nlanr.net/Projects/Iperf/)实时记录网络可用带宽，观察三种启动时延策略的实现情况。附图1、附图2、附图3分别对应三种算法的实验结果。

在实验二中，主要评估在不考虑节点环境下三种启动时延对于中断的影响，同时观察启动时延的变化状况，以及通过启动时延策略，是否对缓存的利用率起到一定的影响。在部署的实验二中，我们选择从PlanetLab上选择耶鲁大学提供的一个节点pl1.cs.yale.edu，在节点上分别开启四个实验用客户端监听不同的端口；在源服务器上编码一个WMV视频为媒体流后分发给四个服务器端，通过不同的端口向耶鲁节点对应的客户端进行传输，并同时利用Iperf实时记录网络可用带宽。首先统计了不同启动时延策略下中断随时间变化的情况，如附图4所示。然后统计了不同策略对于启动时延的影响，如附图5、附图6、附图7、附图8所示。最后观察不同策略对于缓存利用率的影响，如附图9、附图10所示。

比未使用启动时延策略而言，无论是通过节点自身的中断密度控制还是通过对于网络状况的探测，在网络条件不佳的情况下，都可以大幅度的降低播放中断次数，提高缓存利用率很好的实现对于环境的自适应。但是由于工作原理不同，三者之间也存在着比较明显的差异。并且在观察节点本身的情况已经整个覆盖网络中，这三种启动时延策略所表现出来的能力也不尽相同。

首先，当观察节点本身的情况下，由于不用考虑父节点所带来的直接影响，节点自身的环境以及自身健康状况是影响播放质量的关键因素。

表2实验二结果概述

改善播放中断能力	启动时延＞混合策略＞中断密度＞原始
		启动时延增长幅度	启动时延＞混合策略＞中断密度＞原始
改善缓存利用率能	启动时延＞混合策略＞中断密度＞原始
		力

表2为实验二的结果概述，从中我们可以看出，三种策略都可以很好的改善播放中断状况，改善缓存利用率，同时也增加了启动时延，然后三者之间还是存在一定差别。其中，部署了根据中断密度调整启动时延策略的客户端，其通过探测自身前一时刻的中断状况，可以有效的降低播放中断的次数，但是由于其减少中断的判断是通过上一时刻付出更多的中断来完成的，所以在三种策略中由于调整的启动时延程度不高，改善播放中断状况的能力最差，缓存利用率改善程度不高。相反的，由于调整的启动时延小，所以相比其他两个策略，可以达到更快的播放。而部署了根据网络状况调整启动时延策略的客户端，由于它主动探测节点的接受速率，可以更及时的自适应网络状况，所以改善播放中断状况的能力最强，缓存利用率也最大，但是当持续不断的网络状况不佳时，该策略会导致启动时延增加到极大值，用户需要等待很长时间才可以接受服务，严重影响用户体验。部署了混合启动时延策略的客户端，对网络状况和中断密度进行加权融合，很好的将前两种策略结合起来，在提供了较强的改善播放中断能力的同时，并没有像部署了网络状况启动时延策略的客户端调整启动时延那样过高的增加启动时延，达到了相对完善的平衡。

在我们的实验中，由于PlanetLab平台上的节点安装的都是linux系统，使用者通过ssh方式进行远程控制节点，所以实验在命令行模式下进行，不使用界面化的播放器，为了解决这个问题，我们编写了模拟播放器读包的线程playerProc，在客户端程序启动后会自动开启playProc线程。

在这个线程中，我们定义了一个核心类ConsTant，它定义了所有模拟播放器中必须的变量，例如接收数据指针，播放数据指针等以及集成了部分启动时延策略实现的代码。

该类的具体声明如下：

在ConsTant类中定义了几个变量，其中，AverPacklen是每个音视频数据的实际长度，单位是字节；Bitrate变量是通过PCP协议获取的音视频源的编码率；ReadPacketpersec根据Bitrate和AverPacklen算出来的播放器应当每秒钟读包的数量。IntRup_count变量用来统计播放中断的次数；writecount用来统计写入数据包的个数，每写入一个包加一；playcount用来模拟播放器的读取功能，统计读取数据包的个数，每读取一个包加一；模拟播放器线程的核心功能就是通过在IntRup_func()中比较这两个变量来实现的：当playconut大于或等于writecount时，表示缓存已经没有数据包可读，出现一次中断，IntRup_count变量自动加一。IntRup_func()函数基本功能具体实现如下：

模拟播放器读包线程playerProc在客户端程序启动后随之启动，并调用IntRup_func函数，开始不断的检测缓存中是否有数据包写入并且还未读出，同时引入启动延迟变量Startup(以数据包为单位)，只有延迟到达指定的时间，也就是写入了指定数量的数据包后，才开始读包。

根据中断密度调整启动时延策略的部署方案如下：

首先需要获取播放中断的密度，当建立频道链接时第一次记录系统时间：

timeA＝sys-＞getTime()；

当第一次发生中断时第二次记录系统时间：

timeB＝sys-＞getTime()；

中断密度为M＝n/N，N为时间段，n为该时间段内的中断次数，我们需要将中断密度控制在理想值M1内，也就是不断检测相邻两次中断时间差值与2/(M1+1)值的关系，功能实现的伪代码如下：

同时不停的检测当前系统时间timeC，如果一段时间N1内未发生中断，则将启动时延调回最小值，具体代码如下：

每当发生一次中断，就用timeB赋值timeA，将上一次中断的时间存入timeA中，然后再让timeB获取当前中断的系统时间，求timeB与timeA的差值，计算相邻两次中断的差值是否在理想的中断密度范围内，如果超出了范围且启动时延Startup小于缓存最大值，则Startup动态增加X个数据包；同时还有一个计时器timeC在每写入一个包时获取一次系统时间，如果timeC与timeB的差值到达理想数值N1时，则说明这段时间内都没有发生中断，Startup恢复到最小值。

根据网络状况调整启动时延策略的部署方案如下：

首先需要探测节点的接收速率，在这里接收速率并不一定等于网络带宽，当可用带宽足够好的情况下，接收速率的大小是由源服务器的编码速率决定的，所以我们将问题简化，只探测单位时间内节点接收到的数据包个数，以此来调整启动时延。

当建立频道链接后，在接收到第一个数据包时用计时器timeA记录系统时间：

并当每次写入数据包时都将系统时间存储到计时器timeB中，并不断的计算timeB与timeA之间的时间段长度，利用累加器sumPack记录该段时间内写入的数据包个数，具体代码如下：

constant-＞timeA＝sys-＞getTime()；//记录第一个数据包的写入时间

……

constant-＞writecount++；

constant-＞sumPack++；//记录该段时间内的数据包个数

constant-＞timeB＝sys-＞getTime()；//写入数据包时记录系统时间

当timeB与timeA之间的时间段长度大于等于1时，所记录的sumPack值即为当前时刻的接收速率，而之前所计算出的ReadPacketpersec为播放速率。

我们在每一单位时间都比对sumPack与ReadPacketpersec的值的关系，当sumPack小于ReadPacketpersec时，累加器badSum自加一；当badSum值到达门限值B时，说明这段时间网络状况持续不佳，则将Startup增加X个数据包；当sumPack大于等于ReadPacketpersec时，累加器goodSum自加一，当goodSum值增大到门限值A时，说明这段时间网络状况足以满足流媒体传输，则将Startup恢复为最小值。实现伪代码如下：

当完成一次sumPack与ReadPacketpersec的判断后，timeB将值赋予timeA，重新开始记录系统时间，统计接收速率。

混合启动时延策略的部署方案如下：

统计节点的接收速率，实现代码与根据网络状况调整启动时延的代码一样。由于要将中断密度策略融合进去避免启动时延增长过快，将判定中断密度的代码加入到判定网络状况差时执行措施的代码中，具体实现如下：

当badSum累积到门限值B时，说明网络状况持续不佳，但不立即增大启动时延，先判断中断密度是否在理想范围内：如果小于理想值，则恢复启动时延为初始值；如果大于理想值，则增加启动时延X个数据包。

Claims (1)

1.流媒体直播系统启动时延方法，其特征在于：

为以下三种启动时延策略之一：

1)根据播放中断密度动态启动时延策略

中断密度定义为pi＝n/T，n表示播放中断的次数，T表示整个媒体流的时间长度；由于直播系统媒体流的播放时间长度理论上是无限大的，即T里面包含了无限个时间长度为N的时段，所以整个媒体流的中断密度等价为一个时段内的中断密度：pw＝n/N；

当在某个长度为N的时间段内，如果没有达到n次播放中断，则保持启动时延的最小值，但不动态增加；如果达到n次播放中断，则动态增加启动时延，动态增加启动时延到最大值；调整过启动时延后，如果在长度为N的时间段内没有再达到n次播放中断，就将启动时延恢复到最小值；其中最小值为流媒体系统单位缓存值的5至10倍；最大值为流媒体系统单位缓存值的20至30倍；

2)根据网络状况动态启动时延策略

此处网络状况的优劣，是通过比较长度为N的时段内播放终端的数据包接收速率a与播放速率b的大小来衡量的；

如果接收速率a持续大于等于播放速率b，就将启动时延调整为最小值；如果接收速率a持续小于播放速率b，则动态增加启动时延；增加启动时延到最大值；调整过启动时延后，如果在长度为N的时间段内如果接收速率a持续大于等于播放速率b，就将启动时延恢复到最小值；其中最小值为流媒体系统单位缓存值的5至10倍；最大值为流媒体系统单位缓存值的20至30倍；

3)混合型动态启动时延策略

通过不断统计终端的接收速率，以判断下一时刻启动时延的大小；在长度为N的时段内，如果接收速率持续大于等于播放速率，则维持启动时延的最小值；当接收速率持续小于等于播放速率时，则判断长度为N的时段内的中断次数，如果未达到n次播放中断，则将启动时延固定在最小值；如果达到n次播放中断，则动态增加启动时延至最大值；其中最小值为流媒体系统单位缓存值的5至10倍；最大值为流媒体系统单位缓存值的20至30倍。

Images