CN106850595A - 一种流媒体传输优化方法及装置 - Google Patents

Abstract

本发明公开了一种流媒体传输优化方法及装置，该方法包括：流媒体服务器开始以RTP报文向终端发送流媒体数据；终端将检测丢失RTP报文，并通过丢包监测窗口聚合一组丢失RTP报文的序号后，通过RTSP信令向媒体服务器发起该组丢失RTP报文的重传请求；流媒体服务器根据重传请求RTSP信令，通过原流媒体数据传输通道向终端重传相应RTP报文；终端将收到重传RTP报文插入到对应位置；实时监测缓存状态，控制流媒体服务器的流媒体数据以及重传RTP报文发流速率。本发明采用丢包重传技术，并在流量控制技术的支持下，使丢包重传也有简单的拥塞避免机制，不仅提高了流媒体的传输质量，还增加了终端设备的媒体缓存能力，提高IPTV播放质量及流畅性。

Description

一种流媒体传输优化方法及装置

技术领域

本发明涉及流媒体传输与控制技术，具体涉及一种流媒体传输优化方法及装置。

背景技术

IPTV业务基于网络层传输协议TCP/UDP进行数据传送。其中，TCP是面向连接的传输，可靠性好，但传输的效率低,在网络质量不好的情况下，实时性差；UDP不是面向连接的传输，可靠性差，会发生数据包丢失，但传输的效率以及实时性较高。

目前市场上，各运营商在各地区对于两种流媒体数据传输方式都有应用，但基于对实时性要求和网络负载的考虑，首选方案较多为UDP，因此在UDP传输的应用场景中，经常会出现因为丢包和抖动等异常因素引起的视频卡顿、花屏，影响流媒体播放效果。

发明内容

本发明所要解决的技术问题是以UDP为数据传输基础的IPTV架构中，在保证IPTV播放实时性的前提下，如何提高传输可靠性、网络适应性以及增强本地缓存能力的问题。

为了解决上述技术问题，本发明所采用的技术方案是提供一种流媒体传输优化方法，包括以下步骤：

步骤S10、终端与流媒体服务器之间进行支持丢包重传的初始化后，流媒体服务器开始以RTP报文向终端发送流媒体数据；

步骤S20、终端将检测丢失RTP报文，并经丢包监测窗口聚合一组丢失RTP报文的序号后，通过RTSP信令向媒体服务器发起该组丢失RTP报文的重传请求；

步骤S30、流媒体服务器根据重传请求RTSP信令，通过原流媒体数据传输通道向终端重传相应RTP报文；

步骤S40、终端将收到重传RTP报文插入到对应位置；

步骤S50、终端实时监测缓存状态，控制流媒体服务器的流媒体数据以及重传RTP报文发流速率，调整其缓存区。

在上述方法中，步骤S10包括以下步骤：

步骤S11、终端收到应用发来的基于RTSP协议的流媒体播放任务，向流媒体服务器的RTSP服务器发起描述播放任务请求，并在描述播放任务请求信令中申明丢包重传能力；

步骤S12、RTSP服务器回应描述播放任务请求，并表示支持“丢包重传”功能；

步骤S13、媒体服务器获取描述播放任务请求信令中携带的终端流媒体接收地址，并以RTP报文方式开始向终端发送流媒体数据。

在上述方法中，步骤S20包括以下步骤：

步骤S21、终端在接收流媒体数据时，根据RTP报文序号检测RTP报文丢失，将检测到的丢失RTP报文序号记录到丢包监测窗口，丢包数加1；

步骤S22、判断丢包监测窗口的丢包数是否为1；如是，转步骤S23；否则，转步骤S24；

步骤S23、启动丢包监测计时器，执行步骤S21；

步骤S24、判断丢包监测窗口中丢包数是否达到预设值，如是，转步骤S26；否则，转步骤S25；

步骤S25、判断丢包监测计时器是否超时，如果超时，转步骤S26；否则，转步骤S21；

步骤S26、取消丢包监测计时器，转步骤S27；

步骤S27、终端把丢包监测窗口中所有丢包RTP报文记录转移到重传等待队列中，并向流媒体服务器发起丢包重传请求，丢包重传请求信令携带所有丢包监测窗口中丢包RTP报文的序号。

