CN103814582B - 视频业务数据传输方法和数据发送装置 - Google Patents

视频业务数据传输方法和数据发送装置 Download PDF

Info

Publication number
CN103814582B
CN103814582B CN201380002474.3A CN201380002474A CN103814582B CN 103814582 B CN103814582 B CN 103814582B CN 201380002474 A CN201380002474 A CN 201380002474A CN 103814582 B CN103814582 B CN 103814582B
Authority
CN
China
Prior art keywords
retransmission
video
video data
data bag
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201380002474.3A
Other languages
English (en)
Other versions
CN103814582A (zh
Inventor
严卫平
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
XFusion Digital Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN103814582A publication Critical patent/CN103814582A/zh
Application granted granted Critical
Publication of CN103814582B publication Critical patent/CN103814582B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/426Internal components of the client ; Characteristics thereof
    • H04N21/42607Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames

Abstract

本发明实施例提供了一种视频业务数据传输方法和数据发送装置,涉及数据传输领域,所述方法包括:接收视频数据包;判断如果将接收到的视频数据包放入接收缓冲区,是否会造成接收缓冲区溢出;当判断结果为将接收到的视频数据包放入接收缓冲区,会造成接收缓冲区溢出时,判断接收到的视频数据包的类型;若接收到的视频数据包的类型为不重要,则直接丢弃视频数据包;若接收到的视频数据包的类型为重要,则在接收缓冲区队列中找到离队尾最近的一个视频数据包的类型为不重要的视频数据包,将离队尾最近的一个视频数据包的类型为不重要的视频数据包丢弃,将接收到的视频数据包加入到接收缓冲区队列的队尾。从而保证了关键帧不会丢失。

Description

视频业务数据传输方法和数据发送装置
技术领域
本发明涉及数据传输领域,特别涉及一种视频业务数据传输方法和数据发送装置。
背景技术
随着移动终端和第三代移动通信技术(3rd-generation,简称“3G”)的普及,移动视频业务逐渐获得用户青睐。
在3G/通用移动通信系统(Universal Mobile Telecommunications System,简称“UMTS”)中,用户设备(User Equipment,简称“UE”)通过网络连接向视频服务器请求视频流服务,视频服务器接收到请求之后向UE传输视频流(视频数据包)。在视频流的传输过程中,无线网络控制器(Radio Network Controller,简称“RNC”)和UE执行无线部分的传输控制功能。以RNC为例,RNC将接收到的无线链路控制(Radio Link Control,简称“RLC”)协议数据单元(Protocol Data Unit,简称“PDU”)放入接收缓冲区中,然后将PDU组成服务数据单元(Service Data Unit,简称“SDU”)交给上层。
在实现本发明的过程中,发明人发现现有技术至少存在以下问题:
RLC层的接收缓冲区容量是有限的,不管是业务量太大超过了带宽,还是由于无线链路出错导致部分PDU重传,都可能引起该接收缓冲区溢出,导致视频数据包丢失,进而造成视频质量大幅下降。
发明内容
为了解决现有技术的问题,本发明实施例提供了一种视频业务数据传输方法和数据发送装置。所述技术方案如下:
为了解决现有技术中接收缓冲区溢出,导致视频数据包丢失,造成视频质量大幅下降问题,本发明实施例提供了一种视频业务数据传输方法、数据接收装置和数据发送装置。所述技术方案如下:
一方面,本发明实施例提供了一种视频业务数据接收装置,所述装置包括:
第一接收模块,用于接收视频数据包;
第一判断模块,用于判断如果将所述第一接收模块接收到的所述视频数据包放入接收缓冲区,是否会造成所述接收缓冲区溢出;
第一处理模块,用于当所述第一判断模块的判断结果为将所述视频数据包放入接收缓冲区,会造成所述接收缓冲区溢出时,判断所述视频数据包的类型,所述视频数据包的类型包括重要和不重要;
若所述第一接收模块接收到的所述视频数据包的类型为不重要,则直接丢弃第一接收模块接收到的所述视频数据包;若所述第一接收模块接收到的所述视频数据包的类型为重要,则在所述接收缓冲区队列中找到离队尾最近的一个视频数据包的类型为不重要的视频数据包,将所述离队尾最近的一个视频数据包的类型为不重要的视频数据包丢弃,将所述第一接收模块接收到的所述视频数据包加入到所述接收缓冲区队列的队尾。
在本发明实施例的一种实现方式中,所述第一处理模块包括:
判断单元,用于获取所述视频数据包中的头部信息,所述头部信息包括所述视频数据包的类型。
在本发明实施例的另一种实现方式中,所述视频数据包中还携带有数据包编号,所述装置还包括:
检测模块,用于周期性检测所述接收缓冲区中的视频数据包的编号是否连续;
第一处理模块,还用于根据所述检测模块的检测结果,向发送端发送重传请求报文,所述重传请求报文包括待重传视频数据包的标识。
在本发明实施例的另一种实现方式中,所述装置还包括:
计时模块,用于在发送所述重传请求报文时,设置重传计时器;
所述第一处理模块,还用于当所述重传计时器超时且未收到重传请求报文中的所有待重传视频数据包时,重新发送所述重传请求报文。
另一方面,本发明实施例还提供了一种视频业务数据发送装置,所述装置包括:
发送模块,用于发送发送缓冲区中的视频数据包,并将所述发送缓冲区中的视频数据包复制进重传缓冲区;
第二接收模块,用于获取接收端发送的重传请求报文,所述重传请求报文包括待重传视频数据包的标识;
第二判断模块,用于根据所述第二接收模块接收到的重传请求报文,判断待重传视频数据包的类型,所述待重传视频数据包的类型包括重要和不重要;
第二处理模块,用于根据所述第二判断模块判断的待重传视频数据包的类型,确定所述待重传视频数据包在超时阈值内的最大重传次数,所述类型为重要的待重传视频数据包的最大重传次数大于所述类型为不重要的待重传视频数据包的最大重传次数;确定所述待重传视频数据包在所述超时阈值内已重传次数;当所述待重传视频数据包的已重传次数小于所述最大重传次数时,向所述接收端发送所述待重传视频数据包;
所述第二处理模块,用于根据以下公式确定所述待重传视频数据包对应的最大重传次数:
其中,RmaxI为所述类型为重要的待重传视频数据包的最大重传次数,RmaxN为所述类型为不重要的待重传视频数据包的最大重传次数,Th为视频业务设置的超时阈值,RTT为视频数据包在发送端和所述接收端间的平均反馈确认周期。
在本发明实施例的另一种实现方式中,所述第二处理模块,用于将所述待重传视频数据包从所述重传缓冲区写入所述发送缓冲区队列的队首并发送。
在本发明实施例的另一种实现方式中,所述第二处理模块,还用于当所述待重传视频数据包的已重传次数等于所述最大重传次数时,从所述重传缓冲区中丢弃所述待重传视频数据包。
在本发明实施例的另一种实现方式中,所述重传请求报文中还包括确认接收到的视频数据包的标识,所述第二处理模块,还用于根据所述重传请求报文,将所述确认接收到的视频数据包从所述重传缓冲区中丢弃。
另一方面,本发明实施例还提供了一种视频业务数据传输方法,所述方法包括:
接收视频数据包;
判断如果将接收到的所述视频数据包放入接收缓冲区,是否会造成所述接收缓冲区溢出;
当判断结果为将接收到的所述视频数据包放入所述接收缓冲区,会造成所述接收缓冲区溢出时,判断接收到的所述视频数据包的类型,所述视频数据包的类型包括重要和不重要;
若接收到的所述视频数据包的类型为不重要,则直接丢弃接收到的所述视频数据包;若接收到的所述视频数据包的类型为重要,则在所述接收缓冲区队列中找到离队尾最近的一个视频数据包的类型为不重要的视频数据包,将所述离队尾最近的一个视频数据包的类型为不重要的视频数据包丢弃,将接收到的所述视频数据包加入到所述接收缓冲区队列的队尾。
在本发明实施例的一种实现方式中,所述判断接收到的所述视频数据包的类型,包括:
获取所述视频数据包中的头部信息,所述头部信息包括所述视频数据包的类型。
在本发明实施例的另一种实现方式中,所述视频数据包中还携带有数据包编号,所述方法还包括:
周期性检测所述接收缓冲区中的视频数据包的编号是否连续;
根据检测结果,向发送端发送重传请求报文,所述重传请求报文包括待重传视频数据包的标识。
在本发明实施例的另一种实现方式中,所述方法还包括:
在发送所述重传请求报文时,设置重传计时器;
当所述重传计时器超时且未收到所述重传请求报文中的所有待重传视频数据包时,重新发送所述重传请求报文。
另一方面,本发明实施例还提供了一种视频业务数据传输方法,所述方法包括:
发送发送缓冲区中的视频数据包,并将所述发送缓冲区中的视频数据包复制进重传缓冲区;
获取接收端发送的重传请求报文,所述重传请求报文包括待重传视频数据包的标识;
根据接收到的所述重传请求报文,判断待重传视频数据包的类型,所述待重传视频数据包的类型包括重要和不重要;
根据待重传视频数据包的类型,确定所述待重传视频数据包在超时阈值内的最大重传次数,所述类型为重要的待重传视频数据包的最大重传次数大于所述类型为不重要的待重传视频数据包的最大重传次数;
确定所述待重传视频数据包在所述超时阈值内已重传次数;
当所述待重传视频数据包的已重传次数小于所述最大重传次数时,向所述接收端发送所述待重传视频数据包;
所述根据待重传视频数据包的类型,确定所述待重传视频数据包在超时阈值内的最大重传次数,包括:
根据以下公式确定所述待重传视频数据包对应的最大重传次数:
其中,RmaxI为所述类型为重要的待重传视频数据包的最大重传次数,RmaxN为所述类型为不重要的待重传视频数据包的最大重传次数,Th为视频业务设置的超时阈值,RTT为视频数据包在发送端和所述接收端间的平均反馈确认周期。
在本发明实施例的另一种实现方式中,所述向所述接收端发送所述待重传视频数据包,包括:
将所述待重传视频数据包从所述重传缓冲区写入所述发送缓冲区队列的队首并发送。
在本发明实施例的另一种实现方式中,所述方法还包括:
当所述待重传视频数据包的已重传次数等于所述最大重传次数时,从所述重传缓冲区中丢弃所述待重传视频数据包。
在本发明实施例的另一种实现方式中,所述重传请求报文中还包括确认接收到的视频数据包的标识,所述方法还包括:
根据所述重传请求报文,将所述确认接收到的视频数据包从所述重传缓冲区中丢弃。
本发明实施例提供的技术方案的有益效果是:
通过在进行视频业务数据传输时,若接收缓冲区溢出,则判断视频数据包的类型,并在接收到重要的视频数据包时,将接收缓冲区队列中不重要的视频数据包丢弃,从而可以在接收缓冲区中存放接收到的重要的视频数据包,由于重要的视频数据包中携带了关键帧,关键帧丢失所造成的视频损失远大于非关键帧丢失,因此上述做法避免了在接收缓冲区溢出时,保证了关键帧不会丢失,避免了视频质量大幅下降,提高了视频业务质量。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的视频业务数据传输场景示意图;
图2是本发明实施例一提供的视频业务数据传输方法流程图;
图3是本发明实施例二提供的视频业务数据传输方法流程图;
图4是本发明实施例三提供的视频业务数据传输方法流程图;
图5是本发明实施例四提供的视频业务数据传输方法流程图;
图6是本发明实施例五提供的视频业务数据接收装置的结构示意图;
图7是本发明实施例六提供的视频业务数据接收装置的结构示意图;
图8是本发明实施例七提供的视频业务数据发送装置的结构示意图;
图9是本发明实施例八提供的视频业务数据发送装置的结构示意图;
图10是本发明实施例九提供的视频业务数据接收装置的结构示意图;
图11是本发明实施例十提供的视频业务数据发送装置的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。
首先结合图1说明本发明实施例的应用场景,参见图1,其中1为通用移动通信系统陆地无线接入网(Universal Mobile Telecommunications System Terrestrial RadioAccess Network,简称“UTRAN”),2为核心网(Core Net,简称“CN”),3为互联网(Internet),4为视频服务器。在移动视频业务中,UE 11与视频服务器4之间通过UTRAN 1、CN 2和Internet 3连接,CN 2中主要包括有通用分组无线服务技术服务支持节点(Serving GPRSSUPPORT NODE,简称“SGSN”)21和网关GPRS支持节点(Gateway GPRS Support Node,简称“GGSN”)22,UTRAN 4主要包括RNC 13和基站(Node B)12,其中RNC 13负责无线部分的传输控制,由于受到无线部分(UTRAN)带宽影响,在进行视频业务传输时,RNC与UE在进行视频数据包的传输过程中可能会出现是视频数据包丢失的情况,从而导致视频业务质量的下降,本发明实施例所要解决的问题就是如何在无线网络状况不好的情况下,最大限度保证视频质量。
实施例一
本发明实施例提供了一种视频业务数据传输方法,该方法由视频业务中的接收端执行,该接收端可以UE或RNC,参见图2,该方法包括:
步骤101:接收视频数据包。
步骤102:判断如果将接收到的视频数据包放入接收缓冲区,是否会造成接收缓冲区溢出,若判断结果为将接收到的视频数据包放入接收缓冲区,不会造成接收缓冲区溢出,则执行步骤103,若判断结果为将接收到的视频数据包放入接收缓冲区,会造成接收缓冲区溢出,则执行步骤104,该接收缓冲区用于存放接收到的视频数据包。
步骤103:将接收到的视频数据包放入该接收缓冲区队列的队尾。
步骤104:判断接收到的视频数据包的类型,若接收到的视频数据包的类型为不重要,则执行步骤105,若接收到的视频数据包的类型为重要,则执行步骤106,视频数据包类型包括不重要和重要。
步骤105:直接丢弃接收到的视频数据包。
步骤106:在该接收缓冲区队列中找到离队尾最近的一个视频数据包的类型为不重要的视频数据包,将该离队尾最近的一个视频数据包的类型为不重要的视频数据包丢弃,将接收到的视频数据包加入到该接收缓冲区队列的队尾。
本发明实施例通过在进行视频业务数据传输时,若接收缓冲区溢出,则判断视频数据包的类型,并在接收到重要的视频数据包时,将接收缓冲区队列中不重要的视频数据包丢弃,从而可以在接收缓冲区中存放接收到的重要的视频数据包,由于重要的视频数据包中携带了关键帧,关键帧丢失所造成的视频损失远大于非关键帧丢失,因此上述做法避免了在接收缓冲区溢出时,保证了关键帧不会丢失,避免了视频质量大幅下降,提高了视频业务质量。
实施例二
本发明实施例提供了一种视频业务数据传输方法,该方法由视频业务中的接收端执行,该接收端可以是UE或RNC,本发明实施例是对实施例一的进一步说明,该进一步说明包括但不限于视频数据包的类型判断、发送重传请求报文等内容,参见图3,该方法包括:
步骤201:接收视频数据包。
如前所述,执行该步骤201的接收端可以是UE或者RNC,当接收端为RNC时,接收端接收到的视频数据包为SDU。当接收端为UE时,接收端接收到的视频数据包为PDU。
步骤202:判断如果将接收到的视频数据包放入接收缓冲区,是否会造成接收缓冲区溢出,若判断结果为将接收到的视频数据包放入接收缓冲区,不会造成接收缓冲区溢出,则执行步骤203,若判断结果为将接收到的视频数据包放入接收缓冲区,会造成接收缓冲区溢出,则执行步骤204。
其中,接收缓冲区用于存放接收到的视频数据包。
步骤203:将接收到的视频数据包放入该接收缓冲区队列的队尾。
步骤204:判断接收到的视频数据包的类型,若接收到的视频数据包的类型为不重要,则执行步骤205,若接收到的视频数据包的类型为重要,则执行步骤206,该视频数据包的类型包括不重要和重要。
具体地,步骤204可以采用以下方式实现:
获取视频数据包中的头部信息,该头部信息包括视频数据包的类型。
对于SDU来说该头部即为SDU头,对于PDU来说该头部即为PDU头。SDU头或者PDU头中均记录有该视频数据包的类型。
在不同的视频编码机制中,不重要的视频数据包和重要的视频数据包的定义是不同的,不重要的视频数据包和重要的视频数据包可以是事先规定好的,规定的依据可以是视频数据包的作用大小及重要程度。以H.264为例:在该编码机制下,I帧表示关键帧,这一帧画面保留完整;解码时只需要本帧数据就可以完成。P帧表示差别帧,记录这一帧跟之前的一个关键帧(或P帧)的差别,解码时需要用之前缓存的画面叠加上本帧定义的差别,生成最终画面。B帧是双向差别帧,也就是B帧记录的是本帧与前后帧的差别,要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加取得最终的画面,因此在H.264编码方式下,I帧数据包即是重要的视频数据包,B帧数据包和P帧数据包即为不重要的视频数据包。当然本发明实施例除了可以应用在上述H.264视频编码机制中以外,还可以应用于H.262等其他视频编码机制中,在其他视频编码机制中根据视频数据包的功能和重要性可以划分重要和不重要。
步骤205:直接丢弃接收到的视频数据包。
步骤206:在该接收缓冲区队列中找到离队尾最近的一个视频数据包的类型为不重要的视频数据包,并将该离队尾最近的一个视频数据包的类型为不重要的视频数据包丢弃,将接收到的视频数据包加入到该接收缓冲区队列的队尾。
步骤207:周期性检测接收缓冲区中的视频数据包的编号是否连续,视频数据包中还携带有数据包编号。
其中,视频数据包的编号可以携带在视频数据包的包头中,且该编号是由发送端按一定机制产生的。值得说明的是,在步骤207中,检测视频数据包的编号是否连续时,是从编号最小的视频数据包向后检测,例如,接收缓冲区中包括编号为3、4、6和7的视频数据包,此时检测的结果为编号为5的视频数据包丢失。
步骤208:根据步骤207的检测结果,向发送端发送重传请求报文,重传请求报文包括待重传视频数据包的标识以及确认接收到的视频数据包的标识,该标识可以是视频数据包的编号。
在具体实现时,可以在重传请求报文中设置一个Bitmap,该Bitmap用来标识哪些视频数据包未被正确接收,哪些视频数据包已被正确接收,Bitmap的最左侧记录有该Bitmap开始的视频数据包的编号,并且处于Bitmap最左侧的视频数据包是在步骤207的检测过程中检测到的第一个丢失掉的,后面记录的视频数据包编号依次递增,Bitmap每一位表示一个视频数据包是否被正确接收,例如0表示未被正确接收,1表示已被正确接收,Bitmap总长度不能超过缓冲区队列总长度。容易知道,比最左侧数据包的编号小的视频数据包认为是已被正确接收。
为了保证重传成功,在发送重传请求报文时,设置一个重传计时器,当重传计时器超时且未收到重传请求报文中请求中的所有待重传视频数据包时,重新发送重传请求报文。容易知道,重新发送的重传请求报文与前一个重传请求报文中包括的待重传视频数据包的标识可能不同,该重新发送的重传请求报文是在前一个重传请求报文的基础上将已接收到的待重传视频数据包标记为确认接收到的视频数据包后得到的。
另外,除了本实施例中采用的使用一个重传请求报文同时实现请求重传所有丢失的视频数据包,并确认所有已正确接收到的视频数据包外。在其他实施例中,还可以采用重传请求报文和确认报文分别用来请求重传所有丢失的视频数据包,和确认已正确接收到的视频数据包,且每个重传请求报文或确认报文可以只用来请求重传或确认一个视频数据包。
进一步地,当接收端为UE时,该方法还包括:周期性地将接收缓冲区中的视频数据包,按规定的个数顺序组装成SDU,并将该SDU递交给上层。
下面对UE组装SDU进行举例说明:接收缓冲区中包括1、2、3、5、6、7、8和9几个视频数据包,且规定每次将4个视频数据包组装成1个SDU,当达到周期时间时,将视频数据包1、2、3和5组装成一个SDU,将视频数据包6、7、8和9组装成一个SDU。
当接收端为RNC时,该方法还包括:将接收到的视频数据包进行分段,将分段得到的PDU发送给UE。
本发明实施例通过在进行视频业务数据传输时,若接收缓冲区溢出,则判断视频数据包的类型,并在接收到重要的视频数据包时,将接收缓冲区队列中不重要的视频数据包丢弃,从而可以在接收缓冲区中存放接收到的重要的视频数据包,由于重要的视频数据包中携带了关键帧,关键帧丢失所造成的视频损失远大于非关键帧丢失,因此上述做法避免了在接收缓冲区溢出时,保证了关键帧不会丢失,避免了视频质量大幅下降,提高了视频业务质量。另一方面,在检测到有视频数据包缺失情况下,通过请求重传,可以进一步保证视频帧不丢失,从而提高视频业务质量。
实施例三
本发明实施例提供了一种视频业务数据传输方法,该方法由视频业务中的发送端执行,该发送端可以是RNC,与该发送端对应的接收端可以为UE,接收端的相应动作参见实施例一或二,参见图4,该方法包括:
步骤301:发送发送缓冲区中的视频数据包,并将发送缓冲区中的视频数据包复制进重传缓冲区。
步骤302:获取接收端发送的重传请求报文,重传请求报文包括待重传视频数据包的标识。
步骤301和302没有先后关系。
步骤303:根据接收到的重传请求报文,判断待重传视频数据包的类型,待重传视频数据包的类型包括重要和不重要。
步骤304:根据待重传视频数据包的类型,确定待重传视频数据包在超时阈值内的最大重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数。
步骤305:确定该待重传视频数据包在该超时阈值内已重传次数。
步骤306:当待重传视频数据包的已重传次数小于最大重传次数时,向接收端发送待重传视频数据包。
本发明实施例通过在发送端进行重传时,根据待重传视频数据包的类型确定不同类型的待重传视频数据包重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数,保证了携带关键帧的重要的待重传视频数据包可以获得更多的重传次数,从而使得在网络状况不佳时,也可以有效保证视频业务的质量。
实施例四
本发明实施例提供了一种视频业务数据传输方法,该方法由视频业务中的发送端执行,该发送端可以是RNC,与该发送端对应的接收端可以为UE,接收端的相应动作参见实施例一或二,本发明实施例是对实施例三的进一步说明,参见图5,该方法包括:
步骤401:发送发送缓冲区中的视频数据包,并将发送缓冲区中的视频数据包复制进重传缓冲区。
具体地,该步骤401包括:
将待发送视频数据包写入发送缓冲区中。
对于RNC来说,待发送视频数据包可以为接收缓冲区中收到的视频数据包进行分段处理后得到的PDU。
将发送缓冲区中的视频数据包发送给UE,并在发送该视频数据包时将该视频数据包复制进重传缓冲区,以防该视频数据包需要重传。
步骤402:获取接收端发送的重传请求报文,重传请求报文包括待重传视频数据包的标识。
具体地,待重传视频数据包为接收端缺少的视频数据包,待重传视频数据包的标识可以为待重传视频数据包的编号。
步骤401和402没有先后关系,可以同时执行。
步骤403:根据接收到的重传请求报文,判断待重传视频数据包的类型,待重传视频数据包的类型包括重要和不重要。
在不同的视频编码机制中,不重要的视频数据包和重要的视频数据包的定义是不同的,不重要的视频数据包和重要的视频数据包可以是事先规定好的,规定的依据可以是视频数据包的作用大小及重要程度。以H.264为例:在该编码机制下,I帧表示关键帧,这一帧画面保留完整;解码时只需要本帧数据就可以完成。P帧表示差别帧,记录这一帧跟之前的一个关键帧(或P帧)的差别,解码时需要用之前缓存的画面叠加上本帧定义的差别,生成最终画面。B帧是双向差别帧,也就是B帧记录的是本帧与前后帧的差别,要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加取得最终的画面,因此在H.264编码方式下,I帧数据包即是重要的视频数据包,B帧数据包和P帧数据包即为不重要的视频数据包。当然本发明实施例除了可以应用在上述H.264视频编码机制中以外,还可以应用于H.262等其他视频编码机制中。
步骤404:根据待重传视频数据包的类型,确定待重传视频数据包在超时阈值内的最大重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数。
在本实施例中,步骤404可以采用以下方式实现:
根据以下公式确定该待重传视频数据包对应的最大重传次数:
其中,RmaxI为类型为重要的待重传视频数据包的最大重传次数,RmaxN为类型为不重要的待重传视频数据包的最大重传次数,Th为视频业务设置的超时阈值,RTT为视频数据包在发送端和接收端间的平均反馈确认周期。该平均反馈确认周期是指数据在发送端和接收端之间的平均往返时间,该时间可以根据统计获得,这里不再赘述。
容易知道,在其他实施例中,该步骤404中的重要的待重传视频数据包和不重要的待重传视频数据包的最大重传次数也可以为设定值。例如,重要的待重传视频数据包的最大重传次数为5次,不重要的待重传视频数据包的最大重传次数为2次。
步骤405:确定该待重传视频数据包在该超时阈值内已重传次数。
进一步地,在步骤405之前,该方法包括:在向接收端发送视频数据包时,记录该视频数据包在超时阈值内的已重传次数。
步骤406:当待重传视频数据包的已重传次数小于最大重传次数时,向接收端发送待重传视频数据包;当该待重传视频数据包的已重传次数等于该最大重传次数时,从重传缓冲区中丢弃该待重传数据包。
具体地,上述向该接收端发送该待重传视频数据包,可以采用下述方式完成:
将该待重传视频数据包从重传缓冲区写入发送缓冲区队列的队首并发送。
进一步地,该重传请求报文还包括确认接收到的视频数据包的标识,该方法还包括:
根据该重传请求报文,将确认接收到的视频数据包从重传缓冲区中丢弃。
具体地,该待重传视频数据包和确认接收到的视频数据包的编号可以根据重传请求报文中的Bitmap得到,该Bitmap用来标识哪些视频数据包未被正确接收,Bitmap的最左侧记录有该Bitmap开始的视频数据包的编号,并且处于Bitmap最左侧的视频数据包是在检测过程中检测到的第一个丢失掉的,后面记录的视频数据包编号依次递增,Bitmap每一位表示一个视频数据包是否被正确接收,例如0表示未被正确接收的待重传视频数据包,1表示已被正确接收的确认接收到的视频数据包,Bitmap总长度不能超过接收端的接收缓冲区队列总长度。
本发明实施例通过在发送端进行重传时,根据待重传视频数据包的类型确定不同类型的待重传视频数据包重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数,保证了携带关键帧的重要的待重传视频数据包可以获得更多的重传次数,从而使得在网络状况不佳时,也可以有效保证视频业务的质量;另外,由于视频业务数据包的重传次数与视频业务的超时阈值相关,因此在进行视频数据包的重传时,根据超时阈值确定重要视频数据包和不重要视频数据包的重传次数,保证了视频业务对实时性的要求。
实施例五
本发明实施例提供了一种视频业务数据接收装置,该装置可以是UE或RNC,参见图6,该装置包括:
第一接收模块501,用于接收视频数据包;
第一判断模块502,用于判断如果将第一接收模块501接收到的视频数据包放入接收缓冲区,是否会造成接收缓冲区溢出,该接收缓冲区用于存放接收到的视频数据包;
第一处理模块503,用于当第一判断模块502的判断结果为将该视频数据包放入接收缓冲区,会造成接收缓冲区溢出时,判断该视频数据包的类型,该视频数据包的类型包括不重要和重要;
若第一接收模块501接收到的视频数据包的类型为不重要,则直接丢弃第一接收模块501接收到的视频数据包;若第一接收模块501接收到的视频数据包的类型为重要,则在该接收缓冲区队列中找到离队尾最近的一个视频数据包的类型为不重要,并将该离队尾最近的一个视频数据包的类型为不重要,将第一接收模块501接收到的视频数据包加入到该接收缓冲区队列的队尾。
本发明实施例通过在进行视频业务数据传输时,若接收缓冲区溢出,则判断视频数据包的类型,并在接收到重要的视频数据包时,将接收缓冲区队列中不重要的视频数据包丢弃,从而可以在接收缓冲区中存放接收到的重要的视频数据包,由于重要的视频数据包中携带了关键帧,关键帧丢失所造成的视频损失远大于非关键帧丢失,因此上述做法避免了在接收缓冲区溢出时,保证了关键帧不会丢失,避免了视频质量大幅下降,提高了视频业务质量。
实施例六
本发明实施例提供了一种视频业务数据接收装置,该装置可以是UE或RNC,本发明实施例是对实施例五的进一步说明,参见图7,该装置包括:
第一接收模块601,用于接收视频数据包;
第一判断模块602,用于判断如果将第一接收模块601接收到的视频数据包放入接收缓冲区,是否会造成接收缓冲区溢出,该接收缓冲区用于存放接收到的视频数据包;
第一处理模块603,用于当第一判断模块602的判断结果为将该视频数据包放入接收缓冲区,不会造成接收缓冲区溢出时,将该视频数据包放入该接收缓冲区队列的队尾;当判断结果为将该视频数据包放入接收缓冲区,会造成接收缓冲区溢出时,判断该视频数据包的类型,该视频数据包的类型包括不重要和重要;
若第一接收模块601接收到的视频数据包的类型为不重要,则直接丢弃第一接收模块601接收到的视频数据包;若第一接收模块601接收到的视频数据包的类型为重要,则在该接收缓冲区队列中找到离队尾最近的一个视频数据包的类型为不重要的视频数据包,并将该离队尾最近的一个视频数据包的类型为不重要的视频数据包丢弃,将第一接收模块601接收到的视频数据包加入到该接收缓冲区队列的队尾。
如前所述,该接收端可以是UE或者RNC,当接收端为RNC时,接收端接收到的视频数据包为SDU。当接收端为UE时,接收端接收到视频数据包为PDU。
具体地,第一处理模块603可以包括:
判断单元,用于获取视频数据包中的头部信息,该头部信息包括视频数据包的类型。
对于SDU来说该头部即为SDU头,对于PDU来说该头部即为PDU头。SDU头或者PDU头中均记录有该视频数据包的类型。
在不同的视频编码机制中,不重要的视频数据包和重要的视频数据包的定义是不同的,不重要的视频数据包和重要的视频数据包可以是事先规定好的,规定的依据可以是视频数据包的作用大小及重要程度。以H.264为例:在该编码机制下,I帧表示关键帧,这一帧画面保留完整;解码时只需要本帧数据就可以完成。P帧表示差别帧,记录这一帧跟之前的一个关键帧(或P帧)的差别,解码时需要用之前缓存的画面叠加上本帧定义的差别,生成最终画面。B帧是双向差别帧,也就是B帧记录的是本帧与前后帧的差别,要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加取得最终的画面,因此在H.264编码方式下,I帧数据包即是重要的视频数据包,B帧数据包和P帧数据包即为不重要的视频数据包。当然本发明实施例除了可以应用在上述H.264视频编码机制中以外,还可以应用于H.262等其他视频编码机制中。
进一步地,该装置还包括检测模块604,用于周期性检测接收缓冲区中的视频数据包的编号是否连续,视频数据包中还携带有数据包编号。
其中,视频数据包的编号可以携带在视频数据包的包头中。值得说明的是,检测视频数据包的编号是否连续时,是从编号最小的视频数据包向后检测,例如,接收缓冲区中包括编号为3、4、6和7的视频数据包,此时检测的结果为编号为5的视频数据包丢失。
相应地,上述第一处理模块603还用于,根据检测模块604的检测结果,向发送端发送重传请求报文,重传请求报文包括待重传视频数据包的标识以及确认接收到的视频数据包的标识,该标识可以是视频数据包的编号。
在具体实现时,可以在重传请求报文中设置一个Bitmap,该Bitmap用来标识哪些视频数据包未被正确接收,Bitmap的最左侧记录有该Bitmap开始的视频数据包的编号,并且处于Bitmap最左侧的视频数据包是在检测过程中检测到的第一个丢失掉的,后面记录的视频数据包编号依次递增,Bitmap每一位表示一个视频数据包是否被正确接收,例如0表示未被正确接收,1表示已被正确接收,Bitmap总长度不能超过缓冲区队列总长度。
进一步地,为了保证重传成功,该装置还包括计时模块,用于在在发送重传请求报文时,设置一个重传计时器;第一处理模块603,还用于当重传计时器超时且未收到重传请求报文中的所有待重传视频数据包时,重新发送重传请求报文。容易知道,重新发送的重传请求报文与前一个重传请求报文中包括的待重传视频数据包的标识可能不同,该重新发送的重传请求报文是在前一个重传请求报文的基础上将已接收到的待重传视频数据包标记为确认接收到的视频数据包后得到的。
另外,除了本实施例中采用的使用一个重传请求报文同时实现请求重传所有丢失的视频数据包,并确认所有已正确接收到的视频数据包外。在其他实施例中,还可以采用重传请求报文和确认报文分别用来请求重传所有丢失的视频数据包,和确认已正确接收到的视频数据包,且每个重传请求报文或确认报文可以只用来请求重传或确认一个视频数据包。
进一步地,当接收端为UE时,第一处理模块603,还用于周期性地将接收缓冲区中的视频数据包,按规定的个数顺序组装成SDU,并将该SDU递交给上层。
下面对UE组装SDU进行举例说明:接收缓冲区中包括1、2、3、5、6、7、8和9几个视频数据包,且规定每次将4个视频数据包组装成1个SDU,当达到周期时间时,将视频数据包1、2、3和5组装成一个SDU,将视频数据包6、7、8和9组装成一个SDU。
当接收端为RNC时,第一处理模块603,还用于将接收到的视频数据包进行分段,将分段得到的PDU发送给UE。
本发明实施例通过在进行视频业务数据传输时,若接收缓冲区溢出,则判断视频数据包的类型,并在接收到重要的视频数据包时,将接收缓冲区队列中不重要的视频数据包丢弃,从而可以在接收缓冲区中存放接收到的重要的视频数据包,由于重要的视频数据包中携带了关键帧,关键帧丢失所造成的视频损失远大于非关键帧丢失,因此上述做法避免了在接收缓冲区溢出时,保证了关键帧不会丢失,避免了视频质量大幅下降,提高了视频业务质量。另一方面,在检测到有视频数据包缺失情况下,通过请求重传,可以进一步保证视频帧不丢失,从而提高视频业务质量。
实施例七
本发明实施例提供了一种视频业务数据发送装置,该装置可以是UE或RNC,参见图8,该装置包括:
发送模块701,用于发送发送缓冲区中的视频数据包,并将发送缓冲区中的视频数据包复制进重传缓冲区;
第二接收模块702,用于获取接收端发送的重传请求报文,重传请求报文包括待重传视频数据包的标识;
第二判断模块703,用于根据第二接收模块702接收到的重传请求报文,判断待重传视频数据包的类型,待重传视频数据包的类型包括重要和不重要;
第二处理模块704,用于根据第二判断模块703判断的待重传视频数据包的类型,确定待重传视频数据包在超时阈值内的最大重传次数,类型为重要的视频数据包的最大重传次数大于类型为不重要的视频数据包的最大重传次数,确定该待重传视频数据包在该超时阈值内已重传次数,当待重传视频数据包的已重传次数小于最大重传次数时,向接收端发送待重传视频数据包。
本发明实施例通过在发送端进行重传时,根据待重传视频数据包的类型确定不同类型的待重传视频数据包重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数,保证了携带关键帧的重要的待重传视频数据包可以获得更多的重传次数,从而使得在网络状况不佳时,也可以有效保证视频业务的质量。
实施例八
本发明实施例提供了一种视频业务数据发送装置,该装置可以是RNC,本发明实施例是对实施例七的进一步说明,参见图9,该装置包括:
发送模块801,用于发送发送缓冲区中的视频数据包,并将发送缓冲区中的视频数据包复制进重传缓冲区;
第二接收模块802,用于获取接收端发送的重传请求报文,重传请求报文包括待重传视频数据包的标识,待重传视频数据包的标识可以为待重传视频数据包的编号;
第二判断模块803,用于根据第二接收模块802接收到的重传请求报文,判断待重传视频数据包的类型,待重传视频数据包的类型包括重要和不重要;
在不同的视频编码机制中,不重要的视频数据包和重要的视频数据包的定义是不同的,不重要的视频数据包和重要的视频数据包可以是事先规定好的,规定的依据可以是视频数据包的作用大小及重要程度。以H.264为例:在该编码机制下,I帧表示关键帧,这一帧画面保留完整;解码时只需要本帧数据就可以完成。P帧表示差别帧,记录这一帧跟之前的一个关键帧(或P帧)的差别,解码时需要用之前缓存的画面叠加上本帧定义的差别,生成最终画面。B帧是双向差别帧,也就是B帧记录的是本帧与前后帧的差别,要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加取得最终的画面,因此在H.264编码方式下,I帧数据包即是重要的视频数据包,B帧数据包和P帧数据包即为不重要的视频数据包。当然本发明实施例除了可以应用在上述H.264视频编码机制中以外,还可以应用于H.262等其他视频编码机制中。
第二处理模块804,用于根据第二判断模块803判断的待重传视频数据包的类型,确定待重传视频数据包在超时阈值内的最大重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数,确定该待重传视频数据包在该超时阈值内已重传次数,当待重传视频数据包的已重传次数小于最大重传次数时,向接收端发送待重传视频数据包;当该待重传视频数据包的已重传次数等于该最大重传次数时,从重传缓冲区中丢弃该待重传数据包。
发送模块801将待发送视频数据包写入发送缓冲区中,然后将发送缓冲区中的视频数据包发送给UE,并在发送该视频数据包时将该视频数据包复制进重传缓冲区,以防该视频数据包需要重传。对于RNC来说,待发送视频数据包可以为接收缓冲区中收到的视频数据包进行分段处理后得到的PDU。
进一步地,该第二处理模块804可以根据以下公式确定该待重传视频数据包对应的最大重传次数:
其中,RmaxI为类型为重要的待重传视频数据包的最大重传次数,RmaxN为类型为不重要的待重传视频数据包的最大重传次数,Th为视频业务设置的超时阈值,RTT为视频数据包在发送端和接收端间的平均反馈确认周期。该平均反馈确认周期是指数据在发送端和接收端之间的平均往返时间,该时间可以根据统计获得,这里不再赘述。
容易知道,在其他实施例中,重要的视频数据包和不重要的视频数据包的最大重传次数也可以为设定值。例如,重要的视频数据包的最大重传次数为5次,不重要的视频数据包的最大重传次数为2次。
进一步地,该第二处理模块804,还用于在向接收端发送视频数据包时,记录该视频数据包在超时阈值内的已重传次数。
进一步地,该第二处理模块804,还用于将该待重传视频数据包从重传缓冲区写入发送缓冲区队列的队首并发送。
进一步地,该重传请求报文还包括确认接收到的视频数据包的标识,该第二处理模块804,还用于根据该重传请求报文,将确认接收到的视频数据包从重传缓冲区中丢弃。
具体地,该待重传视频数据包和确认接收到的视频数据包的编号可以根据重传请求报文中的Bitmap得到,该Bitmap用来标识哪些视频数据包未被正确接收,Bitmap的最左侧记录有该Bitmap开始的视频数据包的编号,并且处于Bitmap最左侧的视频数据包是在检测过程中检测到的第一个丢失掉的,后面记录的视频数据包编号依次递增,Bitmap每一位表示一个视频数据包是否被正确接收,例如0表示未被正确接收的待重传视频数据包,1表示已被正确接收的确认接收到的视频数据包,Bitmap总长度不能超过接收端的接收缓冲区队列总长度。
本发明实施例通过在发送端进行重传时,根据待重传视频数据包的类型确定不同类型的待重传视频数据包重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数,保证了携带关键帧的重要的待重传视频数据包可以获得更多的重传次数,从而使得在网络状况不佳时,也可以有效保证视频业务的质量;另外,由于视频业务数据包的重传次数与视频业务的超时阈值相关,因此在进行视频数据包的重传时,根据超时阈值确定重要的视频数据包和不重要的视频数据包的重传次数,保证了视频业务对实时性的要求。
实施例九
本发明实施例提供了一种视频业务数据接收装置,如图10所示,该装置90一般包括第一存储器91、第一处理器92、第一发送器93和第一接收器94等部件。本领域技术人员可以理解,图10中所示出的结构并不构成对本网关的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合图10对装置90的各个构成部件进行具体的介绍:
第一存储器91可用于存储软件程序以及应用模块,第一处理器92通过运行存储在第一存储器91的软件程序以及应用模块,从而执行装置90的各种功能应用以及数据处理。第一存储器91可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据装置90的处理所创建的数据。此外,第一存储器91可以包括高速RAM(Random Access Memory,随机存取存储器),还可以包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
第一处理器92是装置90的控制中心,利用各种接口和线路连接整个计算机的各个部分。
具体地,第一处理器92通过运行或执行存储在第一存储器91内的软件程序和/或应用模块,以及调用存储在第一存储器91内的数据,第一处理器92可以实现:
通过第一接收器94接收视频数据包;判断如果将第一接收器94接收到的视频数据包放入接收缓冲区,是否会造成接收缓冲区溢出,该接收缓冲区用于存放接收到的视频数据包;当判断结果为将数据包放入接收缓冲区,会造成接收缓冲区溢出时,则判断第一接收器94接收到的视频数据包的类型,数据包类型包括重要和不重要;若第一接收器94接收到的视频数据包的类型为不重要,则直接丢弃第一接收器94接收到的视频数据包;若第一接收器94接收到的视频数据包的类型为重要,则在接收缓冲区队列中找到离队尾最近的一个视频数据包的类型为不重要的视频数据包,将离队尾最近的一个视频数据包的类型为不重要的视频数据包丢弃,将第一接收器94接收到的视频数据包加入到接收缓冲区队列的队尾。
进一步地,该第一处理器92还可实现:
获取视频数据包中的头部信息,该头部信息包括视频数据包的类型。
进一步地,数据包中还携带有数据包编号,该第一处理器92还可实现:
周期性检测接收缓冲区中的视频数据包的编号是否连续;
根据检测结果,向发送端发送重传请求报文,重传请求报文包括待重传视频数据包的标识。
进一步地,该第一处理器92还可实现:
在发送重传请求报文时,设置对应的重传计时器;
当重传计时器超时且未收到请求重传请求报文中的所有待重传视频数据包时,重新发送重传请求报文。
本发明实施例通过在进行视频业务数据传输时,若接收缓冲区溢出,则判断视频数据包的类型,并在接收到重要的视频数据包时,将接收缓冲区队列中不重要的视频数据包丢弃,从而可以在接收缓冲区中存放接收到的重要的视频数据包,由于重要的视频数据包中携带了关键帧,关键帧丢失所造成的视频损失远大于非关键帧丢失,因此上述做法避免了在接收缓冲区溢出时,保证了关键帧不会丢失,避免了视频质量大幅下降,提高了视频业务质量。另一方面,在检测到有视频数据包缺失情况下,通过请求重传,可以进一步保证视频帧不丢失,从而提高视频业务质量。
实施例十
本发明实施例提供了一种视频业务数据发送装置,如图11所示,该装置100一般包括第二存储器1001、第二处理器1002、第二发送器1003和第二接收器1004等部件。本领域技术人员可以理解,图11中所示出的结构并不构成对本网关的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合图11对装置100的各个构成部件进行具体的介绍:
第二存储器1001可用于存储软件程序以及应用模块,第二处理器1002通过运行存储在第二存储器1001的软件程序以及应用模块,从而执行装置100的各种功能应用以及数据处理。第二存储器1001可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据装置100的处理所创建的数据。此外,第二存储器1001可以包括高速RAM(Random Access Memory,随机存取存储器),还可以包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
第二处理器1002是装置100的控制中心,利用各种接口和线路连接整个计算机的各个部分。
具体地,第二处理器1002通过运行或执行存储在第二存储器1001内的软件程序和/或应用模块,以及调用存储在第二存储器1001内的数据,第二处理器1002可以实现:
通过第二发送器1003发送发送缓冲区中的视频数据包,并将该发送缓冲区中的视频数据包复制进重传缓冲区;通过第二接收器1004获取接收端发送的重传请求报文,重传请求报文包括待重传视频数据包的标识;根据接收到的重传请求报文,判断待重传视频数据包的类型,待重传视频数据包的类型包括重要和不重要;根据待重传视频数据包的类型,确定待重传视频数据包在超时阈值内的最大重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数;确定待重传视频数据包在超时阈值内已重传次数;当待重传视频数据包的已重传次数小于最大重传次数时,向接收端发送待重传视频数据包。
进一步地,第二处理器1002还可以实现:根据以下公式确定该待重传视频数据包对应的最大重传次数:
其中,RmaxI为类型为重要的待重传视频数据包的最大重传次数,RmaxN为类型为不重要的待重传视频数据包的最大重传次数,Th为视频业务设置的超时阈值,RTT为视频数据包在发送端和接收端间的平均反馈确认周期。
进一步地,第二处理器1002还可以实现:
将该待重传视频数据包从重传缓冲区写入发送缓冲区队列的队首并发送。
进一步地,第二处理器1002还可以实现:
当待重传视频数据包的已重传次数等于最大重传次数时,从重传缓冲区中丢弃待重传视频数据包。
进一步地,该重传请求报文还包括确认接收到的视频数据包的标识,第二处理器1002还可以实现:
根据请求重传请求报文,将确认接收到的视频数据包从重传缓冲区中丢弃。
本发明实施例通过在发送端进行重传时,根据待重传视频数据包的类型确定不同类型的待重传视频数据包重传次数,类型为重要的待重传视频数据包的最大重传次数大于类型为不重要的待重传视频数据包的最大重传次数,保证了携带关键帧的重要的待重传视频数据包可以获得更多的重传次数,从而使得在网络状况不佳时,也可以有效保证视频业务的质量;另外,由于视频业务数据包的重传次数与视频业务的超时阈值相关,因此在进行视频数据包的重传时,根据超时阈值确定重要的视频数据包和不重要的视频数据包的重传次数,保证了视频业务对实时性的要求。
需要说明的是:上述实施例提供的视频业务数据发送装置和视频业务数据接收装置在进行视频业务数据传输时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的视频业务数据发送装置和视频业务数据接收装置与视频业务数据传输方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (8)

1.一种视频业务数据发送装置,其特征在于,所述装置包括:
发送模块,用于发送发送缓冲区中的视频数据包,并将所述发送缓冲区中的视频数据包复制进重传缓冲区;
第二接收模块,用于获取接收端发送的重传请求报文,所述重传请求报文包括待重传视频数据包的标识;
第二判断模块,用于根据所述第二接收模块接收到的重传请求报文,判断待重传视频数据包的类型,所述待重传视频数据包的类型包括重要和不重要;
第二处理模块,用于根据所述第二判断模块判断的待重传视频数据包的类型,确定所述待重传视频数据包在超时阈值内的最大重传次数,所述类型为重要的待重传视频数据包的最大重传次数大于所述类型为不重要的待重传视频数据包的最大重传次数;确定所述待重传视频数据包在所述超时阈值内已重传次数;当所述待重传视频数据包的已重传次数小于所述最大重传次数时,向所述接收端发送所述待重传视频数据包;
所述第二处理模块,用于根据以下公式确定所述待重传视频数据包对应的最大重传次数:
其中,RmaxI为所述类型为重要的待重传视频数据包的最大重传次数,RmaxN为所述类型为不重要的待重传视频数据包的最大重传次数,Th为视频业务设置的超时阈值,RTT为视频数据包在发送端和所述接收端间的平均反馈确认周期。
2.根据权利要求1所述的装置,其特征在于,所述第二处理模块,用于将所述待重传视频数据包从所述重传缓冲区写入所述发送缓冲区队列的队首并发送。
3.根据权利要求1或2所述的装置,其特征在于,所述第二处理模块,还用于当所述待重传视频数据包的已重传次数等于所述最大重传次数时,从所述重传缓冲区中丢弃所述待重传视频数据包。
4.根据权利要求1或2所述的装置,其特征在于,所述重传请求报文中还包括确认接收到的视频数据包的标识,所述第二处理模块,还用于根据所述重传请求报文,将所述确认接收到的视频数据包从所述重传缓冲区中丢弃。
5.一种视频业务数据传输方法,其特征在于,所述方法包括:
发送发送缓冲区中的视频数据包,并将所述发送缓冲区中的视频数据包复制进重传缓冲区;
获取接收端发送的重传请求报文,所述重传请求报文包括待重传视频数据包的标识;
根据接收到的所述重传请求报文,判断待重传视频数据包的类型,所述待重传视频数据包的类型包括重要和不重要;
根据待重传视频数据包的类型,确定所述待重传视频数据包在超时阈值内的最大重传次数,所述类型为重要的待重传视频数据包的最大重传次数大于所述类型为不重要的待重传视频数据包的最大重传次数;
确定所述待重传视频数据包在所述超时阈值内已重传次数;
当所述待重传视频数据包的已重传次数小于所述最大重传次数时,向所述接收端发送所述待重传视频数据包;
所述根据待重传视频数据包的类型,确定所述待重传视频数据包在超时阈值内的最大重传次数,包括:
根据以下公式确定所述待重传视频数据包对应的最大重传次数:
其中,RmaxI为所述类型为重要的待重传视频数据包的最大重传次数,RmaxN为所述类型为不重要的待重传视频数据包的最大重传次数,Th为视频业务设置的超时阈值,RTT为视频数据包在发送端和所述接收端间的平均反馈确认周期。
6.根据权利要求5所述的方法,其特征在于,所述向所述接收端发送所述待重传视频数据包,包括:
将所述待重传视频数据包从所述重传缓冲区写入所述发送缓冲区队列的队首并发送。
7.根据权利要求5或6所述的方法,其特征在于,所述方法还包括:
当所述待重传视频数据包的已重传次数等于所述最大重传次数时,从所述重传缓冲区中丢弃所述待重传视频数据包。
8.根据权利要求5或6所述的方法,其特征在于,所述重传请求报文中还包括确认接收到的视频数据包的标识,所述方法还包括:
根据所述重传请求报文,将所述确认接收到的视频数据包从所述重传缓冲区中丢弃。
CN201380002474.3A 2013-11-05 2013-11-05 视频业务数据传输方法和数据发送装置 Active CN103814582B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2013/086531 WO2015066836A1 (zh) 2013-11-05 2013-11-05 视频业务数据传输方法、数据接收装置和数据发送装置

Publications (2)

Publication Number Publication Date
CN103814582A CN103814582A (zh) 2014-05-21
CN103814582B true CN103814582B (zh) 2017-06-20

Family

ID=50709728

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201380002474.3A Active CN103814582B (zh) 2013-11-05 2013-11-05 视频业务数据传输方法和数据发送装置

Country Status (2)

Country Link
CN (1) CN103814582B (zh)
WO (1) WO2015066836A1 (zh)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105450969B (zh) * 2014-06-16 2019-01-15 联想(北京)有限公司 一种实时视频数据传输方法及电子设备
CN105828180A (zh) * 2016-03-31 2016-08-03 努比亚技术有限公司 一种缓存视频帧的装置和方法
CN108616925B (zh) * 2016-12-13 2023-03-21 中兴通讯股份有限公司 一种数据流的处理方法及装置
CN108419275B (zh) * 2017-02-10 2022-01-14 华为技术有限公司 一种数据传输方法、通信设备、终端和基站
CN109002361B (zh) * 2017-06-07 2022-06-03 阿里巴巴集团控股有限公司 数据处理方法、分配方法、电子设备、客户端和存储介质
CN107404443B (zh) * 2017-08-03 2020-06-23 北京东土军悦科技有限公司 队列缓存资源控制方法及装置、服务器及存储介质
CN109996088A (zh) * 2017-12-29 2019-07-09 阿里巴巴集团控股有限公司 一种直播数据处理方法及装置
CN110830818A (zh) * 2018-08-10 2020-02-21 北京松果电子有限公司 视频传输方法和装置
CN110839164A (zh) * 2018-08-17 2020-02-25 北京松果电子有限公司 视频传输方法和装置
CN111131210B (zh) 2019-12-16 2021-09-17 维沃移动通信有限公司 数据处理方法及电子设备
CN113495832A (zh) * 2020-04-05 2021-10-12 杭州迪普科技股份有限公司 缓存区泄漏检测系统及其方法
CN115001632A (zh) * 2022-06-09 2022-09-02 咪咕文化科技有限公司 一种信息传输方法、装置、电子设备及可读存储介质
CN115514815A (zh) * 2022-07-13 2022-12-23 武汉依迅北斗时空技术股份有限公司 一种音视频数据采集方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101039254A (zh) * 2006-03-15 2007-09-19 联想(北京)有限公司 一种媒体数据重组方法以及组包服务器
CN101179362A (zh) * 2006-11-07 2008-05-14 中兴通讯股份有限公司 适宜移动流媒体应用的自动重传请求机制
CN101645883A (zh) * 2008-08-08 2010-02-10 比亚迪股份有限公司 数据传输方法、数据发送方法及数据接收方法
CN102017539A (zh) * 2005-08-05 2011-04-13 索尼株式会社 用于通过有损网络传输数据的系统和方法
WO2011152231A1 (ja) * 2010-05-31 2011-12-08 株式会社エヌ・ティ・ティ・ドコモ 放送補完データ伝送装置および放送補完データ伝送方法、ならびに放送システム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1130839B1 (en) * 2000-03-02 2005-06-08 Matsushita Electric Industrial Co., Ltd. Method and apparatus for retransmitting video data frames with priority levels
CN101075948A (zh) * 2006-05-15 2007-11-21 中兴通讯股份有限公司 一种实现实时流媒体节目可靠传输的方法
CN101360058A (zh) * 2008-09-08 2009-02-04 华为技术有限公司 一种控制缓存溢出的方法及装置
CN101466034A (zh) * 2008-12-25 2009-06-24 华为技术有限公司 发送、播放流媒体数据的方法和装置及流媒体点播系统
US8009567B2 (en) * 2009-02-05 2011-08-30 Cisco Technology, Inc. System and method for improved data transmission reliability over a network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102017539A (zh) * 2005-08-05 2011-04-13 索尼株式会社 用于通过有损网络传输数据的系统和方法
CN101039254A (zh) * 2006-03-15 2007-09-19 联想(北京)有限公司 一种媒体数据重组方法以及组包服务器
CN101179362A (zh) * 2006-11-07 2008-05-14 中兴通讯股份有限公司 适宜移动流媒体应用的自动重传请求机制
CN101645883A (zh) * 2008-08-08 2010-02-10 比亚迪股份有限公司 数据传输方法、数据发送方法及数据接收方法
WO2011152231A1 (ja) * 2010-05-31 2011-12-08 株式会社エヌ・ティ・ティ・ドコモ 放送補完データ伝送装置および放送補完データ伝送方法、ならびに放送システム

Also Published As

Publication number Publication date
CN103814582A (zh) 2014-05-21
WO2015066836A1 (zh) 2015-05-14

Similar Documents

Publication Publication Date Title
CN103814582B (zh) 视频业务数据传输方法和数据发送装置
CN103312441B (zh) 数据包传输方法及系统、发送端设备与接收端设备
US9397791B2 (en) Transmitting data in a mobile communication system
US7542482B2 (en) Method and apparatus for message segmentation in a wireless communication system
US6839566B2 (en) Method and apparatus for time-based reception of transmissions in a wireless communication system
US8428086B2 (en) Transmitting data in a mobile communication system
KR100750170B1 (ko) 통신 네트워크에서 데이터 프레임을 효율적으로 전송하는방법 및 장치
KR100750166B1 (ko) 무선 네트워크 환경에서 효율적인 데이터 재전송 장치 및방법
CN110086578A (zh) 数据传输方法、装置和系统
TW200807992A (en) BI-directional RLC non-persistent mode for low delay services
ZA200404746B (en) System and method for polling a protocal data unit of a transmission buffer
KR20060088507A (ko) 통신 시스템, 송신 장치 및 수신 장치
WO2010006557A1 (zh) 数据传输方法和装置
US20090303871A1 (en) Method and apparatus for packet aggregation according to traffic characteristics
CN104521167A (zh) 一种数据传输方法、装置、基站及用户设备
KR20150066335A (ko) 무선통신에서 패킷 손실을 줄이기 위한 방법 및 장치
CN101494531B (zh) 调整滑动窗口的方法和装置
Ge et al. Comparisons of error control techniques for wireless video multicasting
JP2013066188A (ja) QoS保証方法及び装置
CN104137507B (zh) 反馈丢包的消息处理方法及装置
US20030137948A1 (en) Retransmission control in wireless packet data networks
Gomez et al. QoS modeling for end-to-end performance evaluation over networks with wireless access
US11502986B2 (en) Reducing transmission delay of transmitting data in Wi-Fi
Chandra et al. TCP performance for future IP-based wireless networks
KR101012549B1 (ko) 트래픽 특성에 따른 패킷의 집합 통신 방법 및 장치

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20211221

Address after: 450046 Floor 9, building 1, Zhengshang Boya Plaza, Longzihu wisdom Island, Zhengdong New Area, Zhengzhou City, Henan Province

Patentee after: Super fusion Digital Technology Co.,Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd.