CN103780971A - 一种互联网条件下基于rudp的实时视频传输方法 - Google Patents

Abstract

本发明公开了一种基于RUDP的实时视频传输方法，采用客户端/服务器(C/S)结构模型，该技术方案的具体步骤包括视频数据分发、丢包检测、接收报告、丢包恢复、接收端数据排序和解码显示等。本发明能够解决互联网条件下，因为网络拥塞，数据包丢失等问题导致的视频接收延迟、停顿、画面出现马赛克、花屏等问题。主要优点在于，无需通过额外的投入改进用户现有的网络条件，用户利用现有的网络环境能获取更清晰更流畅的视频通信效果。

Description

一种互联网条件下基于RUDP的实时视频传输方法

技术领域

本发明涉及视频传输领域，尤其涉及一种基于RUDP的实时视频传输方法。

背景技术

目前，视频通信的发展方向具有普及化、多终端、多网络化、高清化的特点。这对视频通信的网络载体提出更高要求，即更高更稳定的网络带宽保障和多种网络(如企业专网、ADSL、3G网路等)的高效互联。虽然目前互联网带宽已经有很大改善，但仍然存在不同运营商之间互通性差，同一运营商由于地域的不同，也很难有稳定的带宽保障。因此，如何在不稳定的互联网带宽条件下获得清晰流畅而且实时的视频通信质量，是一个相当大的技术难题。

主流的视频通信在网络协议层面上讲，分为UDP(用户数据报)协议和TCP(传输控制)协议，UDP协议传输的特点是数据实时到达，但不保证能传到，网络带宽抖动时有可能丢失；TCP协议传输的特点是数据传输可靠，但在网络条件下将时，有可能延迟到达，在某些情况下，会导致数据拥塞而使网络连接断开，并无法继续传输数据。

目前，现有技术中解决以上问题主要有两种技术方案：

一是对网络链路提供QOS(服务质量)保障。无论采用哪种通信协议，视频传输都是有保障的，但是整个传输过程都是依赖于数据链路中间的网关、路由等设备提供可靠服务质量。在现阶段，互联网运营商还无法为大规模用户提供类似的服务，一般只能在专有网络内部提供QOS服务，而且建设成本相当高，使用范围有相当大的局限性。

二是根据网络状况来动态调整当前发送的数据流量。这种方案需要统计各个接收点的丢包率，再综合调整数据发送的带宽，但当接收点数量比较多时，由于各个接收点网络状况可能差别较大，有的地方带宽好，有的地方带宽差，如果按照某一个值去调整发送带宽的话，则会导致带宽好的地方本应该收到高质量视频，调整后收到的视频质量降低，而带宽差的地方仍然有可能收不到流畅的视频。另外，网络的抖动往往具有瞬时性和间歇性，而带宽的统计在时间上会有一定的滞后，很难保证同一时间点上调整的带宽和用户实际的网络状况一致。这种方案比较适合少量参与者的交互视频通信，很难适应大规模的视频会议等应用。

本发明的目的就是在最大程度上利用现有网络带宽条件，获取高质量的视频通信效果，即获得清晰流畅的实时视频通信效果同时，用户也无需增加另外的投入来升级现有的网络设备和增加互联网接入带宽。

发明内容

本发明提供一种基于RUDP(可靠的UDP传输协议)的实时视频传输方法，采用客户端/服务器(C/S)结构模型，具体包括以下步骤：(a)数据分发：每路视频数据的分发，先是由发送端传输到分发服务器，再由分发服务器传输到各接收端；(b)丢包检测：针对数据发送端，采用发送端主动检测模式，针对接收端，则采用被动检测模式；(C)接收报告：接收端定时(2秒)向发送端报告数据包接收情况，如恢复前的丢包率和恢复后的丢包率太高，则停止恢复，同时将这些信息反馈到客户机UI操作界面。(d)丢包恢复：根据重传数据包的重传次数及丢包率进行数据重传；(e)接收端数据排序：在接收端利用数据接收缓存对视频帧数据进行排序，并增加相应的超时机制；(f)将已经按序接收完的视频帧和等待超时后的视频帧数据进行解码器解码显示。

