CN106301684A - 一种媒体数据传输方法及装置 - Google Patents

Abstract

本发明实施例涉及网络技术领域，公开了一种媒体数据传输方法及装置。其中，该方法包括：获取发送端与接收端之间的至少两个网络时延；确定所述至少两个网络时延的变化趋势；根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率。采用本发明，能降低网络时延，减少网络拥塞，从而使系统在较恶劣的网络环境下，保持良好的传输性能。

Description

一种媒体数据传输方法及装置

技术领域

本发明涉及网络技术领域，具体涉及一种媒体数据传输方法及装置。

背景技术

近年来计算机网络的爆炸式发展，特别是大量多媒体实时业务的广泛应用，对传统的以传输控制协议(Transmission Control Protocol，TCP)为主的传输层协议提出了新的挑战。大部分多媒体应用对时延很敏感，但却具有一定的容错机制，能够容忍少量的报文丢失。此类应用要求传输协议开销小、响应快，并且不必保证传输完全可靠。此外，抖动也是对多媒体应用有较大影响的问题，而TCP拥塞控制使用的加性增加乘性减少(AdditiveIncrease Multiplicative Decrease，AIMD)策略，会引起发送速率很大的抖动。目前多媒体实时应用多采用用户数据报(User Datagram Protocol，UDP)协议来传输，但由于UDP协议缺乏拥塞控制机制，当基于TCP、UDP的应用共享网络带宽时，TCP流因具有拥塞退避机制而导致“饥饿”，而UDP将不公平地获得大量带宽，同时可能导致网络拥塞，影响Internet的鲁棒性，因此随着UDP协议的应用在Internet所占的比例的增加，其不足之处逐渐暴露。

针对这个问题，TCP友好速率控制算法(TCP Friendly Rate Control,TFRC)应运而生。TFRC是一种适合于多媒体传输，并具有拥塞退避机制，能够与TCP协议公平分享带宽的传输协议。在同等条件下，TFRC流具有与TCP流近似相同的吞吐量，因此，可以“公平地”与TCP共享网络带宽。另一方面，TFRC吞吐量变化稳定、抖动较小，因此更加适合电话、流媒体等对传输速率的平滑性要求较高的应用。

TFRC是一种基于接收端的机制，其基本思想是在接收端检测网络的拥塞信号丢包事件频率，并将信号反馈给发送端。而发送端利用以丢包事件频率为变量的吞吐率公式来调整发送速率，以适应网络拥塞的状况，同时保证协议的友好性和发送速率的平滑性。

现有基于TFRC的UDP网络传输框架通过检测丢包事件频率来估计网络可用带宽，确定流媒体数据的发送速率，在网络存在瓶颈的情况下，这样的机制势必导致瓶颈链路拥塞并出现路由排队丢包。这种情况下流媒体传输系统不但会出现丢包，时延增加，而且丢包导致的重传也会导致数据吞吐量下降。

发明内容

本发明实施例公开了一种媒体数据传输方法及装置，能降低网络时延，减少网络拥塞，从而使系统在较恶劣的网络环境下，保持良好的传输性能。

本发明实施例第一方面公开一种媒体数据传输方法，包括：

获取发送端与接收端之间的至少两个网络时延；

确定所述至少两个网络时延的变化趋势；

根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率。

本发明实施例第二方面公开一种媒体数据传输装置，包括：

获取模块，用于获取发送端与接收端之间的至少两个网络时延；

确定模块，用于确定所述至少两个网络时延的变化趋势；

调整模块，用于根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率。

本发明实施例中，获取发送端与接收端之间的至少两个网络时延，确定该至少两个网络时延的变化趋势，根据该变化趋势，调整发送端向接收端发送流媒体数据的发送速率，通过网络时延及时确定是否调整发送速率，而不必等到丢包产生后才调整发送速率，这样能降低网络时延，减少网络拥塞，从而使系统在较恶劣的网络环境下，保持良好的传输性能。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例公开的一种媒体数据传输方法的流程图；

图2是本发明实施例公开的另一种媒体数据传输方法的流程图；

图3是本发明实施例公开的一种状态转移图；

图4是本发明实施例公开的一种媒体数据传输装置的结构图；