在上述方法中，在步骤S27中，在终端把丢包监测窗口中所有丢包RTP报文记录转移到重传等待队列中时，清空丢包监测窗口丢包RTP报文序号记录及记数，准备开始下一轮丢包监测，并针对重传等待队列中的每个丢包RTP报文将记录开启重传等待循环计时器，定时清理丢包重传队列中等待重传、但是对应的重传等待循环计时器超时的丢包RTP报文记录。

在上述方法中，步骤S40具体包括以下步骤：

步骤S41、当收到新的RTP报文时，判断是否是有效的重传RTP报文，如是，转步骤S42；否则，转步骤S43；

步骤S42、将收到的重传RTP报文根据其报文序号插入到终端接收流媒体数据的缓存区的相应位置，并从重传等待队列中删除对应的丢包RTP报文记录，转步骤S44；

步骤S43、此报文已过期，丢弃；

步骤S44、判断重传等待队列中是否还有丢包RTP报文记录，如果是，转步骤S41；否则，结束程序。

在上述方法中，步骤S50包括以下步骤：

步骤S51、终端实时监测缓存状态，如超过了缓存上溢或下溢的预警线，则向流媒体服务器发出携带指定的发流速度和需要调整的缓存大小信息的发流速率调整请求指令；

步骤S52、流媒体服务器根据终端的请求，基于指定的发流速度和终端需要调整的缓存大小信息确定发流速率调整的时间，进行流媒体数据以及重传RTP报文的发流速率调整。

在上述方法中，步骤S51包括以下步骤：

步骤S511、终端收到应用发来的基于RTSP协议的流媒体播放任务，向RTSP服务器发起描述请求，并在描述请求信令中申明流量控制功能的支持能力；

步骤S512、RTSP服务器回应描述请求，表示支持“流量控制”功能；

步骤S513、终端与RTSP服务器之间完成流量控制初始化，发出播放信令，播放信令携带初始发流速度和本地缓存大小的上溢门限；

步骤S514、终端接收到流媒体数据以及重传RTP报文，存放到缓冲区；

步骤S515、如果终端检测到RTP报文的丢包率明显提升或下降，或者本地缓存出现上溢或下溢，终端通过设置缓存参数信令向服务器请求调整发流速度，发流速度调整方案为：

(1)本地缓存下溢：请求增大发流速度；

(2)本地缓存上溢：请求减小发送速度；

(3)报文丢包率上升：如果当前处于加速发流，应向服务器请求取消加速发流；如当前速率正常，且缓存数据较多，则可向服务器请求以慢速发流。

在上述方法中，在步骤S52中，发流速率调整时间＝缓存大小的上溢门限/(码率×请求速率)；

在发流速率调整时间内以码率与请求速率之积作为发流速度，向终端发送流媒体数据以及重传RTP报文。

本发明还提供了一种流媒体传输优化装置，包括流媒体服务器和终端；

所述流媒体服务器包括主控模块、RTSP服务器以及媒体数据发送模块；

所述终端包括RTSP客户机、缓存管理模块以及数据接收和处理模块；

所述RTSP客户机发送申明支持丢包重传的播放任务请求，所述RTSP服务器回应该请求，完成终端与流媒体服务器之间支持丢包重传的初始化；所述主控模块根据播放任务请求控制所述媒体数据发送模块开始以RTP报文向所述数据接收和处理模块发送流媒体数据；

所述数据接收和处理模块检测接收的RTP报文，并经通过丢包监测窗口聚合一组丢失RTP报文的序号后，通过所述RTSP客户机向所述流媒体服务器发起该组丢失RTP报文的重传请求；

所述RTSP服务器处理丢失RTP报文的重传请求，并发给所述主控模块；所述主控模块根据重传请求控制所述媒体数据发送模块通过原流媒体数据传输通道向终端重传相应RTP报文；所述数据接收和处理模块将收到重传RTP报文插入到对应位置；

所述缓存管理模块，用于管理所述终端本地缓存、监测缓存水平；

如果本地缓存发生上溢或下溢，通过所述RTSP客户机向所述流媒体服务器发送流速调整请求。

