CN102595251B - 流媒体丢包重传实现方法和系统 - Google Patents

Abstract

本发明涉及一种流媒体丢包重传实现方法和系统，该方法包括：发送端采用与媒体码流相同的传输方式发送重传配置信息，所述重传配置信息包括反馈规范标识及重传规范标识；接收端接收并配置所述重传配置信息；所述接收端检测到丢包时，按照缓存的重传配置信息构造并发送丢包反馈消息；所述发送端接收所述丢包反馈消息后，根据所述重传配置信息构造重传包并发送；所述接收端根据缓存的重传配置信息接收所述重传包。本发明流媒体丢包重传实现方法和系统可以提高流媒体传输可靠性。

Description

流媒体丢包重传实现方法和系统

技术领域

本发明涉及流媒体技术领域，更具体地，涉及一种流媒体应用中，流媒体丢包重传实现的方法和系统。

背景技术

随着宽带网的普及和多媒体技术的发展，流媒体技术的应用也越来越广泛，如数字广播业务、IPTV(交互式网络电视)业务、移动流媒体业务等。这些业务的共同特点，都是将多媒体数据按一定规则封装打包后，通过底层的通信网络，进行数据的分发。例如IPTV应用中，使用TSoverRTP(TransportStreamoverReal-timeTransportProtocol，传输流承载在实时传输协议上)或者TSoverUDP(TransportStreamoverUserDatagramProtocol，传输流承载在用户数据报协议上)的方式，通过IP网络进行分发。数字广播领域，更是将TS(TransportStream，传输流)直接承载在链路层上进行数据的分发。由于底层网络的传输不可靠性，将不可避免的存在数据包发生误码、丢失等情况。此时，可以通过接收端提出丢包重传的反馈请求，发送端将丢失或错误的数据包重新发送给接收端，来解决这个问题。

要做丢包重传，就需要接收端能够向发送端反馈所丢失的数据包信息，同时也需要能从发送端发送的码流中识别出正常的码流和重传的码流。而MPEG-2(MovingPicturesExpertsGroup，运动图像专家组)TS规范最初设计出来，只是用于数据广播领域，缺乏这种丢包信令的通知和反馈机制。

目前常见的做法，是通过将TS(TransportStream，传输流)承载在RTP(Real-timeTransportprotocol，实时传输协议)上，然后通过RTSP(Real-timeStreamingProtocol，实时流协议)/RTP的架构，以带外的方式提供丢包重传的信令通知和反馈。即首先通过SDP的方式，通知接收端，系统支持的重传规范，包括丢包反馈的方式、重传码流的传输通道和格式等。接收端检测到数据包丢失后，则通过RTCP(Real-timeTransportControlProtocol，实时传送控制协议)或RTSP的方式，向发送端反馈。

但是在某些情况下，接收端可能缺少这种通过SDP等带外方式获取重传规范等信息的手段。例如目前很多IPTV应用中，对于直播频道，接收端通常只能获取到对应于频道码流的一个组播地址和端口。由于TS的PSI(ProgramSpecificInformation，节目特定信息)中包含有内部各个媒体流的详细信息，例如媒体流类型、编码格式、标识等信息，而且TS流承载在RTP上的PT(PayloadType，RTP包头中的PT字段，用于标识负载类型)值也是确定的，所以无论是TSoverUDP还是TSoverRTP，这种方式接收端都可以正常接收码流并解码播放。没有RTSP链接，没有SDP，则上述的重传规范等信息，接收端都无从获取。而且，当该信息有变化时，也无法及时通知接收端。另外，依靠RTSP/RTCP的方式，反馈丢包信息，也存在需要维护多个链接的问题，在有NAT防火墙时，问题也比较多，处理比较复杂。

发明内容

本发明要解决的技术问题是提供一种流媒体丢包重传实现方法和系统，以提高流媒体传输可靠性。

为解决以上技术问题，本发明提供了一种流媒体丢包重传实现方法，该方法包括：

发送端采用与媒体码流相同的传输方式发送重传配置信息，所述重传配置信息包括反馈规范标识及重传规范标识；

接收端接收并配置所述重传配置信息；

所述接收端检测到丢包时，按照缓存的重传配置信息构造并发送丢包反馈消息；

所述发送端接收所述丢包反馈消息后，根据所述重传配置信息构造重传包并发送；

所述接收端根据缓存的重传配置信息接收所述重传包。

进一步地，所述重传配置信息还包括重传流标识或服务器支持的重传窗口大小。

