CN105611424A - 基于rudp的音视频可靠传输qos方法、系统 - Google Patents

基于rudp的音视频可靠传输qos方法、系统 Download PDF

Info

Publication number
CN105611424A
CN105611424A CN201511005154.0A CN201511005154A CN105611424A CN 105611424 A CN105611424 A CN 105611424A CN 201511005154 A CN201511005154 A CN 201511005154A CN 105611424 A CN105611424 A CN 105611424A
Authority
CN
China
Prior art keywords
rudp
data
seq
bag
video
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.)
Granted
Application number
CN201511005154.0A
Other languages
English (en)
Other versions
CN105611424B (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.)
Wuhan Hongruida Information Technology Co Ltd
Original Assignee
Wuhan Hongruida Information Technology 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 Wuhan Hongruida Information Technology Co Ltd filed Critical Wuhan Hongruida Information Technology Co Ltd
Priority to CN201511005154.0A priority Critical patent/CN105611424B/zh
Publication of CN105611424A publication Critical patent/CN105611424A/zh
Application granted granted Critical
Publication of CN105611424B publication Critical patent/CN105611424B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64746—Control signals issued by the network directed to the server or the client
    • H04N21/64761—Control signals issued by the network directed to the server or the client directed to the server
    • H04N21/64776—Control signals issued by the network directed to the server or the client directed to the server for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64784—Data processing by the network
    • H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了音视频传输领域，具体为基于RUDP的音视频可靠传输QOS方法、系统、发送端和接收端。该方法包括：发送端根据音视频数据长度将音视频打包成一个以上RUDP包，每个RUDP包中数据均对应不同帧音视频内容；发送端将RUDP包通过udp？socket发送，并同时将RUDP包拷贝到发送指令对应循环buffer中，备发送失败时调用重发；接收端接收RUDP包数据，并将接收数据拷贝到接收指令对应循环buffer中；接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据处理方式，处理方式包括：丢弃、解码或重发。本发明有效解决了视频传输中网络延迟、拥塞和丢包的现象。

Description