本发明采用丢包重传技术，使IPTV终端在网络质量不好的情况下，可以有效地提高流媒体播放质量；并通过采用流速控制技术有效地提高了点播、时移节目开始播放的速度，使非面向连接的传输具有简单的拥塞避免机制，使终端有了本地缓存数据的能力，对于各种网络异常(抖动、瞬断、以及其它不稳定情况)有了不错的容错效果；且丢包重传在流量控制技术的支持下，也有简单的拥塞避免机制，避免丢包重传给正常的流媒体数据传输带来影响，不仅保证流媒体传输实时性，而且提高了流媒体的传输质量，增加了终端设备的媒体缓存能力，使IPTV播放的音画质量以及流畅性得到提高，提升了IPTV服务的整体性能。

附图说明

图1为本发明提供一种流媒体传输优化方法的流程图；

图2为本发明中步骤S20的具体流程图；

图3为本发明中步骤S40的具体流程图；

图4为本发明中步骤S51的具体流程图；

图5为本发明提供一种流媒体传输优化装置的结构示意图。

具体实施方式

本发明通过丢包重传和流量控制技术相结合，解决了IPTV网络数据传输实时性与可靠性同时兼顾的问题。其中，丢包重传技术，使IPTV终端在网络质量不好的情况下，可以有效地提高流媒体播放质量；并与流量控制技术结合，使非面向连接的传输也有简单的拥塞避免机制，不仅保证流媒体传输实时性，而且提高了流媒体的传输质量，增加了终端设备的媒体缓存能力，使IPTV播放的音画质量以及流畅性得到提高，提升了IPTV服务的整体性能。以下为本发明涉及的名词解释：

IPTV：交互式网络电视,是通过IP承载网络向用户提供能够支持交互能力的电视节目的直播、点播和时移播放等业务的总称。

RTSP：实时流传输协议，是一种控制实时流传输的应用级协议，控制流媒体数据的传输,此协议主要应用于IPTV系统，目前IPTV网络中的媒体服务器基本上都是基于RTSP协议的媒体服务器。

下面结合说明书附图和具体实施例对本发明做出详细的说明。

本发明的适用场景为：具有IPTV播放能力的设备(机顶盒、电视等)作为流媒体播放的终端，向IPTV系统内的流媒体服务器发起播放请求；流媒体服务器基于RTSP信令进行控制,并使用UDP承载RTP报文的方式向终端传输流媒体数据。而基于UDP不可靠连接的数据传输，会发生丢包，可靠性低，本发明提供的一种流媒体传输优化方法，有效的解决了这一问题，如图1所示，包括以下步骤：

步骤S10、终端与流媒体服务器之间进行支持丢包重传的初始化后，流媒体服务器开始以RTP报文向终端发送流媒体数据。

步骤S20、终端将检测丢失RTP报文，并通过丢包监测窗口聚合一组丢失RTP报文的序号后，通过RTSP信令向媒体服务器发起该组丢失RTP报文的重传请求。

步骤S30、流媒体服务器根据重传请求RTSP信令，通过原流媒体数据传输通道向终端重传相应RTP报文，本发明采用带外的丢包重传机制，并不在RTSP信令传输通道内传送流媒体数据。

步骤S40、终端将收到重传RTP报文插入到对应位置，即终端正常接收流媒体数据的缓存区，由于重传RTP报文不是顺序上传，需要插入到丢失前的原位置，以保证媒体流数据的正确性。

步骤S50、终端实时监测缓存状态，控制流媒体服务器流媒体数据以及重传RTP报文发流速率，调整其缓存区，例如报文丢包率上升，说明流媒体数据的发流速率过快，对其进行降速调整；如果当前重传RTP报文发流速率造成终端本地缓存上溢，则需要对重传RTP报文发流速率进行降速调整。

在本发明中，步骤S10包括以下步骤：

步骤S11、终端收到应用发来的基于RTSP协议的流媒体播放任务，向流媒体服务器的RTSP服务器发起描述播放任务请求，并在描述播放任务请求信令中申明丢包重传能力；

步骤S12、RTSP服务器回应描述播放任务请求，并表示支持“丢包重传”功能；

步骤S13、媒体服务器获取描述播放任务请求信令(RTSP信令)中携带的终端流媒体接收地址，并以RTP报文方式开始向终端发送流媒体数据。

如图2所示，在本发明中，步骤S20包括以下步骤：

步骤S21、终端在接收流媒体数据时，根据RTP报文序号检测RTP报文丢失，将检测到的丢失RTP报文序号记录到丢包监测窗口，丢包数加1；

在本发明中，如果延时收到之前已经认为丢失的RTP报文，则将该RTP报文序号从丢包监测窗口中删除；