图5是本发明实施例公开的另一种媒体数据传输装置的结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例公开了一种媒体数据传输方法及装置可以应用于基于TFRC的UDP网络传输框架中，TFRC是一种基于接收端的机制，其基本思想是在接收端检测网络的拥塞信号丢包事件频率，并将信号反馈给发送端。而发送端利用以丢包事件频率和往返时延及重传超时时间为变量的吞吐率公式来调整发送速率，以适应网络拥塞的状况，同时保证协议的友好性和发送速率的平滑性。协议使用的吞吐量方程如下：

$T=\frac{1-}{RTT\×\sqrt{\frac{2p}{3}}+RTO\min (1,3\sqrt{\frac{2p}{8}})p(1+32p^2)}$

其中，路由往返时延(Round-Trip Time，RTT)，RTO为重传超时时间，p为丢包事件频率。在计算发送速率前，必须首先得到以上参数。其中，由于接收端并不对每个收到的数据包发送应答，因此丢包事件频率必须由接收端统计。而RTT和RTO既可以在发送端测量也可以在接收端测量。目前TFRC协议的实现是由发送端测量RTT和RTO，接收端统计丢包事件频率并反馈给发送端，发送端根据以上参数计算合理的发送速率。

现有基于TFRC的UDP网络传输框架通过检测丢包事件频率和网络往返时延来估计网络可用带宽，调整发送速率，其网络瓶颈带宽测量过程必然伴随着拥塞丢包。这样的机制决定了在节点路由缓存队列较长，或者带宽较小的网络场景，TFRC传输协议会带来较严重的网络拥塞。

通常在瓶颈带宽较小，链路路由缓存队列较长的网络环境中，使用TFRC的流媒体传输系统往往出现数十秒的往返时延。一个较典型的场景是移动3G网络中时分同步码分多址(Time Division-Synchronous Code Division Multiple Access，TD-SCDMA)，其上行带宽约为100kBps，TFRC协议运行往返时延大约为40～60s，这样的传输性能使得该系统基本无法满足移动网络下的实时流媒体通信应用需求。

针对这个问题，本发明实施例提出一种针对小带宽高延时的TFRC改进策略。通过这种方法，本发明实施例检测RTT上升时即对发送速率进行调整，而不是等到RTT上升至出现网络丢包才对发送速率进行调整，将RTT作为较小带宽下网络出现拥塞的标志，对发送速率进行降低，从而避免较小带宽网络环境下往返时延大幅升高，和由此产生的超时重传、丢帧、播放卡顿等不良后果。

请参阅图1，图1是本发明实施例公开的一种媒体数据传输方法的流程图。如图1所示，该方法可以包括以下步骤：

S100、获取发送端与接收端之间的至少两个网络时延；

本发明实施例中，网络时延可以是RTT，或者单向网络时延。正常情况下，对当前网络可以做如下假设：1.网络可用带宽大于接收端的接收速率；2.网络出现拥塞时，RTT上升(当网络出现拥塞时，节点路由缓存队列较长，从而导致RTT上升)。

获取当前网络中发送端与接收端之间的至少两个网络时延，获取方法可以是，发送端发送一个数据包，该数据包中携带发送时间戳，当该数据包到达接收端后，接收端向发送端返回确认帧，发送端可以根据数据包的发送时间戳以及确认帧的接收时间确定当前网络的RTT。

当需要确定是否调整发送端的发送速率时，则需要获取发送端与接收端之间的至少两个数据包的至少两个网络时延，从而通过该至少两个网络时延的变化趋势以判断链路当前的使用状况，从而对发送速率进行相应控制。

S101、确定所述至少两个网络时延的变化趋势；

本发明实施例中，将所获得的至少两个网络时延根据获取时间进行排序，从而确定该至少两个网络时延的变化趋势，比如可以通过坐标轴来判断该至少两个网络时延的变化趋势，该坐标轴的横坐标为获取网络时延的时间，该坐标轴的纵坐标为各个网络时延的大小，将各个网络时延通过曲线连接起来，从而可以直观反应出该至少两个网络时延的变化趋势。

S102，根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率。

本发明实施例中，根据该至少两个网络时延的变化趋势，调整发送端向接收端发送流媒体数据的发送速率，流媒体数据包括音频数据、视频数据以及音视频数据等等。根据变化趋势调整发送速率的调整方式可以采用Pathload带宽估计方法进行调整。