基于RUDP的音视频可靠传输QOS方法、系统
技术领域
本发明涉及音视频传输领域，具体为基于RUDP的音视频可靠传输QOS方法、系统、发送端和接收端。
背景技术
目前，实现可靠数据传递的方法主要采用TCP协议或者SCTP协议。TCP和SCTP都是基于流的传输协议，都有十分复杂的保证可靠传输的机制，应用于通信中时都将不可避免地增加系统的开销并降低通信效率，而UDP虽然开销小、速率高，但它是基于消息的不可靠传递协议，虽然音视频传输允许一定的丢包率，但是媒体转发系统对视频传输却要求具备一定的可靠性，为此就自然地考虑到在UDP的基础上增加一些为保证可靠数据传递所必需的功能，使其成为一个基于消息的可靠传递协议这就是RUDP协议。
在RUDP协议主要是解决TCP协议和UDP协议存在的弊端，TCP协议是面向有连接的传输协议，其传输的数据通过三次握手和滑动窗口协议实现了数据的可靠传输，但TCP协议由于需要三次握手，因此其传输实时性比较差，很难应用于实时的数据传输；UDP协议刚好于TCP协议相反，UDP协议是面向无连接的传输协议，数据只是在不断地进行发送，而没有对数据进行丢包和排序处理，不能进行网络的QOS保证，而目前市场上的RUDP的音视频可靠传输，在传输过程中存在网络传输丢包、抖动和乱序的现象，对服务质量产生很多不好的影响。
随着移动互联网的快速发展以及媒体转发终端性能的逐步提高，媒体转发终端间进行实时音视频通讯成为未来移动互联网发展的一个重要方向。那么如何保证媒体转发终端之间实时音视频通讯的服务质量成为一个必须加以重视的问题。实时音视频通讯包括采集、编码、网络传输、解码、播放等环节，其中采集、编解码和播放是不受网络条件影响的，只受限于编解码算法，播放策略等因素，网络传输的丢包、抖动和乱序对qos的影响最为重大。
TCP的三次握手协议实现了数据的可靠传输，但TCP协议由于需要三次握手，受网络延迟、拥塞和丢包的影响，其传输实时性比较差，很难应用于实时的数据传输。
发明内容
本发明的目的在于提供基于RUDP的音视频可靠传输QOS方法、系统、发送端和接收端，以解决上述背景技术中提出的问题。
为实现上述目的，本发明提供一种基于RUDP的音视频可靠传输QOS方法，其包括：
发送端根据音视频数据长度将音视频打包成一个以上的RUDP包，每个RUDP包中的数据均对应不同帧的音视频内容；
发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中；
接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发。
在一些实施例中，优选为，所述发送指令对应循环buffer的节点数、所述接收指令对应循环buffer的节点数相等，且均为65536的整数倍。
在一些实施例中，优选为，所述发送端根据音视频数据长度将音视频打包成一个以上的RUDP包包括：
分析所述音视频的数据长度；
当所述数据长度大于MTU时，将数据长度大于MTU的帧切割，分块封装到多个RUDP包中；
当所述数据长度小于MTU时，将数据直接封装为RUDP包中。
在一些实施例中，优选为，所述发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发包括：
从打包的多个RUDP包中提取一个RUDP包；
将所述RUDP包的seq设置为send_seq，通过udpsocket发送给接收端；
在发送同时，将所述RUDP包拷贝到所述send_seq对应节点的循环buffer中，以备接收端未成功接收时，调用重发。
在一些实施例中，优选为，所述接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中包括：
接收端接收所述RUDP包的数据；
解析数据的RUDP包头，设置received_seq，并将数据拷贝到received_seq对应循环buffer中，并将该节点的数据flag设置为true；
若received_seq对应的RUDP包的到达时间晚于end_seq对应包的到达时间，则更新end_seq，否则不更新。
在一些实施例中，优选为，接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式包括：
当收到第一个所述RUDP包的数据时，包头的start_seq和end_seq都设置为received_seq；
当收到非第一个所述RUDP包时，进行如下操作：
以设定时间段为间隔单位，循环扫描start_seq和end_seq对应的每个节点；
若当前时间和start_seq对应数据到达时间的差值大于第一阈值，则丢弃start_seq和end_seq之间的每个节点的数据，将每个节点的数据flag设置为false，更新start_seq为end_seq；
若当前时间和start_seq对应数据到达时间的小于第一阈值，且start_seq对应的节点的下一个节点的数据falg为true，则将该节点的数据送到解码单元，同时将start_seq更新为该节点的seq，并将该节点的flag设置为false；
若flag为false，且当前时间和start_seq对应的数据到达时间的差值小于第二阈值，则该请求发送端将seq对应的RUDP数据重发。
本发明还提供了一种基于RUDP的音视频可靠传输QOS的发送端，其包括：
分析模块，用于分析所述音视频的数据长度；
打包模块，用于根据分析模块分析的数据长度来对音视频进行打包，当所述数据长度大于MTU时，将数据长度大于MTU的帧切割，分块封装到多个RUDP包中；当所述数据长度小于MTU时，将数据直接封装为RUDP包中；
发送模块，用于将RUDP包通过udpsocket发送；
缓存模块，用于在所述发送模块发送的同时，将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收模块，用于接收发送失败的信息，并将所述信息发送给发送模块。
本发明还提供了一种基于RUDP的音视频可靠传输QOS的接收端，其包括：
接收单元，用于接收发送端发送的RUDP包的数据；
缓存单元，用于将接收的所述数据拷贝到接收指令对应循环buffer中；
判断单元，用于根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发；
解码单元，用于对RUDP包的数据进行解码获取音视频；
发送单元，用于向发送端发送重发信息。
在一些实施例中，优选为，所述判断单元的执行方式为：
当收到第一个所述RUDP包的数据时，包头的start_seq和end_seq都设置为received_seq；
当收到非第一个所述RUDP包时，进行如下操作：
以设定时间段为间隔单位，循环扫描start_seq和end_seq对应的每个节点；
若当前时间和start_seq对应数据到达时间的差值大于第一阈值，则丢弃start_seq和end_seq之间的每个节点的数据，将每个节点的数据flag设置为false，更新start_seq为end_seq；
若当前时间和start_seq对应数据到达时间的小于第一阈值，且start_seq对应的节点的下一个节点的数据falg为true，则将该节点的数据送到解码单元，同时将start_seq更新为该节点的seq，并将该节点的flag设置为false；
若flag为false，且当前时间和start_seq对应的数据到达时间的差值小于第二阈值，则该请求发送端将seq对应的RUDP数据重发。
本发明还提供了一种基于RUDP的音视频可靠传输QOS系统，其包括:接收端和发送端，其中，
发送端根据音视频数据长度将音视频打包成一个以上的RUDP包，每个RUDP包中的数据均对应不同帧的音视频内容；
发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中；
接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发。
本发明提供的基于RUDP的音视频可靠传输QOS方法、系统、发送端和接收端，与现有技术相比，发送端对音视频根据其长度进行切割打包，形成一个以上的RUDP包，这些RUDP包被单独发送，接收端接收到RUDP包后根据接收时间来确定接收的RUDP包数据丢弃、解码或重发，将超时接收的直接丢弃，将短时间没收到的包进行重发，将正常接收且时间合适的进行解码，即满足音视频可以适当丢帧，只要播放的时候有一定帧等待即可，更重要的是，在发送和接收两端均设置缓冲区，以方便对数据进行暂存，根据数据分析后的结构进行调用或做各种处理。本发明整体有效解决了视频传输中网络延迟、拥塞和丢包的现象。
附图说明
图1示出了本发明RUDP视频传输系统的物理架构示意图；
图2示出了本发明RUDP视频传输系统的逻辑架构示意图；
图3示出了本发明RUDP视频传输系统的工作状态示意图；
图4示出了本发明一个实施例中发送端循环buffer状态示意图；
图5示出了本发明一个实施例中接收端循环buffer状态示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
基于现在互联网络音视频传输出现网络延迟、丢包、抖动等现象，本发明基于RUDP传输技术解决了在主播和服务器之间音视频数据传输的问题。具体提供了基于RUDP的音视频可靠传输QOS方法、系统、发送端和接收端。
基于RUDP的音视频可靠传输QOS方法，其包括：
发送端根据音视频数据长度将音视频打包成一个以上的RUDP包，每个RUDP包中的数据均对应不同帧的音视频内容；
发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中；
接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发。
对应该方法提供了执行该方法的发送端、接收端和方法对应的系统。其中，
发送端可以直接应用于主播方，以硬件形式呈现，该硬件中加载对应的执行程序，也可以设计为一套应用程序加载日常主播方使用的互联网工具中，比如：手机、平板电脑、PC电脑等。
接收端可以直接应用于平台服务器中，该平台服务器加载该应用程序。
对应的系统包含发送端和接收端的两方，二者之间执行统一的RUDP协议，加载QOS模块。
下面，对该技术进行详细说明：
本技术改进是基于RUDP视频传输系统的整体架构进行的，下面首先描述该整体架构：
图1中示出了该RUDP视频传输系统的物理架构：
系统物理架构采用三级交换网络，主播将音视频信息发送到MTS(媒体转发服务器)，MTS在发生故障时可以通过备份的MTS进行房间迁移，MTS处于一级交换网络，MTS将信息推流到二级交换网的MSS集群，观众通过各种浏览器访问MSS集群服务器，数据流是可以双向访问和互动的。
图2中示出了该RUDP视频传输系统的逻辑架构：
系统逻辑架构采用四层架构，最底层是LINUX内核，上层通过系统API接口访问LINUX内核，然后是网络层，网络层分为网络适配层、NetAPI接口和EventDrive三个部分，其中NetAPI接口遵循TCP/UDP协议，eventDrive通过epoll函数进行Linux系统设备访问，然后是MTS层，MTS层包含房间管理、游客管理、认证鉴权、媒体转发、直播推流和故障管理这个几个功能，最上层是接口层，包括MRSinterface(媒体资源管理服务器接口)、MTMinterface(媒体任务管理服务器接口)、MSSinterface(媒体流服务器接口)、Clientinterface(客户端器接口)。
基于该逻辑架构，图3示出了其工作状态。
1.1RM(房间管理者)向MTM(媒体任务管理服务器)申请创建房间。
1.2MTM(媒体任务管理服务器)通过消息代理机制向MRS(媒体资源管理服务器)申请创建房间。
1.3MRS(媒体资源管理服务器)向MTS(媒体转发服务器)申请创建房间。
2.1创建房间成功后，RM向MTM申请进入房间。
2.2创建房间成功后，RM通过MTM向MTS登记游客信息。
3.1RM向助手提供开播参数。
3.2播放开始后，RM通过助手连接MTS，发送实时数据流，数据流的发送和接收遵循RUDP协议。
3.3MTS对用户鉴别权限，让有权限的用户接收实时流。
4.1MTS向MSS(媒体流服务器)进行房间推流，推送房间信息。
4.2MSS拉取流并传输到浏览器上播放。
本技术是基于3.2进行改进。其中发射端对应助手；接收端对应MTS。具体为：
步骤101，发送端根据音视频数据长度将音视频打包成一个以上的RUDP包，每个RUDP包中的数据均对应不同帧的音视频内容；
对于实时音视频通讯，常采用UDP协议来传输多媒体数据，本发明是采用RUDP协议来传输音视频数据。对于不同格式的编码数据，会有不同的RUDP打包协议，比如对于H.264视频数据，目前已对NALU的RUDP打包封装进行了规范。对于视频数据的打包封装，因为一帧视频数据的数据长度可能大于MTU，所以相关的打包协议都会规定将长度大于MTU的帧进行切割，分块封装到多个RUDP包进行传输。
在切割中，是按照音视频的播放顺序进行切割，所以，能够满足每个RUDP包中的数据均对应不同帧的音视频内容。
步骤102，发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
为了避免丢包、抖动和乱序对服务质量的影响，在发送端和各建立了节点数相等的一段循环buffer，用于缓存发送端数据。
发送端在发送数据的时候，某个RUDP包的seq为send_seq，发送端把这个包通过udpsocket发送出去的同时，把这个RUDP包的数据拷贝到send_seq对应节点的buffer中去，以便这个RUDP包接收方没收到时，发送方还能重发这个RUDP包。
这里要注意的一点是，发送端和接收端的循环buffer节点数要能被65536整除，这样RUDPseq增加到最大值65535时对应最后一个节点，下一个RUDP包的seq为0正好对应上第一个节点，避免RUDPseq掉头时出现漏洞。如图4，发送端循环buffer。
步骤103，接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中；
为了避免丢包、抖动和乱序对服务质量的影响，本方案和发送端类似，接收端也开辟了一段节点数能被65536整除的循环buffer，用于缓存接收到的RUDP包数据。
在收到非第一个包时，接收的模块将接收到的RUDP包拷贝到received_seq指向的节点的buffer，并将这个节点的数据flag(用于标记该节点是否填充了数据)设置为true，同时要根据start_seq、end_seq和received_seq的关系来决定要不要将end_seq更新为received_seq的值，如果received_seq对应的包本来应该end_seq对应的包之前到达，则不更新end_seq的值，否则就更新。通过更新，将缓存中的节点和接收的包进行时刻的对应。
步骤104，接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发。
接收端收到RUDP包时，需要去解析RUDP包头，取出接收到的RUDP包的seq，对应图5中的received_seq。当收到第一个包时，start_seq和end_seq都被设置为received_seq，并把收到的RUDP包送到解码单元。后面接收非第一个包时，收到RUDP包时，要每过一段时间都要去扫描start_seq到end_seq对应的每个节点，首先，若当前时间和start_seq对应的数据到达时间的差值超过一定第一阈值(比如500ms)，则将start_seq和end_seq之间的每个节点的数据全部丢弃，将每个节点的数据flag设置为false，更新start_seq为end_seq。其次，若start_seq对应的节点的下一个节点的数据falg为true，则将该节点的数据送到解码单元，同时将start_seq更新为该节点的seq，并将该节点的数据flag设置为false；若flag为false，且当前时间和start_seq对应的数据到达时间的差值小于第二阈值(比如50ms)，则将该节点的seq(lost_seq)发送给发送端，请求发送端将seq对应的RUDP数据再发一遍。这样，当有些包很久(大于500ms)都没收到，就认为它来不了，直接将它们丢弃；有些包短时间(小于50ms)没来，则向发送端发送重传请求，请求发送端再发一次该包，试图能补上这些包。如图5，接收端循环buffer。
针对上述方法，分别设计对应的发送端、接收端、系统。具体为：
发送端，其执行基于RUDP的音视频可靠传输QOS方法中发送端的程序，对应该程序，其包括：
分析模块，用于分析所述音视频的数据长度；
打包模块，用于根据分析模块分析的数据长度来对音视频进行打包，当所述数据长度大于MTU时，将数据长度大于MTU的帧切割，分块封装到多个RUDP包中；当所述数据长度小于MTU时，将数据直接封装为RUDP包中；
发送模块，用于将RUDP包通过udpsocket发送；
缓存模块，用于在所述发送模块发送的同时，将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收模块，用于接收发送失败的信息，并将所述信息发送给发送模块。
该发送端更具体的细节，可以根据其在方法中作用进行具体限定。
接收端，其执行基于RUDP的音视频可靠传输QOS方法中接收端的程序，对应该程序，其包括：
接收单元，用于接收发送端发送的RUDP包的数据；
缓存单元，用于将接收的所述数据拷贝到接收指令对应循环buffer中；
判断单元，用于根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发；
解码单元，用于对RUDP包的数据进行解码获取音视频；
发送单元，用于向发送端发送重发信息。
其中，判断单元的执行方式为：
当收到第一个所述RUDP包的数据时，包头的start_seq和end_seq都设置为received_seq；
当收到非第一个所述RUDP包时，进行如下操作：
以设定时间段为间隔单位，循环扫描start_seq和end_seq对应的每个节点；
若当前时间和start_seq对应数据到达时间的差值大于第一阈值，则丢弃start_seq和end_seq之间的每个节点的数据，将每个节点的数据flag设置为false，更新start_seq为end_seq；
若当前时间和start_seq对应数据到达时间的小于第一阈值，且start_seq对应的节点的下一个节点的数据falg为true，则将该节点的数据送到解码单元，同时将start_seq更新为该节点的seq，并将该节点的flag设置为false；
若flag为false，且当前时间和start_seq对应的数据到达时间的差值小于第二阈值，则该请求发送端将seq对应的RUDP数据重发。
其中缓存单元执行如下操作：
在收到非第一个包时，接收的模块将接收到的RUDP包拷贝到received_seq指向的节点的buffer，并将这个节点的数据flag(用于标记该节点是否填充了数据)设置为true，同时要根据start_seq、end_seq和received_seq的关系来决定要不要将end_seq更新为received_seq的值，如果received_seq对应的包本来应该end_seq对应的包之前到达，则不更新end_seq的值，否则就更新。通过更新，将缓存中的节点和接收的包进行时刻的对应。
该接收端更具体的细节，可以根据其在方法中作用进行具体限定。
对应基于RUDP的音视频可靠传输QOS方法的系统，其包括:接收端和发送端，其中，
发送端根据音视频数据长度将音视频打包成一个以上的RUDP包，每个RUDP包中的数据均对应不同帧的音视频内容；
发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中；
接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发。
我们的媒体转发系统传输的是视频和音频数据，并且音频数据有天生的优势，那就是数据片段小。而视频数据片段大，特别是I帧(关键帧，属于帧内压缩，保留完整画面)，但是，视频有个特点是可以丢帧，只要播放的时候有I帧等待即可。
那么基于RUDP的QOS保证技术就是一个不同的发送和确认，再发送过程。到超出发送缓冲区就丢掉。这点和TCP是不同的，TCP处理这个是直接报发送超时。加上TCP的滑窗是慢启动的，也带来了网络抖动情况下，视频质量的影响。而RUDP是在适配MTU(最大传输单元)大小的情况下，快速发送，固定滑窗。所以本发明介绍的基于RUDP技术的媒体转发系统中视音频的可靠传输QOS技术保证技术解决了网络传输丢包、抖动和乱序因素对服务质量的不好影响，既能实现数据的实时传输，又能保证数据的可靠性。
没加QOS模块时，两个终端视频通信在有丢包情况下回出现视频帧不完整，播放出现马赛克的现象，本发明中加上QOS模块后，视音频播放流畅，效果大为改善。同时我们为了测试该方案的作用，在发送端人为地分别丢弃10％和20％的视频RUDP包，接收端解码播放效果良好，没有出现马赛克现象。
尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (10)