进一步地，发送端周期性发送所述重传配置信息。

进一步地，所述重传配置信息有修改时，所述发送端发送更新后的重传配置信息，所述发送端和接收端根据所述更新后的重传配置信息分别构造丢包反馈消息和重传包。

进一步地，所述重传配置信息基于扩展的运动图像专家组(MPEG)协议或扩展的实时传输协议(RTP)发送。

为解决以上技术问题，本发明还提供了一种流媒体丢包重传实现系统，该系统包括发送端和接收端，其中，所述发送端包括：

收发模块，用于采用与媒体码流相同的传输方式发送重传配置信息，接收丢包反馈消息，以及发送重传包，其中所述重传配置信息包括反馈规范标识及重传规范标识；

重传处理模块，用于在接收所述丢包反馈消息后，根据所述重传配置信息构造所述重传包；

所述接收端包括：

收发模块，用于接收并配置所述重传配置信息，发送所述丢包反馈消息，以及根据缓存的重传配置信息接收所述重传包；

丢包反馈消息构造模块，用于在检测到丢包时，按照缓存的重传配置信息构造所述丢包反馈消息。

本发明流媒体丢包重传实现方法和系统通过带内方式传递重传配置信息，这样只要接收端能够收到媒体码流，就可以获取到相应的重传配置信息，并可以方便的实现该信息的动态更新。

附图说明

图1是本发明流媒体丢包重传实现方法的示意图；

图2是利用RTP通道传输重传配置信息的码流示意图；

图3是用于传递重传配置信息的RTP扩展头结构；

图4是用于在RTP包中传递重传配置信息参数的数据结构；

图5是本发明流媒体丢包重传实现系统的模块结构示意图。

具体实施方式

本发明流媒体丢包重传实现方法和系统的基本思想，就是通过带内方式传递重传配置信息，这样只要接收端能够收到媒体码流，就可以获取到相应的重传配置信息，并可以方便的实现该信息的动态更新。

下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

如图1所示，本发明流媒体丢包重传实现方法包括：

步骤101：发送端采用与媒体码流相同的传输方式发送重传配置信息；

发送端将重传配置信息进行封装打包，采用与媒体码流相同的传输方式发送。重传配置信息可以通过在媒体数据包中增加相关字段携带，也可以通过定义新的数据包格式，然后复用媒体码流的传输通道的方式，随媒体码流发送。本方案对此不作限制。

其中重传配置信息包括但不限于如下信息：

重传规范标识——不同的重传规范可以有不同的重传包格式，以及重传包到原始包的映射规则。该参数是必选的，以便接收端可以正确的解析重传包。；

所遵循的反馈规范标识——不同的反馈规范，可以有不同的反馈消息格式和反馈机制。该参数是必须的，以便接收端正确地构造和发送丢包反馈消息；

重传流标识——如果缺少了该参数，接收端可以通过排除所有可以识别的码流，来识别出重传流，但是存在干扰码流的时候，可能会导致误判。所以优选地在重传配置信息中始终包含该参数，以便接收端能够明确识别出重传码流；

服务器支持的重传窗口大小——服务器对处于重传窗口内的数据包提供重传服务。优选地，接收端可以根据该参数判断，是否有必要发起丢包重传请求，以尽量减少无效的反馈消息的发送。当缺少该参数时，接收端可以根据自己的策略，以及接收端当前的网络状况和缓存播放状态等进行决策。

对于直播码流的情况，该重传配置信息可以周期性的发送，以保证新接入的接收端可以及时获取到相关信息。

当重传配置信息有修改更新时，发送端按照新的参数构造相关信息，然后按上述方式发送更新后的信息。

步骤102：接收端接收并配置所述重传配置信息；

接收端接收媒体码流的同时，也会接收到与媒体码流采用相同方式传送的重传配置信息，接收端解析该信息，并据此进行配置，具体指接收端在本地记录这些信息，可以保存在内存中，例如直接修改程序中相关对象实例的参数，也可以是记录在存储设备上，例如文件中。具体配置方式由接收端的具体实现决定。只要保证接收端后续能按照这里获取到的信息处理媒体码流即可。。

步骤103：所述接收端检测到丢包时，按照缓存的重传配置信息构造并发送丢包反馈消息；

如接收端接收到更新后的重传配置信息后，则更新缓存的重传配置信息，并按照更新后参数进行处理。

丢包反馈消息也称为自动重传请求消息。