步骤S22、判断丢包监测窗口的丢包数是否为1(此轮监测到的当前丢包数为1)；如是，转步骤S23；否则，转步骤S24；

步骤S23、启动丢包监测计时器，执行步骤S21；

步骤S24、判断丢包监测窗口中丢包数是否达到预设值(考虑到带宽占用和流媒体服务器的处理压力，终端不会发现一次丢包就发起一次重传请求，而是进行一定的聚合，预设值为设定的一次聚合重传的最大丢包数，预设值大于等于1)，如是，转步骤S26；否则，转步骤S25；

步骤S25、判断丢包监测计时器是否超时，如果超时，转步骤S26；否则，转步骤S21；

步骤S26、取消丢包监测计时器，转步骤S27；

步骤S27、终端把丢包监测窗口中所有丢包RTP报文记录转移到重传等待队列中，并向流媒体服务器发起丢包重传请求，丢包重传请求信令(RTSP信令)携带所有丢包监测窗口中丢包RTP报文的序号。

在步骤S27中，在终端把丢包监测窗口中所有丢包RTP报文记录转移到重传等待队列中时，清空丢包监测窗口丢包RTP报文序号记录及记数，准备开始下一轮丢包监测，并针对重传等待队列中的每个丢包RTP报文将记录开启重传等待循环计时器，定时清理丢包重传队列中等待重传、但是超出预期重传等待时间(对应的重传等待循环计时器超时)的丢包RTP报文记录，超时没收到重传的丢包RTP报文，视为丢包，但不影响播放的实时性，由丢包引起的质量问题会交由播放器来进行二次优化。

在步骤S30中，流媒体服务器根据重传请求RTSP信令携带的丢包RTP报文序号依次进行重传，流媒体服务器对丢包重传有抑制机制，对于丢包率、重传请求次数和频率都可做出限制。

如图3所示，步骤S40具体包括以下步骤：

步骤S41、当收到新的RTP报文时，判断是否是有效的重传RTP报文(判断依据为一直缺失，且没有超出预期重传等待时间)，如是，转步骤S42；否则，转步骤S43；

步骤S42、将收到的重传RTP报文根据其报文序号插入到终端接收流媒体数据的缓存区的相应位置(丢失前的原位置)，并从重传等待队列中删除对应的丢包RTP报文记录，转步骤S44；

步骤S43、此报文已过期，丢弃；

步骤S44、判断重传等待队列中是否还有丢包RTP报文记录(播放被终止同样视为接收完毕)，如果是，转步骤S41；否则，结束程序。

本发明基于RTSP协议，还扩展了一种流量控制技术，通过终端控制流媒体服务器发流速率(流量)，对缓存区调整，达到避免拥塞的目的，包括以下步骤：

步骤S51、终端实时监测缓存状态，如超过了缓存上溢或下溢的预警线，则向流媒体服务器发出携带指定的发流速度和需要调整的缓存大小信息的发流速率调整请求指令。

步骤S52、流媒体服务器根据终端的请求，基于指定的发流速度和终端需要调整的缓存大小信息确定发流速率调整的时间，进行流媒体数据以及重传RTP报文的发流速率调整。

在步骤S52中，流媒体服务器收到携带发流速率调整参数的播放请求，计算发流速率调整时间，发流速率调整时间＝缓存大小的上溢门限/(码率*请求速率)，然后在发流速率调整时间内以码率与请求速率之积作为发流速度，向终端发送数据报文。

在本发明中，如图4所示，步骤S51包括以下步骤：

步骤S511、终端收到应用发来的基于RTSP协议的流媒体播放任务，向RTSP服务器发起描述请求，并在描述请求信令中申明流量控制功能的支持能力；

步骤S512、RTSP服务器回应描述请求，表示支持“流量控制”功能；

步骤S513、终端与RTSP服务器之间完成流量控制初始化，发出播放信令，播放信令携带初始发流速度和本地缓存大小的上溢门限，为了达到快速开始播放的目的，一般初始发流速度会设置为大于1倍速；而缓存大小的上溢门限建议为总缓存大小的百分之六十至八十；

步骤S514、终端接收到流媒体数据以及重传RTP报文，存放到缓冲区；

