一种提升低速网络中RTP视频流处理效率的方法

摘要

本发明公开了一种提升低速网络中RTP视频流处理效率的方法，视频采集端负责视频数据的实时获取；视频编码打包模块首先对视频数据进行压缩编码，形成标准的H.264格式的视频，再对压缩后的视频进行RTP封装打包，将打包后的数据送往网络缓存区；网络发送端获取共享的网络缓存区中的RTP包数据，生成RTP帧数据，通过基础网络将多对TCP套接字对上传到网络发送端上；网络接收端作为视频服务器，通过与网络发送端建立多对TCP套接字来传送RTP数据。实现了多对套接字共同传输实时RTP流，合理地合并多个小RTP包一次传输，提高了带宽利用率和网络传输效率，有效解决视频流实时传输导致的丢帧、卡顿及花屏等问题。

说明书

技术领域

本发明涉及一种网络传输方法，尤其涉及的是一种提升低速网络中RTP视频流处理效率 的方法。

背景技术

随着3G网络的普及和LTE时代的到来，人们希望能随时获取到音视频等多媒体信息。RTP 协议就是为支持多媒体通信而设计的网络传输协议，从而使流媒体播放器在各种网络终端上 得到普遍应用。

RTP封装的数据包易于在网络上传输，其序列号字段和时间戳字段保证接收端能实现丢 包检测和包顺序的恢复。在RTP/RTSP协议中，RTP数据包和RTCP数据包都采用UDP协议传 输，RTCP数据包用于实时监控数据传输质量和拥塞控制。UDP是基于消息的方式传送数据包， 传送速度快，但不提供消息的确认与重传机制，不提供流量的拥塞控制，因此在低速网络中 容易导致丢包和乱序到达，影响实时音视频传输的用户体验。

低速网络传输通常是基于无线广域网。由于低速网络的带宽限制，数据包传送速率慢， 且容易因网络状况不稳定而产生波动。传输通道更有可能受信号覆盖、自然环境、用户稠密 度、业务时间段等影响。因此低速网络的流媒体传输需要将多媒体的编解码和传输技术很好 地结合在一起，才能确保用户在复杂的网络环境下也能得到稳定的音视频播放质量。

发明内容

本发明的目的在于克服现有技术的不足，提供了一种提升低速网络中RTP视频流处理效 率的方法，解决基于RTP/RTCP传输技术容易产生的丢包、卡顿问题，提升了数据传输的稳定 性和带宽利用效率。

本发明是通过以下技术方案实现的，本发明包括以下步骤：

（1）视频采集端负责视频数据的实时获取；

（2）视频编码打包模块首先对视频数据进行压缩编码，形成标准的H.264格式的视频， 再对压缩后的视频进行RTP封装打包，形成适合网络传输的RTP视频流，将打包后的数据送 往网络缓存区；

（3）网络缓存区是编码打包模块与网络发送端之间共享的环形缓存存储区域，网络发 送端获取共享的网络缓存区中的RTP包数据，生成RTP帧数据，通过基础网络的多对TCP套 接字对将RTP数据帧上传到网络接收端上；

（4）网络接收端作为视频服务器，通过与网络发送端建立多对TCP套接字来接收RTP 数据帧并完成帧的分解、RTP包解析和H.264视频的播放。

所述网络发送端与网络接收端之间采用基于连接的TCP传输层协议传输RTP数据帧，通 信双方通过TCP报文协商来确定双方采用的传输线程数目、每个线程的TCP传输连接数目以 及每个传输连接双方所采用的TCP端口。

在低速网络中，如果采用UDP传输，发送方有数据则直接发送且无需确认接收方是否能 正确接收数据，从而导致数据包丢包和乱序到达的现象比较严重，影响视频播放的质量。如 果采用TCP的传输方式，依靠TCP的重传、确认和流量控制机制，实现数据的可靠传输，从 而减少数据包的丢失，减少低速网络中多种网络环境因素可能对视频传输产生的干扰。与UDP 相比，TCP传输方式对可靠性的保障会影响传输的效率，特别是在低速网络中，很容易因为 速率不够导致实时视频播放的卡顿，因此必须有效地提高带宽的利用率。本发明的网络发送 端与网络接收端采用多线程多连接，一方面提高网络带宽的利用效率，另一方面也提高通信 双方操作系统分配的CPU处理时间。

所述TCP报文协商的具体过程为：处于广域网的一端首先创建TCP套接字sock1并进入 监听状态，处于局域网的一端向sock1发起连接，通过此连接传输协商参数，即协商连接； 用户在网络发送端获取用户设置的线程数，每个线程连接数以及每个连接双方所采用的端口 组装成报文1后发送，通过协商连接发送给网络接收端，网络接收端接收到报文1并解析到 协商参数后，先后建立对应数目的接收线程数，在每个线程中使用协商的端口进行TCP监听， 如果所有协商参数生效成功则通过协商连接返回设置成功，如果出现协商端口被占用，则自 动递增获取一个可用端口并进行监听，并将生效的端口信息通过协商连接返回给发送端，从 而建立好数据传输通道。

H.264流中常会连续出现多帧长度较小的P图像帧，对应的RTP流中就会出现长度较小 的RTP数据包以及长度较小的音频信息和私有封装子信息。为提升连续出现的小RTP包的传 输效率，并在接收端与发送端之间形成足够的视频数据的缓冲，在本发明中通过合并小RTP 包实现并包传输，以减少传输层发送帧、确认帧的数目，从而进一步提高传输的效率。

所述视频数据的传输通过合并缓存区已有的、连续的、长度较小的RTP包实现并包传输， 以RTP包为最小单元，RTP包前添加N字节RTP长度信息，按时间顺序依次将一个或多个RTP 包拼接起来，在首部封装头部信息，形成RTP数据帧，以RTP数据帧的形式实现数据的发送 与接收；对网络缓存区已有的RTP数据进行封包并立即发送，若网络缓存区已没有新数据， 即使已有数据帧总长度很小，也不必等待网络缓存区的下一包数据；所述RTP数据帧的帧头 信息包含帧序列号、帧长度信息和RTP数据帧所包含的RTP数据包个数。

所述RTP数据帧的总长度根据网络最大传输路径单元MSS的长度来确定，单个RTP包的 最大长度与帧头长度之和或小于等于数据帧的最大长度限定值；拼接起来的若干RTP数据包 的长度与帧头长度之和小于或等于RTP数据帧的最大长度限定值，数据帧的最大长度限定值 不超过底层MSS的N倍，1≤N≤5。从而减少IP层分片传输的次数以及发送和接收端网络缓 存区上下文切换的次数。以太网中典型的MSS值为1460字节。

所述RTP长度的判断方法如下：

循环检测并读取缓存区中等待传输的RTP数据包并对RTP长度进行判断；若仅有一包等 待传输，则仅将此包封装成RTP数据帧并发送；若有N个RTP包等待传输且长度之和小于RTP 数据帧的限定值，则将此N个RTP合并封装成RTP数据帧并发送；若有N个RTP包等待传输 且长度之和超过RTP数据帧的限定值，则仅将部分RTP包合并封装成RTP数据帧并发送，将 超过限定值的部分RTP包与下一次读取到的RTP数据合并后再重新判断封包。

与UDP基于消息的传输方式不同，TCP是基于字节流的传输协议，有时会出现发送端的 若干包数据到接收端时粘在一起形成一个数据包。本发明由于最大限度的提高网络带宽利用 效率，故TCP的流量控制会频繁地将数据帧粘起来发送。为解决此问题，所述网络接收端对 网络数据流进行分解接收工作和RTP数据包的解封装工作：对每一个RTP帧分两次读取，首 先读取RTP数据帧的首部信息，确定RTP数据帧的序号、数据帧的长度以及此数据帧包含多 少个RTP包信息，再根据数据帧的长度去读取剩余的数据帧。

在低速网络中，数据包到达网络接收端是一个明显的过程，从数据包的首部移入网络接 收端的网络缓存区到数据包的最后一个字节到达网络接收端的网络缓存区是一个可以明显 感知到的过程。所述网络接收端在读取网络缓存区的时候要等待数据均到达网络缓存区后再 去读取，具体步骤如下：

设RTP数据帧的首部长度为N字节，网络接收端在网络缓存区发现有网络数据到达后， 先判断网络缓存区是否有超过N个字节可读，如果超过N个字节可读，读取N字节并分解获 得帧首部信息；如果不够N字节则延时一毫秒后继续判断缓存区可读的数据长度，循环等待 直到有超过N字节可读为止；获得帧长度信息后，判断缓存区剩余可读数据的长度，如果达 到帧的长度，读取此帧，如果缓存区剩余可读数据的长度没有达到帧的长度，延时一毫秒后 继续判断缓存区可读数据长度，循环等待直到有超过N字节可读为止，至此一帧数据读取完 成。

网络接收端与发送端建立了多对套接字连接，数据帧在广域网传输过程中可能会出现接 收乱序现象，原因在于，一方面数据包在广域网中传输会出现不同程度的延时，后发送的数 据可能会先到达；另一方面如果有若干帧数据均已到达接收端，而接收端在接收数据时无法 判断先接收哪一帧数据，可能会出现先到达接收端的数据却后被处理的情况。为解决此问题， 所述网络接收端与发送端建立了多对套接字连接，通过select端口模型监控套接字数据的 到达情况，对获取到的数据进行顺序重建，具体步骤如下：

a、通过链表管理接收到的RTP帧，根据Frame NO.字段递增依次将连续的链表节点送入 播放器；

b、播放器缓存区是一个先进先出的FIFO结构，对送进来的每一个RTP帧分解成一个或 多个RTP包，再对RTP包解析成H.264格式可播放的NALU裸流数据，最后将完整的NALU帧 送入播放库进行显示；

c、将每个从网络缓存区接收到的一帧数据，建立一个链表节点，并根据Frame NO.值插 入到链表中，如果有Frame NO.重复的帧则丢弃，如果Frame NO.小于已送入播放器的帧的 Frame NO.则丢弃；

d、根据select监控套接字到达，如果仅有一个套接字可读，则读取此套接字的一帧数 据后，建立一个链表节点并插入链表，如果多个套接字可读，则依次读取每一个套接字的帧 数据，对每个RTP帧建立链表节点，并插入链表。

本发明相比现有技术具有以下优点：本发明实现了多对套接字共同传输实时RTP流，合 理地合并多个小RTP包一次传输，接收端通过乱序重组、分解得到视频流数据，提高了带宽 利用率和网络传输效率，有效解决视频流实时传输导致的丢帧、卡顿及花屏等问题。

附图说明

图1是本发明的结构示意图；

图2是对RTP包数据合并成RTP帧数据的示意图。

具体实施方式

下面对本发明的实施例作详细说明，本实施例在以本发明技术方案为前提下进行实施， 给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。

如图1和图2所示，本实施例包括视频采集端1、视频编码打包模块2、网络发送端3、 网络接收端4和基础网络5，

（1）视频采集端1负责视频数据的实时获取；

（2）视频编码打包模块2首先对视频数据进行压缩编码，形成标准的H.264格式的视 频，再对压缩后的视频进行RTP封装打包，形成适合网络传输的RTP视频流，将打包后的数 据送往网络缓存区；

（3）网络缓存区是编码打包模块与网络发送端3之间共享的环形缓存存储区域，网络 发送端3获取共享的网络缓存区中的RTP包数据，生成RTP帧数据，通过基础网络5的多对 TCP套接字对将RTP数据帧上传到网络接收端4上；

（4）网络接收端4作为视频服务器，通过与网络发送端3建立多对TCP套接字来接收 RTP数据帧并完成帧的分解、RTP包解析和H.264视频的播放。

所述网络发送端3与网络接收端4之间采用基于连接的TCP传输层协议传输RTP数据帧， 通信双方通过TCP报文协商来确定双方采用的传输线程数目、每个线程的TCP传输连接数目 以及每个传输连接双方所采用的TCP端口。

所述TCP报文协商的具体过程为：处于广域网的一端首先创建TCP套接字sock1并进入 监听状态，处于局域网的一端向sock1发起连接，通过此连接传输协商参数，即协商连接； 用户在网络发送端3获取用户设置的线程数，每个线程连接数以及每个连接双方所采用的端 口组装成报文1后发送，通过协商连接发送给网络接收端4，网络接收端4接收到报文1并 解析到协商参数后，先后建立对应数目的接收线程数，在每个线程中使用协商的端口进行TCP 监听，如果所有协商参数生效成功则通过协商连接返回设置成功，如果出现协商端口被占用， 则自动递增获取一个可用端口并进行监听，并将生效的端口信息通过协商连接返回给发送 端，从而建立好数据传输通道。