Pathload带宽估计方法是一种基于SLoPS的带宽估计方法，SLoPS是指发送一系列等长等速率的UDP数据包作为探测包，并保持一条TCP通路以传递发送控制信息。若当前发送速率大于可用带宽，则网络时延会出现明显的上升趋势；反之若发送速率小于可用带宽，延时则会保持平稳。Pathload算法通过在对端观察单向延时情况并绘制曲线，判断当前延时的变化趋势，并将该信息返回源端。源端通过延时变化趋势信息对发送速率进行反复调整，直至发送速率近似等于网络可用带宽，并保持较低的延时。

可选的，所述根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率，可以包括以下三种可选的实施方式：

第一种可选的实施方式中，若所述变化趋势为连续上升趋势，则减小所述发送端向所述接收端发送流媒体数据的发送速率；

具体可选的，所述减小所述发送端向所述接收端发送流媒体数据的发送速率，包括：

当检测到所述接收端的接收速率大于所述发送速率，则停止减小所述发送端向所述接收端发送流媒体数据的发送速率。

具体的，若该至少两个网络时延的变化趋势为连续上升趋势，则说明当前网络出现了拥塞，因为当路由出现拥塞时，路由节点的路由缓存队列不断增加，导致数据包的网络时延也不断增加，则说明需要减小发送端向接收端发送流媒体数据的发送速率。

可选的，在减小发送端向接收端发送流媒体数据的发送速率之前还可以进一步判断距离上次减小发送速率的时间是否超过2*RTT，若超过，则减小发送速率。具体减小的方式可以是乘性减少当前发送速率，乘性减少即是以大于1的倍数减少当前发送速率，比如倍数为2，则每次都将当前速率除以2作为下次发送速率。

同时，在减小发送速率的同时，获取接收端的接收速率，若接收速率大于当前的发送速率，则停止减小发送端向接收端发送流媒体数据的发送速率。需要说明的是，在停止减小发送速率时，需要进一步监控网络时延的变化趋势，若RTT又出现连续上升趋势，且距离上次减小发送速率的时间超过2*RTT，还需要进一步减小发送速率；若RTT出现下降趋势或者平稳趋势，则可以进一步参照第二种可选的实施方式和第三种可选的实施方式进行执行，以调整发送端的发送速率。

第二种可选的实施方式中，若所述变化趋势为连续下降趋势，则增大所述发送端向所述接收端发送流媒体数据的发送速率。

具体的，若该至少两个网络时延的变化趋势为连续下降趋势，则说明当前网络状况有所好转，比如网络拥塞得到了解决，网络开始恢复正常状况，路由缓存队列逐渐减少，则可以增大发送端向接收端发送流媒体数据的发送速率，从而增加网络吞吐量。

可选的，在增大发送速率之前，还可以检测历史拥塞时的发送速率与当前发送速率之差是否大于预设阈值，若是，则增大发送端的发送速率。

需要说明的是，在增大发送速率的同时，还需要检测RTT的变化趋势，若检测到RTT变化趋势出现上升状态，则需要停止增大发送速率，并进一步检测是否一直处于连续上升趋势，若是，则需要减小发送速率，具体的处理过程请参照第一种可选的实施方式。若RTT的变化趋势为平稳状态，且该平稳状态持续一定时长，则可以进一步增大发送速率，具体请参照第三种可选的实施方式。

第三种可选的实施方式中，若所述变化趋势为平稳趋势，则增大所述发送端向所述接收端发送流媒体数据的发送速率，所述平稳趋势包括所述至少两个网络时延之间的差值小于第一阈值。

具体的，若该至少两个网络时延的变化趋势为平稳趋势，则说明当前网络状况比较稳定，路由缓存队列一直保持在一定的长度范围内，可以增大发送端向接收端发送流媒体数据的发送速率，需要说明的是，平稳趋势即是该至少两个网络时延之间的差值都在第一阈值以内。

可选的，在检测至少两个网络时延的变化趋势是否为平稳趋势的检测方式可以是，检测该平稳趋势的持续时间是否超过一定的时间范围，比如，该平稳趋势是否超过5秒，若超过5秒，则可以增大发送端的发送速率。