所述的数据分发包括：发送端在数据发送初期建立固定大小的发送窗口，对每个发送的数据包进行顺序编号，已发送的数据包按编号从小到大缓存在发送窗口中，该缓存大小以时间为依据，缓存时间为300毫秒，新建立的数据在发送的同时添加到发送窗口队列的最前端，而在窗口队列中最后端保留时间超过300毫秒的数据自动丢弃。

所述的发送端主动检测模式为：服务器作为接收端每接收10毫秒数据报告一次已接收的数据包编号，发送端再根据报告的情况，主动检测哪些数据包丢失，并在发送窗口中查找相应编号的数据，重新发送给服务器。

所述的接收端被动检测模式为：服务器作为发送端只是实时转发数据包并动态滑动数据发送窗口，接收端根据已接收的数据包编号，每30毫秒检测一次哪些数据包丢失，并将丢包信息发送给服务器，服务器被动接收丢包信息，在发送窗口中查找这些数据包编号并重新发送。

所述的丢包恢复包括：记录每个重传数据包的重传次数，如果超过2次，则不再进行重传，同时，根据接收报告，如果丢包率超过20％，则停止丢包检测，不再进行重传，待丢包率小于20％，再重新开始检测和恢复工作。

本发明所提供的视频传输方法能够解决互联网条件下，视频传输因为网络拥塞，数据包丢失等问题导致的视频接收延迟、停顿、画面出现马赛克、花屏等问题。

与现有技术相比，本发明的主要优点在于，无需通过额外的投入改进用户现有的网络条件，用户利用现有的网络环境能获取更清晰更流畅的视频通信效果；另外，本发明的技术方案可以让用户使用固定的视频传输质量，无需经常调节，操作方面也更加便捷。

附图说明

附图1所示为本发明技术方案的网络结构示意图。

附图2所示为本发明技术方案的发送端到数据分发服务器数据流示意图。

附图3所示为本发明技术方案的数据分发服务器到接收端数据流示意图。

具体实施方式

本发明利用UDP传输协议的实时性，首先保证了视频传输的实时到达，另外在通信过程中增加相应的丢包补偿机制，很大程度上改善了传输的可靠性，业内称此技术为RUDP(可靠的UDP传输协议)。目前此项技术已成功应用于自主研发的网动多媒体视频会议***、LiveUC云会议***、网动远程视频监控***等产品中，取得了相当好的效果；使用此项技术后，和市面上其他同类产品比较，很大程度上提高了市场竞争力。

以下结合附图对本发明的技术方案做进一步说明。

如附图1所示的本发明的网络结构示意图。本发明总体上采用客户端/服务器(C/S)结构。具体包括以下步骤：

数据的分发。每路视频数据的分发，是由发送端传输到分发服务器，再由分发服务器传输到各接收端，实现一点对多点的视频通信功能，当然对于集群服务器结构，也会存在分发服务器将数据转发到另外一个分发服务器再发送到客户端的情况。

发送端在数据发送初期建立固定大小的发送窗口，对每个发送的数据包进行顺序编号，已发送的数据包按编号从小到大缓存在发送窗口中，该缓存大小以时间为依据，缓存时间为300毫秒，这个也是接收端视频延迟的最大值，新建立的数据在发送的同时添加到发送窗口队列的最前端，而在窗口队列中最后端保留时间超过300毫秒的数据自动丢弃。

丢包检测。由于处理数据量大小所承担的负荷不同，可以分为主动检测模式和被动检测模式，对于分发服务器，由于面对的是多路的上传数据和更多路的数据下发，数据处理量大，所以针对数据发送端，采用发送端主动检测模式，如附图2所示，即服务器作为接收端，每接收10毫秒数据报告一次已接收的数据包编号，发送端再根据报告的情况，主动检测哪些数据包丢失，并在发送窗口中查找相应编号的数据，重新发送给服务器。而针对接收端，则采用被动检测模式，如附图3所示，即服务器作为发送端，只是实时转发数据包并动态滑动数据发送窗口，接收端根据已接收的数据包编号，每30毫秒检测一次哪些数据包丢失，并将丢包信息发送给服务器，服务器被动接收丢包信息，在发送窗口中查找这些数据包编号并重新发送。

接收报告。无论是服务器作为接收端还是客户机作为接收端，都须定时(2秒)向发送端报告数据包接收情况，如恢复前的丢包率和恢复后的丢包率，如果丢包率太高，说明网络状况恶化，则停止恢复，另外如果将这些信息反馈到客户机UI操作界面，则用户可以清楚知道当前网络状况，并对网络状况或者发送数据的带宽作出相应调整。