步骤104：所述发送端接收所述丢包反馈消息后，根据所述重传配置信息构造重传包并发送；

服务器收到接收端的丢包反馈后，从历史缓存中获取指定的媒体包，按重传配置信息中指定的方式，构造重传包，发送给接收端。

步骤105：所述接收端根据缓存的重传配置信息接收所述重传包。

所述重传配置信息有修改时，所述发送端发送更新后的重传配置信息，所述发送端和接收端根据所述更新后的重传配置信息分别构造丢包反馈消息和重传包。

所述重传配置信息可以基于扩展的运动图像专家组(MPEG)协议或扩展的实时传输协议(RTP)发送。

以下就这两种协议的扩展分别给出具体实施例：

实施例1

本实施例在MPEG-2TS基础上，实现带内方式传递重传配置信息。例如，采用如下的技术方案对MPEG-2TS作扩展：

1、在PMT(ProgramMapTable，节目映射表)中增加一个节目级别的arq_signal_descriptor，定义如下：

注：表中的uimsbf表示无符号整数(Unsignedinteger，mostsignificantbitfirst，具体参见ISO/IEC13818-1标准中的相关定义)，以下同。

定义descriptor_tag＝129，表明该descriptor为arq_signal_descriptor。其他各字段的含义如下：

descriptor_length——表明该arq_signal_descriptor的长度，参见ISO/IEC13818-1标准中的相关定义；

arq_profile_identifier——表明所采用的重传规范，例如当为ASCII字符“ZARQ”时，表明重传包的格式、传送方式等，具体参见后续“重传包格式”一节的相关内容；

fb_profile_identifier——表明所采用的反馈规范，例如当为ASCII字符“AFBP”时，表明反馈消息的格式和反馈方式等，具体参见后续“丢包反馈消息的格式”一节的相关内容；

rtx_window——表明服务器所支持的重传窗口的大小，为一个32位数，以毫秒为单位。

2、在本实施例中，重传数据包作为单独的ES(ElementaryStream，基本码流)流传送，单独分配PID，以便与反馈包和媒体包区分。所以需要增加一个stream_type类型，用于标识重传流，例如stream_type值为0xFD时，表示相应的PID流是用于传送重传包的；

3、在PMT中增加ES级别的arq_label_descriptor，用于给ES流添加一个重传标签，这样可以标识媒体码流与重传码流的对应关系。标签值相同的媒体流对应于同一个重传流。定义如下：

其中descriptor_tag＝129，表明该descriptor为arq_label_descriptor。其他各字段的含义如下：

label——标签值，具有同样标签值的媒体流的数据包，在重传时，使用具有同样标签值的重传流。

当该arq_label_descriptor()在所有ES流中都不存在，且PMT中stream_type为0xFD的PID流只有一个时，表明所有媒体PID的重传包都通过这个唯一的重传PID流传送。

重传包的格式：

重传包中需要包含原始媒体包的相关信息，以便接收端将重传包和原始包对应起来。例如可以作如下定义：

注：表中的bslbf表示比特串(Bitstring，leftbitfirst，具体参见ISO/IEC13818-1标准中的相关定义)。rpchof表示余数多项式的系数(Remainderpolynomialcoefficients，highestorderfirst，具体参见ISO/IEC13818-1标准中的相关定义)。以下同。

其中各字段的含义如下：

table_id——用于标识该section类型为arq_packet_section，取值为0xF1；section_syntax_indicator——取值为0，含义参见MPEG-2TS标准《ISO/IEC13818-1：2007》中，关于privatesection的相关定义；

private_indicator——根据ISO/IEC13818-1标准中的相关定义，该字段取默认值0；

private_section_length——表示arq_packet_section中，在private_section_length字段之后的数据长度；

rtx_packet_number——表示该arq_packet_section中包含的重传包数目；

orig_pid——表示相应的源TS包的PID；

orig_packet_id——表示相应的源TS包的标识，参见丢包反馈消息中的相关说明；

orig_packet_length——表示相应的源TS包的长度，该字段后，即为重传的源TS包数据；

CRC32——用于对数据提供校验的，参见MPEG-2TS标准(即ISO/IEC13818-1)中的相关定义。

丢包反馈消息的格式：

当arq_signal_descriptor()中的fec_profile_identifier为ASCII字符“ZFBP”时，丢包反馈的消息格式定义如下：

其中message_type的值为0x01时，为丢包反馈消息arq_fb_message()，其定义如下：