需要说明的是，在增大发送速率的同时，还需要检测RTT的变化趋势，若检测到RTT变化趋势出现上升状态，则需要停止增大发送速率，并进一步检测是否一直处于连续上升趋势，若是，则需要减小发送速率，具体的处理过程请参照第一种可选的实施方式。若RTT变化趋势出现下降状态，则需要进一步增大发送端的发送速率，具体执行过程请参照第二种可选的实施方式。

进一步可选的，基于第二种可选的实施方式和第三种可选的实施方式，所述增大所述发送端向所述接收端发送流媒体数据的发送速率，包括：

以乘性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，所述乘性算法包括将所述发送速率与第一预设参数相乘以增大所述发送速率，所述第一预设参数为大于1的自然数；或者，

以加性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，所述加性算法包括将所述发送速率与与第二预设参数相加以增大所述发送速率。

具体实施例中，增大发送端的发送速率的增大方式可以是以乘性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，比如，当前发送速率是300kbps，则以2为第一预设参数乘性增加该发送速率时，则每次增加的发送速率分别为600kbps(300*2)、1200kbps(600*2)等等，乘性算法增大发送速率的方式会使得发送速率增加得比较快。

需要说明的是，这种乘性算法增大发送速率的应用场景可以是当前发送速率远远小于历史拥塞发送速率，并且RTT处于连续下降趋势或者平稳趋势，则可以以乘性算法增加发送端的发送速率。

具体实施例中，增大发送端的发送速率的增大方式可以是以加性算法增加所述发送端向所述接收端发送流媒体数据的发送速率，比如，当前发送速率是300kbps，第二预设参数是100kbps，则每次增加的发送速率分别为400kbps(300+100)、500kbps(400+100)等等。加性算法增加发送速率的方式会使得发送速率增大得比较慢。

需要说明的是，这种加性算法增大发送速率的应用场景可以是RTT处于下降趋势或者平稳趋势，系统正在以乘性算法增大发送端的发送速率，但是当前发送速率接近历史拥塞时的发送速率，则可以由乘性算法增大发送速率的方式转为加性算法增大发送速率。或者，这种加性算法增大发送速率的应用场景也可以是系统停止增大发送速率或者停止减少发送速率，但是RTT处于下降趋势或者平稳趋势，但是当前发送速率接近历史拥塞时的发送速率，则可以以加性算法增大发送速率。

本发明实施例中，获取发送端与接收端之间的至少两个网络时延，确定该至少两个网络时延的变化趋势，根据该变化趋势，调整发送端向接收端发送流媒体数据的发送速率，通过网络时延及时确定是否调整发送速率，而不必等到丢包产生后才调整发送速率，这样能降低网络时延，减少网络拥塞，从而使系统在较恶劣的网络环境下，保持良好的传输性能。

请参阅图2，图2是本发明实施例公开的另一种媒体数据传输方法的流程图。如图2所示，该方法可以包括以下步骤：

S200，检测发送端与接收端之间的网络可用带宽；

S201，若所述网络可用带宽小于第二阈值，则执行获取发送端与接收端之间的至少两个网络时延的步骤。

本发明实施例中，在检测到发送端与接收端之间的网络可用带宽小于第二阈值(即是对端接收速率较小且网络往返时延较大的情况下)，不采用在大带宽网络下表现良好的TFRC协议，转而使用自拥塞带宽估计策略(即本发明实施例的方案)，降低网络延时，避免丢包。

在接收速率较小(比如小于400kbps)且RTT出现上升时，可以判断当前可用带宽较小，此时放弃TFRC，转而启用另一套类Pathload的带宽估计策略，即获取发送端与接收端之间的至少两个网络时延。在小带宽网络环境下，采用类Pathload的带宽探测策略决定发送速率，可以使得发送速率尽可能稳定。

需要说明的是，当接收速率较大(大于350kbps)且RTT没有任何异常，退出小带宽逻辑，重新使用TFRC传输协议，以保证正常网络下传输的吞吐率和稳定性。

S202，确定所述至少两个网络时延的变化趋势；

S203，根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率。

本发明实施例步骤S202～S203请参照图1的实施例步骤S101～S102，在此不再赘述。