1.一种基于RUDP的音视频可靠传输QOS方法，其特征在于，包括：
发送端根据音视频数据长度将音视频打包成一个以上的RUDP包，每个RUDP包中的数据均对应不同帧的音视频内容；
发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中；
接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发。
2.如权利要求1所述的基于RUDP的音视频可靠传输QOS方法，其特征在于，
所述发送指令对应循环buffer的节点数、所述接收指令对应循环buffer的节点数相等，且均为65536的整数倍。
3.如权利要求1所述的基于RUDP的音视频可靠传输QOS方法，其特征在于，所述发送端根据音视频数据长度将音视频打包成一个以上的RUDP包包括：
分析所述音视频的数据长度；
当所述数据长度大于MTU时，将数据长度大于MTU的帧切割，分块封装到多个RUDP包中；
当所述数据长度小于MTU时，将数据直接封装为RUDP包中。
4.如权利要求1所述的基于RUDP的音视频可靠传输QOS方法，其特征在于，所述发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发包括：
从打包的多个RUDP包中提取一个RUDP包；
将所述RUDP包的seq设置为send_seq，通过udpsocket发送给接收端；
在发送同时，将所述RUDP包拷贝到所述send_seq对应节点的循环buffer中，以备接收端未成功接收时，调用重发。
5.如权利要求1所述的基于RUDP的音视频可靠传输QOS方法，其特征在于，所述接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中包括：
接收端接收所述RUDP包的数据；
解析数据的RUDP包头，设置received_seq，并将数据拷贝到received_seq对应循环buffer中，并将该节点的数据flag设置为true；
若received_seq对应的RUDP包的到达时间晚于end_seq对应包的到达时间，则更新end_seq，否则不更新。
6.如权利要求1所述的基于RUDP的音视频可靠传输QOS方法，其特征在于，接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式包括：
当收到第一个所述RUDP包的数据时，包头的start_seq和end_seq都设置为received_seq；
当收到非第一个所述RUDP包时，进行如下操作：
以设定时间段为间隔单位，循环扫描start_seq和end_seq对应的每个节点；
若当前时间和start_seq对应数据到达时间的差值大于第一阈值，则丢弃start_seq和end_seq之间的每个节点的数据，将每个节点的数据flag设置为false，更新start_seq为end_seq；
若当前时间和start_seq对应数据到达时间的小于第一阈值，且start_seq对应的节点的下一个节点的数据falg为true，则将该节点的数据送到解码单元，同时将start_seq更新为该节点的seq，并将该节点的flag设置为false；
若flag为false，且当前时间和start_seq对应的数据到达时间的差值小于第二阈值，则该请求发送端将seq对应的RUDP数据重发。
7.一种基于RUDP的音视频可靠传输QOS的发送端，其特征在于，包括：
分析模块，用于分析所述音视频的数据长度；
打包模块，用于根据分析模块分析的数据长度来对音视频进行打包，当所述数据长度大于MTU时，将数据长度大于MTU的帧切割，分块封装到多个RUDP包中；当所述数据长度小于MTU时，将数据直接封装为RUDP包中；
发送模块，用于将RUDP包通过udpsocket发送；
缓存模块，用于在所述发送模块发送的同时，将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收模块，用于接收发送失败的信息，并将所述信息发送给发送模块。
8.一种基于RUDP的音视频可靠传输QOS的接收端，其特征在于，包括：
接收单元，用于接收发送端发送的RUDP包的数据；
缓存单元，用于将接收的所述数据拷贝到接收指令对应循环buffer中；
判断单元，用于根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发；
解码单元，用于对RUDP包的数据进行解码获取音视频；
发送单元，用于向发送端发送重发信息。
9.如权利要求8所述的基于RUDP的音视频可靠传输QOS的接收端，其特征在于，所述判断单元的执行方式为：
当收到第一个所述RUDP包的数据时，包头的start_seq和end_seq都设置为received_seq；
当收到非第一个所述RUDP包时，进行如下操作：
以设定时间段为间隔单位，循环扫描start_seq和end_seq对应的每个节点；
若当前时间和start_seq对应数据到达时间的差值大于第一阈值，则丢弃start_seq和end_seq之间的每个节点的数据，将每个节点的数据flag设置为false，更新start_seq为end_seq；
若当前时间和start_seq对应数据到达时间的小于第一阈值，且start_seq对应的节点的下一个节点的数据falg为true，则将该节点的数据送到解码单元，同时将start_seq更新为该节点的seq，并将该节点的flag设置为false；
若flag为false，且当前时间和start_seq对应的数据到达时间的差值小于第二阈值，则该请求发送端将seq对应的RUDP数据重发。
10.一种基于RUDP的音视频可靠传输QOS系统，其特征在于，包括:接收端和发送端，其中，
发送端根据音视频数据长度将音视频打包成一个以上的RUDP包，每个RUDP包中的数据均对应不同帧的音视频内容；
发送端将RUDP包通过udpsocket发送，并同时将所述RUDP包拷贝到发送指令对应循环buffer中，以备发送失败时调用重发；
接收端接收所述RUDP包的数据，并同时将接收的所述数据拷贝到接收指令对应循环buffer中；
接收端根据循环buffer中节点填充情况和节点接收时间确定接收指令对应循环buffer中数据的处理方式，所述处理方式包括：丢弃、解码或重发。
CN201511005154.0A 2015-12-28 2015-12-28 基于rudp的音视频可靠传输qos方法、接收端及系统 Active CN105611424B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201511005154.0A CN105611424B (zh) 2015-12-28 2015-12-28 基于rudp的音视频可靠传输qos方法、接收端及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201511005154.0A CN105611424B (zh) 2015-12-28 2015-12-28 基于rudp的音视频可靠传输qos方法、接收端及系统