其中各字段的含义如下：

packet_id——表示丢失的第一个TS包的标识，该标识需要保证在一定时间范围内对同一个PID流中的TS包唯一，且顺序递增。由于TS包的CC字段回绕太快，除非对其作扩展，否则不适合在丢包反馈时，用其作标识。这样可能需要服务器在原始TS包中，额外添加一个标识字段，例如可以利用TS的private_data字段来添加标识；

mask_length——用于指明后面掩码字段的长度，以字节为单位；

mask_byte——掩码字段，每一位对应一个TS包。即从packet_id标识的数据包开始，后续掩码范围内的数据包，如果发生了丢失，则将掩码中对应的比特位置1；

对于支持上述MPEG-2TS扩展的流媒体系统来说，其发送端(比如流媒体服务器)和接收端(比如终端)的处理流程如下：

发送端

(1)根据上述对MPEG-2TS的扩展，在PMT中增加相关的重传配置信息并发送；

PMT发送的相关规定，例如发送频率、更新等，可以遵循MPEG-2TS的相关规定。由于重传信令会随着PMT一起周期发送，从而可以保证新接入接收端可以及时获取相关信息。同样也可以保证重传信令发生变化时的更新；

(2)收到接收端反馈的丢包信息后，从历史缓存中获取对应的原始TS包，按规定进行封装打包后，复用到TS流中发送。

接收端

(1)接收TS码流，解析其中的PMT，从中获取媒体码流的相关信息，和重传配置信息；

(2)当检测到媒体码流发生丢包时，按指定反馈规范，构造丢包反馈消息发送；

(3)根据PMT，从TS流中解复用，得到媒体包和重传包，作码流修复。

实施例2

本实施例通过RTP/RTCP传递重传信令，实现带内方式传递重传配置信息。

当码流通过RTP流传输时(例如TSoverRTP)，可以将相关的重传配置信息封装在RTP/RTCP包中，通过RTP/RTCP通道进行传输。图2给出了利用RTP通道传送重传配置信息的示意。重传的RTP包可以作为一路RTP流，复用媒体码流的RTP通道，或者使用新的RTP通道进行传输。

例如，当使用RTP通道传送重传配置信息时，可以采用如下的技术方案，对RTP作扩展：

(1)分配一个专门的PT值，例如126，用于标识相应的RTP流是用于传递重传配置信息的。这样用于传递重传配置信息的RTP包，就可以有自己独立的序号空间，避免对正常的RTP码流造成干扰；

(2)定义一个RTP扩展头，用于标识传递重传配置信息的RTP包格式遵循哪个规范。仅在PT值等于126时有效。扩展头定义如图3所示，遵循RFC3550的相关定义。可以设定definedbyprofile字段为一个特殊值，例如ASCII字符“RT”，以标明相应的RTP负载，是用于传递重传配置信息的。扩展头中的Identifier字段的不同取值，表明相应的规范，不同的规范可能对应不同的RTP包格式定义。例如Identifier取值为ASCII字符“ZARQ”时，则表明后面跟的RTP负载中，所携带的重传配置信息的格式遵循本实施例中的相关规定；

(3)定义重传配置信息相关参数在RTP包中的格式。由于重传配置信息中的部分参数可能是可选的，为便于构造消息，可以对信令中的参数采用Type-Length-Value(TLV)的结构。即基本结构如图4所示。首先通过Type字段标明不同的参数类型，然后通过Length字段标明该参数值的长度，然后在Value字段携带具体的参数值。如果有多个参数，则RTP负载中就是相应的多个TLV结构。需要支持的重传信令参数如下所示：

对于支持上述RTP扩展的流媒体系统来说，其发送端和接收端的处理流程如下：

发送端

(1)根据上述对RTP的扩展，将重传配置信息封装到RTP包中；

(2)使用媒体包的RTP通道，发送携带了重传配置信息的RTP包；

携带了重传配置信息的RTP包可以周期发送；当重传配置信息发生变化时，则根据变化后的重传配置信息，构造RTP格式的消息包，然后按上述规则发送。

(3)收到接收端反馈的丢包信息后，从历史缓存中获取对应的原始RTP包，按规定进行封装打包后，复用RTP通道发送，或通过RTCP通道发送。

接收端

(1)接收RTP包，解复用出携带重传配置信息的RTP包；

(2)当检测到媒体RTP流发生丢包时，按照重传配置信息中指定的方式，发送丢包反馈消息；