步骤S515、如果终端检测到RTP报文的丢包率明显提升或下降，或者本地缓存出现上溢或下溢，终端通过设置缓存参数信令向服务器请求调整发流速度，发流速度调整有以下三种情况：

(1)本地缓存下溢：请求增大发流速度；

(2)本地缓存上溢：请求减小发送速度；

(3)报文丢包率上升：如果当前处于加速发流，应向服务器请求取消加速发流；如当前速率正常，且缓存数据较多，则可向服务器请求以慢速发流。

在本发明中，发流速率调整后，终端实时监测丢包重传的状态，如丢包较为明显，应取消加速发流，且视缓存的情况决定是否减速发流，避免流速调控影响到传输质量，从而提高网络适应性。

如图5所示，本发明还提供了一种流媒体传输优化装置，包括IPTV系统中媒体平台层的流媒体服务子系统和终端层的终端20。

流媒体服务子系统是为用户直接提供流服务的子系统，本发明中称为流媒体服务器10，包括主控模块11、RTSP服务器12以及媒体数据发送模块13；

终端20包括RTSP客户机21、数据接收和处理模块22以及缓存管理模块23；

RTSP客户机21发送申明支持丢包重传的播放任务请求，RTSP服务器12回应该请求，完成终端20与流媒体服务器10之间支持丢包重传的初始化；

主控模块11根据播放任务请求控制媒体数据发送模块13开始以RTP报文向数据接收和处理模块22发送流媒体数据；

数据接收和处理模块22检测接收的RTP报文，并经通过丢包监测窗口聚合一组丢失RTP报文的序号后，通过RTSP客户机21向流媒体服务器10发起该组丢失RTP报文的重传请求；

RTSP服务器12处理丢失RTP报文的重传请求，并发给主控模块11；主控模块11根据重传请求控制媒体数据发送模块13通过原流媒体数据传输通道向终端重传相应RTP报文；

数据接收和处理模块22将收到重传RTP报文插入到对应位置。

缓存管理模块23用于管理终端本地缓存，监测缓存水平，如果本地缓存发生上溢或下溢，通过RTSP客户机21向流媒体服务器10发送流速调整请求。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (9)

1.一种流媒体传输优化方法，其特征在于，包括以下步骤：

步骤S10、终端与流媒体服务器之间进行支持丢包重传的初始化后，流媒体服务器开始以RTP报文向终端发送流媒体数据；

步骤S20、终端将检测丢失RTP报文，并经丢包监测窗口聚合一组丢失RTP报文的序号后，通过RTSP信令向媒体服务器发起该组丢失RTP报文的重传请求；

步骤S30、流媒体服务器根据重传请求RTSP信令，通过原流媒体数据传输通道向终端重传相应RTP报文；

步骤S40、终端将收到重传RTP报文插入到对应位置；

步骤S50、终端实时监测缓存状态，控制流媒体服务器的流媒体数据以及重传RTP报文发流速率，调整其缓存区。

2.如权利要求1所述的方法，其特征在于，步骤S10包括以下步骤：

步骤S11、终端收到应用发来的基于RTSP协议的流媒体播放任务，向流媒体服务器的RTSP服务器发起描述播放任务请求，并在描述播放任务请求信令中申明丢包重传能力；

步骤S12、RTSP服务器回应描述播放任务请求，并表示支持“丢包重传”功能；

步骤S13、媒体服务器获取描述播放任务请求信令中携带的终端流媒体接收地址，并以RTP报文方式开始向终端发送流媒体数据。

3.如权利要求2所述的方法，其特征在于，步骤S20包括以下步骤：

步骤S21、终端在接收流媒体数据时，根据RTP报文序号检测RTP报文丢失，将检测到的丢失RTP报文序号记录到丢包监测窗口，丢包数加1；

步骤S22、判断丢包监测窗口的丢包数是否为1；如是，转步骤S23；否则，转步骤S24；

步骤S23、启动丢包监测计时器，执行步骤S21；

步骤S24、判断丢包监测窗口中丢包数是否达到预设值，如是，转步骤S26；否则，转步骤S25；

步骤S25、判断丢包监测计时器是否超时，如果超时，转步骤S26；否则，转步骤S21；

步骤S26、取消丢包监测计时器，转步骤S27；

步骤S27、终端把丢包监测窗口中所有丢包RTP报文记录转移到重传等待队列中，并向流媒体服务器发起丢包重传请求，丢包重传请求信令携带所有丢包监测窗口中丢包RTP报文的序号。