Publications (2)

Publication Number Publication Date
CN105611424A true CN105611424A (zh) 2016-05-25
CN105611424B CN105611424B (zh) 2019-04-05

Family

ID=55990909

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201511005154.0A Active CN105611424B (zh) 2015-12-28 2015-12-28 基于rudp的音视频可靠传输qos方法、接收端及系统

Country Status (1)

Country Link
CN (1) CN105611424B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107454432A (zh) * 2017-07-26 2017-12-08 北京疯景科技有限公司 数据发送方法及装置
CN113228596A (zh) * 2018-12-04 2021-08-06 区块链联合香港有限公司 传输列表信息的方法和装置
CN114640724A (zh) * 2020-11-30 2022-06-17 腾讯科技（深圳）有限公司 基于rudp的数据传输方法、装置、设备及计算机存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5822524A (en) * 1995-07-21 1998-10-13 Infovalue Computing, Inc. System for just-in-time retrieval of multimedia files over computer networks by transmitting data packets at transmission rate determined by frame size
CN103188716B (zh) * 2011-12-29 2018-08-03 中兴通讯股份有限公司 Rudp链路故障定位方法及装置
CN103780971A (zh) * 2012-10-23 2014-05-07 北京网动网络科技股份有限公司 一种互联网条件下基于rudp的实时视频传输方法
CN103096183B (zh) * 2013-02-05 2015-12-09 清华大学 一种高效流媒体传输方法

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107454432A (zh) * 2017-07-26 2017-12-08 北京疯景科技有限公司 数据发送方法及装置
CN107454432B (zh) * 2017-07-26 2021-04-20 北京疯景科技有限公司 数据发送方法及装置
CN113228596A (zh) * 2018-12-04 2021-08-06 区块链联合香港有限公司 传输列表信息的方法和装置
US11838349B2 (en) 2018-12-04 2023-12-05 Hong Kong Sunstar Technology Co., Limited Method and device for transmitting list information
CN113228596B (zh) * 2018-12-04 2024-04-02 香港星辰科技有限公司 传输列表信息的方法和装置
CN114640724A (zh) * 2020-11-30 2022-06-17 腾讯科技（深圳）有限公司 基于rudp的数据传输方法、装置、设备及计算机存储介质
CN114640724B (zh) * 2020-11-30 2023-11-28 腾讯科技（深圳）有限公司 基于rudp的数据传输方法、装置、设备及计算机存储介质