(3)从RTP流中解复用，得到重传包，修复码流。

对应于以上方法，本发明还提供了一种流媒体丢包重传实现系统，如图5所示，该系统包括发送端和接收端，其中：

所述发送端包括：

收发模块，用于采用与媒体码流相同的传输方式发送重传配置信息，接收丢包反馈消息，以及发送重传包；

重传处理模块，用于在接收所述丢包反馈消息后，根据所述重传配置信息构造重传包；

所述接收端包括：

收发模块，用于接收并配置所述重传配置信息，检测丢包，发送所述丢包反馈消息，以及根据缓存的重传配置信息接收所述重传包；

丢包反馈消息构造模块，用于在检测到丢包时，按照缓存的重传配置信息构造所述丢包反馈消息。

进一步地，所述重传配置信息包括反馈规范标识及重传规范标识。优选地，所述重传配置信息还包括重传流标识或服务器支持的重传窗口大小。

进一步地，发送端可以周期性发送所述重传配置信息。

所述重传配置信息有修改时，所述发送端的收发模块发送更新后的重传配置信息，所述接收端的丢包反馈消息构造模块和发送端的重传处理模块根据所述更新后的重传配置信息分别构造丢包反馈消息和重传包。

所述重传配置信息基于如前文所述的扩展的运动图像专家组(MPEG)协议或扩展的实时传输协议(RTP)发送。

可理解的，以上系统中所提及的功能模块是本发明区别于现有技术的相关内容，本技术方案中，发送端和接收端并不排除有新的或现有的功能模块。

采用本发明的技术方案，可以使用户在接收媒体码流的同时，方便地获取到相关的重传配置信息。从而顺利地实现丢包反馈和重传包的接收修复。同时，当重传配置信息有所更改时，服务器也可以及时地通知接收端，作出相应的调整。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。

Claims (10)

1.一种流媒体丢包重传实现方法，其特征在于，该方法包括：

发送端采用与媒体码流相同的传输方式发送重传配置信息，所述重传配置信息包括反馈规范标识fb_profile_identifier及重传规范标识arq_profile_identifier；

接收端接收并配置所述重传配置信息；

所述接收端检测到丢包时，按照缓存的重传配置信息构造并发送丢包反馈消息；

所述发送端接收所述丢包反馈消息后，根据所述重传配置信息构造重传包并发送；

所述接收端根据缓存的重传配置信息接收所述重传包。

2.如权利要求1所述的方法，其特征在于：所述重传配置信息还包括重传流标识或服务器支持的重传窗口大小。

3.如权利要求1所述的方法，其特征在于：发送端周期性发送所述重传配置信息。

4.如权利要求1所述的方法，其特征在于：所述重传配置信息有修改时，所述发送端发送更新后的重传配置信息，所述发送端和接收端根据所述更新后的重传配置信息分别构造丢包反馈消息和重传包。

5.如权利要求1所述的方法，其特征在于：所述重传配置信息基于扩展的运动图像专家组(MPEG)协议或扩展的实时传输协议(RTP)发送。

6.一种流媒体丢包重传实现系统，其特征在于，该系统包括发送端和接收端，其中，所述发送端包括：

收发模块，用于采用与媒体码流相同的传输方式发送重传配置信息，接收丢包反馈消息，以及发送重传包，其中所述重传配置信息包括反馈规范标识fb_profile_identifier及重传规范标识arq_profile_identifier；

重传处理模块，用于在接收所述丢包反馈消息后，根据所述重传配置信息构造所述重传包；

所述接收端包括：

收发模块，用于接收并配置所述重传配置信息，发送所述丢包反馈消息，以及根据缓存的重传配置信息接收所述重传包；

丢包反馈消息构造模块，用于在检测到丢包时，按照缓存的重传配置信息构造所述丢包反馈消息。

7.如权利要求6所述的系统，其特征在于：所述重传配置信息还包括重传流标识或服务器支持的重传窗口大小。

8.如权利要求6所述的系统，其特征在于：发送端周期性发送所述重传配置信息。

9.如权利要求6所述的系统，其特征在于：所述发送端的收发模块发送更新后的重传配置信息，所述接收端的丢包反馈消息构造模块和发送端的重传处理模块根据所述更新后的重传配置信息分别构造丢包反馈消息和重传包。

10.如权利要求6所述的系统，其特征在于：所述重传配置信息基于扩展的运动图像专家组(MPEG)协议或扩展的实时传输协议(RTP)发送。