4.如权利要求3所述的方法，其特征在于，在步骤S27中，在终端把丢包监测窗口中所有丢包RTP报文记录转移到重传等待队列中时，清空丢包监测窗口丢包RTP报文序号记录及记数，准备开始下一轮丢包监测，并针对重传等待队列中的每个丢包RTP报文将记录开启重传等待循环计时器，定时清理丢包重传队列中等待重传、但是对应的重传等待循环计时器超时的丢包RTP报文记录。

5.如权利要求3所述的方法，其特征在于，步骤S40具体包括以下步骤：

步骤S41、当收到新的RTP报文时，判断是否是有效的重传RTP报文，如是，转步骤S42；否则，转步骤S43；

步骤S42、将收到的重传RTP报文根据其报文序号插入到终端接收流媒体数据的缓存区的相应位置，并从重传等待队列中删除对应的丢包RTP报文记录，转步骤S44；

步骤S43、此报文已过期，丢弃；

步骤S44、判断重传等待队列中是否还有丢包RTP报文记录，如果是，转步骤S41；否则，结束程序。

6.如权利要求1所述的方法，其特征在于，步骤S50包括以下步骤：

步骤S51、终端实时监测缓存状态，如超过了缓存上溢或下溢的预警线，则向流媒体服务器发出携带指定的发流速度和需要调整的缓存大小信息的发流速率调整请求指令；

步骤S52、流媒体服务器根据终端的请求，基于指定的发流速度和终端需要调整的缓存大小信息确定发流速率调整的时间，进行流媒体数据以及重传RTP报文的发流速率调整。

7.如权利要求6所述的方法，其特征在于，步骤S51包括以下步骤：

步骤S511、终端收到应用发来的基于RTSP协议的流媒体播放任务，向RTSP服务器发起描述请求，并在描述请求信令中申明流量控制功能的支持能力；

步骤S512、RTSP服务器回应描述请求，表示支持“流量控制”功能；

步骤S513、终端与RTSP服务器之间完成流量控制初始化，发出播放信令，播放信令携带初始发流速度和本地缓存大小的上溢门限；

步骤S514、终端接收到流媒体数据以及重传RTP报文，存放到缓冲区；

步骤S515、如果终端检测到RTP报文的丢包率明显提升或下降，或者本地缓存出现上溢或下溢，终端通过设置缓存参数信令向服务器请求调整发流速度，发流速度调整方案为：

(1)本地缓存下溢：请求增大发流速度；

(2)本地缓存上溢：请求减小发送速度；

(3)报文丢包率上升：如果当前处于加速发流，应向服务器请求取消加速发流；如当前速率正常，且缓存数据较多，则可向服务器请求以慢速发流。

8.如权利要求6所述的方法，其特征在于，在步骤S52中，发流速率调整时间＝缓存大小的上溢门限/(码率×请求速率)；

在发流速率调整时间内以码率与请求速率之积作为发流速度，向终端发送流媒体数据以及重传RTP报文。

9.一种流媒体传输优化装置，包括流媒体服务器和终端；其特征在于，

所述流媒体服务器包括主控模块、RTSP服务器以及媒体数据发送模块；

所述终端包括RTSP客户机、缓存管理模块以及数据接收和处理模块；

所述RTSP客户机发送申明支持丢包重传的播放任务请求，所述RTSP服务器回应该请求，完成终端与流媒体服务器之间支持丢包重传的初始化；所述主控模块根据播放任务请求控制所述媒体数据发送模块开始以RTP报文向所述数据接收和处理模块发送流媒体数据；

所述数据接收和处理模块检测接收的RTP报文，并经通过丢包监测窗口聚合一组丢失RTP报文的序号后，通过所述RTSP客户机向所述流媒体服务器发起该组丢失RTP报文的重传请求；

所述RTSP服务器处理丢失RTP报文的重传请求，并发给所述主控模块；所述主控模块根据重传请求控制所述媒体数据发送模块通过原流媒体数据传输通道向终端重传相应RTP报文；所述数据接收和处理模块将收到重传RTP报文插入到对应位置；

所述缓存管理模块，用于管理所述终端本地缓存、监测缓存水平；

如果本地缓存发生上溢或下溢，通过所述RTSP客户机向所述流媒体服务器发送流速调整请求。