本发明实施例中，获取发送端与接收端之间的至少两个网络时延，确定该至少两个网络时延的变化趋势，根据该变化趋势，调整发送端向接收端发送流媒体数据的发送速率，通过网络时延及时确定是否调整发送速率，而不必等到丢包产生后才调整发送速率，这样能降低网络时延，减少网络拥塞，从而使系统在较恶劣的网络环境下，保持良好的传输性能。

请参照图3，为本发明实施例提供的一种状态转移图，如图所示，本发明实施例包括的状态有：停止上升状态、乘性下降状态、停止下降状态、加性上升状态以及乘性上升状态，下面分别对这几种状态之间的转移进行说明：

1.HOLDBYINC(停止上升状态)

进入条件：系统处于ADDINC(加性上升状态)或MULINC(乘性上升状态)状态，且检测到RTT出现上升。

状态行为：不作任何处理。

转移条件：a.RTT出现过下降且稳定住，或者RTT稳定超过5秒，进入ADDINC或MULINC状态；

b.RTT连续上升，网络出现拥塞且距离上次出现MULDEC状态的时间超过2*RTT，则进入MULDEC状态。

2.HOLDBYDEC(停止下降状态)

进入条件：系统处于MULDEC状态，且当前发送速率小于接收速率。

状态行为：不作任何处理。

转移条件：RTT出现过下降且稳定住，或者RTT稳定超过5秒，进入ADDINC或MULINC状态。

3.MULDEC(乘性下降状态)

进入条件：系统处于HOLDBYINC状态，RTT连续上升，网络出现拥塞且距离上次出现MULDEC状态的时间超过2*RTT。

状态行为：依据发送速率和接收速率乘性减少当前发送速率。

转移条件：当前发送速率小于接收速率，进入HOLDBYDEC状态。

4.ADDINC(加性上升状态)

进入条件：a.系统处于MULINC状态，且检测到当前发送速率接近历史拥塞时的发送速率；

b.系统处于HOLDBYINC或HOLDBYDEC状态，RTT出现过下降且稳定住，或者RTT稳定超过5秒，且检测到当前发送速率接近历史拥塞时的发送速率。

状态行为：加性增加当前发送速率。

转移条件：a.检测到RTT出现上升，进入HOLDBYINC状态；

b.当前发送速率远小于历史拥塞时的发送速率，进入MULINC状态。

5.MULINC(乘性上升状态)

进入条件：a.系统处于ADDINC状态，且检测到当前发送速率远小于历史拥塞时的发送速率；

b.系统处于HOLDBYINC或HOLDBYDEC状态，RTT出现过下降且稳定住，或者RTT稳定超过5秒，且检测到当前发送速率接近历史拥塞时的发送速率。

状态行为：乘性增加当前发送速率。

转移条件：a.检测到RTT出现上升，进入HOLDBYINC状态；

b.当前发送速率接近历史拥塞时的发送速率，进入ADDINC状态。

请参阅图4，图4是本发明实施例公开的一种媒体数据传输装置的结构图。如图4所示，该媒体数据传输装置包括：

获取模块100，用于获取发送端与接收端之间的至少两个网络时延；

本发明实施例中，网络时延可以是RTT，或者单向网络时延。正常情况下，对当前网络可以做如下假设：1.网络可用带宽大于接收端的接收速率；2.网络出现拥塞时，RTT上升(当网络出现拥塞时，节点路由缓存队列较长，从而导致RTT上升)。

获取当前网络中发送端与接收端之间的至少两个网络时延，获取方法可以是，发送端发送一个数据包，该数据包中携带发送时间戳，当该数据包到达接收端后，接收端向发送端返回确认帧，发送端可以根据数据包的发送时间戳以及确认帧的接收时间确定当前网络的RTT。

当需要确定是否调整发送端的发送速率时，则需要获取发送端与接收端之间的至少两个数据包的至少两个网络时延，从而通过该至少两个网络时延的变化趋势以判断链路当前的使用状况，从而对发送速率进行相应控制。

确定模块101，用于确定所述至少两个网络时延的变化趋势；