丢包恢复。从以上丢包重传机制可以看出，即使已丢失的数据包进行了重传，也并不能保证第二次能收到，另外如果接收端丢失的数据包比例较高，如超过20％，如果将这些数据包都重新发送，则无疑会增加发送端20％的带宽，这样可能会导致本身较差的接收状况变得更加恶化，从而使得丢包率进一步上升，因此在数据恢复过程中增加了恢复策略，一方面，记录每个重传数据包的重传次数，如果超过2次，则不再进行重传，另一方面，根据接收报告，如果丢包率超过20％，则停止丢包检测，不再进行重传，待网络状况好转后(丢包率小于20％)，可以重新开始检测和恢复工作。

接收端数据排序。由于采用了丢包重传机制，有可能会导致接收端完整接收视频帧的顺序发生变化，即先发送的视频帧后接收完成，因此在接收端需要额外的数据接收缓存来针对视频帧数据排序，并增加相应的超时机制。

解码显示。已经按序接收完的视频帧和等待超时后的视频帧数据才可以通过解码器解码显示。

本发明的技术方案以UDP Socket为基础在其上层单独封装了RUDP层数据发送和接收协议，以C/C++编程语言来实现整个通信流程。

以下是以C++编程语言来实现的程序流程：

目前，发明的技术方案已经运用到多款视频通信***中，尤其网动多媒体视频会议***、LiveUC云会议***、网动远程视频监控***等产品中，取得了相当好的效果；在实际环境中，能恢复20％的网络丢包率，很好的解决了因网络抖动、带宽不稳定因素导致的视频延迟、停顿、马赛克等问题，和市面上其他同类产品比较，很大程度上提高了市场竞争力。

以上所述仅为本发明的优选实施例而已，并不限制于本发明，对于本领域技术人员而言，本发明可以有各种改变和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种基于RUDP的实时视频传输方法，采用客户端/服务器(C/S)结构模型，其特征在于，包括以下步骤：(a)数据分发：每路视频数据的分发，先是由发送端传输到分发服务器，再由分发服务器传输到各接收端；(b)丢包检测：针对数据发送端，采用发送端主动检测模式，针对接收端，则采用被动检测模式；(C)接收报告：接收端定时(2秒)向发送端报告数据包接收情况，如恢复前的丢包率和恢复后的丢包率太高，则停止恢复，同时将这些信息反馈到客户机UI操作界面。(d)丢包恢复：根据重传数据包的重传次数及丢包率进行数据重传；(e)接收端数据排序：在接收端利用数据接收缓存对视频帧数据进行排序，并增加相应的超时机制；(f)将已经按序接收完的视频帧和等待超时后的视频帧数据进行解码器解码显示。

2.根据权利要求1所述的传输方法，其特征在于，所述的数据分发包括：发送端在数据发送初期建立固定大小的发送窗口，对每个发送的数据包进行顺序编号，已发送的数据包按编号从小到大缓存在发送窗口中，该缓存大小以时间为依据，缓存时间为300毫秒，新建立的数据在发送的同时添加到发送窗口队列的最前端，而在窗口队列中最后端保留时间超过300毫秒的数据自动丢弃。

3.根据权利要求1所述的传输方法，其特征在于，所述的发送端主动检测模式为：服务器作为接收端每接收10毫秒数据报告一次已接收的数据包编号，发送端再根据报告的情况，主动检测哪些数据包丢失，并在发送窗口中查找相应编号的数据，重新发送给服务器。

4.根据权利要求1所述的传输方法，其特征在于，所述的接收端被动检测模式为：服务器作为发送端只是实时转发数据包并动态滑动数据发送窗口，接收端根据已接收的数据包编号，每30毫秒检测一次哪些数据包丢失，并将丢包信息发送给服务器，服务器被动接收丢包信息，在发送窗口中查找这些数据包编号并重新发送。

5.根据权利要求1所述的传输方法，其特征在于，所述的丢包恢复包括：记录每个重传数据包的重传次数，如果超过2次，则不再进行重传，同时，根据接收报告，如果丢包率超过20％，则停止丢包检测，不再进行重传，待丢包率小于20％，再重新开始检测和恢复工作。

Images