所述视频数据的传输通过合并缓存区已有的、连续的、长度较小的RTP包实现并包传输， 以RTP包为最小单元，RTP包前添加N字节RTP长度信息，按时间顺序依次将一个或多个RTP 包拼接起来，在首部封装头部信息，形成RTP数据帧，以RTP数据帧的形式实现数据的发送 与接收；对网络缓存区已有的RTP数据进行封包并立即发送，若网络缓存区已没有新数据， 即使已有数据帧总长度很小，也不必等待网络缓存区的下一包数据；所述RTP数据帧的帧头 信息包含帧序列号、帧长度信息和RTP数据帧所包含的RTP数据包个数。具体合并过程如图 2所示，RTP包数据包括RTP Header和RTP Data，需要将总长度添加到RTP Length字段形 成RTP Group，控制若干RTP Group的总长度。生成Frame Header需要添加Frame NO.帧标 识字段，表示RTP Frame的先后顺序，以便在网络接收端4进行乱序的重组，从而避免视频 播放的花屏。

所述RTP数据帧的总长度根据网络最大传输路径单元MSS的长度来确定，单个RTP包的 最大长度与帧头长度之和或小于等于数据帧的最大长度限定值；拼接起来的若干RTP数据包 的长度与帧头长度之和小于或等于RTP数据帧的最大长度限定值，数据帧的最大长度限定值 不超过底层MSS的N倍，1≤N≤5，N通常取1或2，从而减少IP层分片传输的次数以及发 送和接收端网络缓存区上下文切换的次数。

所述RTP长度的判断方法如下：

循环检测并读取缓存区中等待传输的RTP数据包并对RTP长度进行判断；若仅有一包等 待传输，则仅将此包封装成RTP数据帧并发送；若有N个RTP包等待传输且长度之和小于RTP 数据帧的限定值，则将此N个RTP合并封装成RTP数据帧并发送；若有N个RTP包等待传输 且长度之和超过RTP数据帧的限定值，则仅将部分RTP包合并封装成RTP数据帧并发送，将 超过限定值的部分RTP包与下一次读取到的RTP数据合并后再重新判断封包。

所述网络接收端4对网络数据流进行分解接收工作和RTP数据包的解封装工作：对每一 个RTP帧分两次读取，首先读取RTP数据帧的首部信息，确定RTP数据帧的序号、数据帧的 长度以及此数据帧包含多少个RTP包信息，再根据数据帧的长度去读取剩余的数据帧。

所述网络接收端4在读取网络缓存区的时候要等待数据均到达网络缓存区后再去读取， 具体步骤如下：

设RTP数据帧的首部长度为N字节，网络接收端4在网络缓存区发现有网络数据到达后， 先判断网络缓存区是否有超过N个字节可读，如果超过N个字节可读，读取N字节并分解获 得帧首部信息；如果不够N字节则延时一毫秒后继续判断缓存区可读的数据长度，循环等待 直到有超过N字节可读为止；获得帧长度信息后，判断缓存区剩余可读数据的长度，如果达 到帧的长度，读取此帧，如果缓存区剩余可读数据的长度没有达到帧的长度，延时一毫秒后 继续判断缓存区可读数据长度，循环等待直到有超过N字节可读为止，至此一帧数据读取完 成。

所述网络接收端4与发送端建立了多对套接字连接，通过select端口模型监控套接字 数据的到达情况，对获取到的数据进行顺序重建，具体步骤如下：

a、通过链表管理接收到的RTP帧，根据Frame NO.字段递增依次将连续的链表节点送入 播放器；

b、播放器缓存区是一个先进先出的FIFO结构，对送进来的每一个RTP帧分解成一个或 多个RTP包，再对RTP包解析成H.264格式可播放的NALU裸流数据，最后将完整的NALU帧 送入播放库进行显示；

c、将每个从网络缓存区接收到的一帧数据，建立一个链表节点，并根据Frame NO.值插 入到链表中，如果有Frame NO.重复的帧则丢弃，如果Frame NO.小于已送入播放器的帧的 Frame NO.则丢弃；

d、根据select监控套接字到达，如果仅有一个套接字可读，则读取此套接字的一帧数 据后，建立一个链表节点并插入链表，如果多个套接字可读，则依次读取每一个套接字的帧 数据，对每个RTP帧建立链表节点，并插入链表。

本实施例的网络接收端4是DVR。基础网络5是局域网或宽带接入网络，包括FTTx、XDSL、 IEEE802.11.x或者无线通信网络的TD-LTE、FDD-LTE、CDMA-EVDO、CDMA2000、TD-CDMA。