本发明实施例中，将所获得的至少两个网络时延根据获取时间进行排序，从而确定该至少两个网络时延的变化趋势，比如可以通过坐标轴来判断该至少两个网络时延的变化趋势，该坐标轴的横坐标为获取网络时延的时间，该坐标轴的纵坐标为各个网络时延的大小，将各个网络时延通过曲线连接起来，从而可以直观反应出该至少两个网络时延的变化趋势。

调整模块102，用于根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率。

本发明实施例中，根据该至少两个网络时延的变化趋势，调整发送端向接收端发送流媒体数据的发送速率，流媒体数据包括音频数据、视频数据以及音视频数据等等。根据变化趋势调整发送速率的调整方式可以采用Pathload带宽估计方法进行调整。

Pathload带宽估计方法是一种基于SLoPS的带宽估计方法，SLoPS是指发送一系列等长等速率的UDP数据包作为探测包，并保持一条TCP通路以传递发送控制信息。若当前发送速率大于可用带宽，则网络时延会出现明显的上升趋势；反之若发送速率小于可用带宽，延时则会保持平稳。Pathload算法通过在对端观察单向延时情况并绘制曲线，判断当前延时的变化趋势，并将该信息返回源端。源端通过延时变化趋势信息对发送速率进行反复调整，直至发送速率近似等于网络可用带宽，并保持较低的延时。

具体可选的，所述调整模块102具体用于：

若所述变化趋势为连续上升趋势，则减小所述发送端向所述接收端发送流媒体数据的发送速率；

进一步可选的，所述调整模块102减小所述发送端向所述接收端发送流媒体数据的发送速率具体包括：

当检测到所述接收端的接收速率大于所述发送速率，则停止减小所述发送端向所述接收端发送流媒体数据的发送速率。

具体的，若该至少两个网络时延的变化趋势为连续上升趋势，则说明当前网络出现了拥塞，因为当路由出现拥塞时，路由节点的路由缓存队列不断增加，导致数据包的网络时延也不断增加，则说明需要减小发送端向接收端发送流媒体数据的发送速率。

可选的，在减小发送端向接收端发送流媒体数据的发送速率之前还可以进一步判断距离上次减小发送速率的时间是否超过2*RTT，若超过，则减小发送速率。具体减小的方式可以是乘性减少当前发送速率，乘性减少即是以大于1的倍数减少当前发送速率，比如倍数为2，则每次都将当前速率除以2作为下次发送速率。

同时，在减小发送速率的同时，获取接收端的接收速率，若接收速率大于当前的发送速率，则停止减小发送端向接收端发送流媒体数据的发送速率。需要说明的是，在停止减小发送速率时，需要进一步监控网络时延的变化趋势，若RTT又出现连续上升趋势，且距离上次减小发送速率的时间超过2*RTT，还需要进一步减小发送速率；若RTT出现下降趋势或者平稳趋势，则可以进一步参照第二种可选的实施方式和第三种可选的实施方式进行执行，以调整发送端的发送速率。

若所述变化趋势为连续下降趋势，则增大所述发送端向所述接收端发送流媒体数据的发送速率。

具体的，若该至少两个网络时延的变化趋势为连续下降趋势，则说明当前网络状况有所好转，比如网络拥塞得到了解决，网络开始恢复正常状况，路由缓存队列逐渐减少，则可以增大发送端向接收端发送流媒体数据的发送速率，从而增加网络吞吐量。

可选的，在增大发送速率之前，还可以检测历史拥塞时的发送速率与当前发送速率之差是否大于预设阈值，若是，则增大发送端的发送速率。

需要说明的是，在增大发送速率的同时，还需要检测RTT的变化趋势，若检测到RTT变化趋势出现上升状态，则需要停止增大发送速率，并进一步检测是否一直处于连续上升趋势，若是，则需要减小发送速率，具体的处理过程请参照第一种可选的实施方式。若RTT的变化趋势为平稳状态，且该平稳状态持续一定时长，则可以进一步增大发送速率，具体请参照第三种可选的实施方式。

若所述变化趋势为平稳趋势，则增大所述发送端向所述接收端发送流媒体数据的发送速率，所述平稳趋势包括所述至少一个网络时延之间的差值小于第一阈值。