Also Published As

Publication number Publication date
CN105611424B (zh) 2019-04-05

Similar Documents

Publication Publication Date Title
CN101552660B (zh) 对流媒体数据进行重传、播放的方法、装置及通信系统
CN110474721B (zh) 视频数据传输方法、装置及计算机可读存储介质
CN104782133A (zh) 用于媒体数据递送控制的方法和装置
JP2004187286A (ja) エンド−トゥ−エンドビットレート基準の輻輳制御を備えた、無線ネットワークにおけるｍｐｅｇ−４ライブユニキャストビデオストリーミングシステム
US10044831B2 (en) Method and apparatus for transmitting messages to a dash client
JP2024509728A (ja) データ再送処理方法、装置、コンピュータ機器及びコンピュータプログラム
WO2019149053A1 (zh) 一种基于融合传输系统的数据传输方法
CN105530553A (zh) Rtmp与rudp结合的实时流媒体直播系统
CN110113662A (zh) 一种适应多种网络状况的视频监控客户端系统
CN111629280B (zh) 丢包处理方法、装置及可读存储介质
CN105611424A (zh) 基于rudp的音视频可靠传输qos方法、系统
CN114221909B (zh) 数据传输方法、装置、终端及存储介质
CN110138513B (zh) 一种数据传输方法和视联网系统
CN111478880B (zh) 一种数据处理的方法和装置
EP1802121A2 (en) Information provisioning device and method
CN111245733A (zh) 一种数据传输的方法和装置
KR102302772B1 (ko) 레이트 페이싱을 위해 버퍼를 관리하는 장치 및 방법
CN101645903A (zh) 一种多媒体数据的传输方法及装置
Kim et al. An efficient delay-constrained ARQ scheme for MMT packet-based real-time video streaming over IP networks
US10334086B2 (en) Header redundancy removal for tunneled media traffic
CN110086772B (zh) 一种监控视频的获取方法和系统
CN112165655A (zh) 基于视联网的数据传输方法、装置、设备及介质
US20190222872A1 (en) Playout buffering in a live content distribution system
CN110830160A (zh) 一种数据包的传输方法和装置
JP6970124B2 (ja) Ｍｍｔｐパケットを送受信する方法及びその装置

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