具体的，若该至少两个网络时延的变化趋势为平稳趋势，则说明当前网络状况比较稳定，路由缓存队列一直保持在一定的长度范围内，可以增大发送端向接收端发送流媒体数据的发送速率，需要说明的是，平稳趋势即是该至少两个网络时延之间的差值都在第一阈值以内。

可选的，在检测至少两个网络时延的变化趋势是否为平稳趋势的检测方式可以是，检测该平稳趋势的持续时间是否超过一定的时间范围，比如，该平稳趋势是否超过5秒，若超过5秒，则可以增大发送端的发送速率。

需要说明的是，在增大发送速率的同时，还需要检测RTT的变化趋势，若检测到RTT变化趋势出现上升状态，则需要停止增大发送速率，并进一步检测是否一直处于连续上升趋势，若是，则需要减小发送速率，具体的处理过程请参照第一种可选的实施方式。若RTT变化趋势出现下降状态，则需要进一步增大发送端的发送速率，具体执行过程请参照第二种可选的实施方式。

进一步可选的，所述调整模块102增大所述发送端向所述接收端发送流媒体数据的发送速率具体包括：

以乘性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，所述乘性算法包括将所述发送速率与第一预设参数相乘以增大所述发送速率，所述第一预设参数为大于1的自然数；或者，

以加性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，所述加性算法包括将所述发送速率与与第二预设参数相加以增大所述发送速率。

具体实施例中，增大发送端的发送速率的增大方式可以是以乘性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，比如，当前发送速率是300kbps，则以2为第一预设参数乘性增加该发送速率时，则每次增加的发送速率分别为600kbps(300*2)、1200kbps(600*2)等等，乘性算法增大发送速率的方式会使得发送速率增加得比较快。

需要说明的是，这种乘性算法增大发送速率的应用场景可以是当前发送速率远远小于历史拥塞发送速率，并且RTT处于连续下降趋势或者平稳趋势，则可以以乘性算法增加发送端的发送速率。

具体实施例中，增大发送端的发送速率的增大方式可以是以加性算法增加所述发送端向所述接收端发送流媒体数据的发送速率，比如，当前发送速率是300kbps，第二预设参数是100kbps，则每次增加的发送速率分别为400kbps(300+100)、500kbps(400+100)等等。加性算法增加发送速率的方式会使得发送速率增大得比较慢。

需要说明的是，这种加性算法增大发送速率的应用场景可以是RTT处于下降趋势或者平稳趋势，系统正在以乘性算法增大发送端的发送速率，但是当前发送速率接近历史拥塞时的发送速率，则可以由乘性算法增大发送速率的方式转为加性算法增大发送速率。或者，这种加性算法增大发送速率的应用场景也可以是系统停止增大发送速率或者停止减少发送速率，但是RTT处于下降趋势或者平稳趋势，但是当前发送速率接近历史拥塞时的发送速率，则可以以加性算法增大发送速率。

本发明实施例中，获取发送端与接收端之间的至少两个网络时延，确定该至少两个网络时延的变化趋势，根据该变化趋势，调整发送端向接收端发送流媒体数据的发送速率，通过网络时延及时确定是否调整发送速率，而不必等到丢包产生后才调整发送速率，这样能降低网络时延，减少网络拥塞，从而使系统在较恶劣的网络环境下，保持良好的传输性能。

请参照图5，为本发明实施例提供的另一种媒体数据传输装置的结构示意图，如图所示，本发明实施例的媒体数据传输装置包括获取模块200、确定模块201、调整模块202以及检测模块203；其中，获取模块200、确定模块201、调整模块202请参照图4实施例的描述，在此不再赘述。

检测模块203，用于检测发送端与接收端之间的网络可用带宽；

若所述网络可用带宽小于第二阈值，则所述获取模块200获取发送端与接收端之间的至少两个网络时延。

本发明实施例中，在检测到发送端与接收端之间的网络可用带宽小于第二阈值(即是对端接收速率较小且网络往返时延较大的情况下)，不采用在大带宽网络下表现良好的TFRC协议，转而使用自拥塞带宽估计策略(即本发明实施例的方案)，降低网络延时，避免丢包。

在接收速率较小(比如小于400kbps)且RTT出现上升时，可以判断当前可用带宽较小，此时放弃TFRC，转而启用另一套类Pathload的带宽估计策略，即获取发送端与接收端之间的至少两个网络时延。在小带宽网络环境下，采用类Pathload的带宽探测策略决定发送速率，可以使得发送速率尽可能稳定。

需要说明的是，当接收速率较大(大于350kbps)且RTT没有任何异常，退出小带宽逻辑，重新使用TFRC传输协议，以保证正常网络下传输的吞吐率和稳定性。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random AccessMemory，RAM)、磁盘或光盘等。

以上对本发明实施例公开的一种客户端播放控制方法及客户端进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (12)

1.一种媒体数据传输方法，其特征在于，包括：

获取发送端与接收端之间的至少两个网络时延；

确定所述至少两个网络时延的变化趋势；

根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率。

2.如权利要求1所述的方法，其特征在于，所述根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率，包括：

若所述变化趋势为连续上升趋势，则减小所述发送端向所述接收端发送流媒体数据的发送速率；

若所述变化趋势为连续下降趋势，则增大所述发送端向所述接收端发送流媒体数据的发送速率。

3.如权利要求2所述的方法，其特征在于，所述减小所述发送端向所述接收端发送流媒体数据的发送速率，包括：

当检测到所述接收端的接收速率大于所述发送速率，则停止减小所述发送端向所述接收端发送流媒体数据的发送速率。

4.如权利要求1所述的方法，其特征在于，所述根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率，包括：

若所述变化趋势为平稳趋势，则增大所述发送端向所述接收端发送流媒体数据的发送速率，所述平稳趋势包括所述至少两个网络时延之间的差值小于第一阈值。

5.如权利要求2或4所述的方法，其特征在于，所述增大所述发送端向所述接收端发送流媒体数据的发送速率，包括：

以乘性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，所述乘性算法包括将所述发送速率与第一预设参数相乘以增大所述发送速率，所述第一预设参数为大于1的自然数；或者，

以加性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，所述加性算法包括将所述发送速率与与第二预设参数相加以增大所述发送速率。

6.如权利要求1所述的方法，其特征在于，所述获取发送端与接收端之间的至少两个网络时延之前，还包括：

检测发送端与接收端之间的网络可用带宽；

若所述网络可用带宽小于第二阈值，则执行获取发送端与接收端之间的至少两个网络时延的步骤。

7.一种媒体数据传输装置，其特征在于，包括：

获取模块，用于获取发送端与接收端之间的至少两个网络时延；

确定模块，用于确定所述至少两个网络时延的变化趋势；

调整模块，用于根据所述变化趋势，调整所述发送端向所述接收端发送流媒体数据的发送速率。

8.如权利要求7所述的装置，其特征在于，所述调整模块具体用于：

若所述变化趋势为连续上升趋势，则减小所述发送端向所述接收端发送流媒体数据的发送速率；

若所述变化趋势为连续下降趋势，则增大所述发送端向所述接收端发送流媒体数据的发送速率。

9.如权利要求8所述的装置，其特征在于，所述调整模块减小所述发送端向所述接收端发送流媒体数据的发送速率具体包括：

当检测到所述接收端的接收速率大于所述发送速率，则停止减小所述发送端向所述接收端发送流媒体数据的发送速率。

10.如权利要求7所述的装置，其特征在于，所述调整模块具体用于：

若所述变化趋势为平稳趋势，则增大所述发送端向所述接收端发送流媒体数据的发送速率，所述平稳趋势包括所述至少两个网络时延之间的差值小于第一阈值。

11.如权利要求8或10所述的装置，其特征在于，所述调整模块增大所述发送端向所述接收端发送流媒体数据的发送速率具体包括：

以乘性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，所述乘性算法包括将所述发送速率与第一预设参数相乘以增大所述发送速率，所述第一预设参数为大于1的自然数；或者，

以加性算法增大所述发送端向所述接收端发送流媒体数据的发送速率，所述加性算法包括将所述发送速率与与第二预设参数相加以增大所述发送速率。

12.如权利要求7所述的装置，其特征在于，所述装置还包括：

检测模块，用于检测发送端与接收端之间的网络可用带宽；

若所述网络可用带宽小于第二阈值，则所述获取模块获取发送端与接收端之间的至少两个网络时延。