一种提高实时视频播放质量的方法与流程

本发明属于网络视频流传输技术领域，涉及一种提高实时视频播放质量的方法。

背景技术：

随着多媒体技术和网络技术的迅速发展，网络上传输的媒体信息由原来的文字和图片逐步过渡到声音和视频等多媒体格式，传输的方式也由先下载再播放转变成边下载边播放的流媒体方式，流媒体技术已成为网络传输多媒体数据的主流技术。其主要思想就是把视频和音频等多媒体文件经过特殊的压缩方式分成一个个压缩包，由服务器向用户计算机连续、实时传送；用户无需将整个文件下载完毕，只需经过较短时间的启动延时即可在用户计算机上进行播放，剩余的部分将继续进行下载，直至播放完毕。

流媒体传输协议是流媒体技术的重要组成部分，包括rsvp(resourcereservationprotocol资源预留协议)、rtp(real-timetransportprotocol实时传输协议)、rtcp(rtpcontrolprotocol实时传输控制协议)、rtsp(realtimestreamingprotocol实时流协议)。其中，rtp(real-timetransportprotocol实时传输协议)为多媒体数据提供端到端的实时传输服务，是实时流传输的重要协议之一。

h.264/mpeg-4avc(h.264)是1995年自mpeg-2视频压缩标准发布以后的最新、最有前途的视频压缩标准。通过该标准，在同等图象质量下的压缩效率比之前的标准提高了2倍以上，因此，h.264/mpeg-4avc(h.264)被普遍认为是最有影响力的行业标准。

随着人们对网络通信服务的依赖性与要求越来越高，qos(qualityofservice传输服务质量)成为实时流媒体系统中最为关注的问题。当前internet(因特网)是以best-effort(标准的因特网服务模式)方式工作的异构网络，其终端接入方式、可用带宽、延迟抖动和丢包等因素都是动态变化和不可预知的，难以满足实时流媒体传输的要求，视频信息的传输常常会因为网络环境不稳定而暂停或出现马赛克，网络状态的波动极大的影响着视频信息的播放效果，服务质量很难保证。为使实时流媒体能够适应internet(因特网)的特点，提高流媒体服务质量，研究人员在针对rtp协议进行实时流传输的过程中给出了很多解决和优化方案，比如，对实时流传输过程中防丢包和丢包修复算法进行了研究，尽可能的解决丢包问题；通过对实时流传输过程中的传输速率和拥塞控制进行研究，来提高传输质量；对实时视频传输中接收端缓冲技术做了研究，来提高播放流畅度。

尽管如此，实时流媒体的服务质量仍有相当大的改进空间，而在异构、低比特率、高丢包率、强干扰及无线网络等网络环境下，实时流媒体传输技术更需要进一步的研究与完善。

技术实现要素：

本发明的目的是提供一种提高实时视频播放质量的方法，解决了现有实时流媒体技术，存在的丢包、视频传输延时和画面质量较差的问题。

本发明所采用的技术方案是，一种提高实时视频播放质量的方法，按照以下过程实施：

设置滑动窗口，滑动窗口是将时间范围对应为rtp包的数量，滑动窗口是在一定的时间范围内，等待序号较小但接收较迟的包，将时间范围对应为包之间的跨度，滑动窗口有两个范围，即左边界wl和右边界wr，

左边界wl的表达式如下：

wl由两部分组成，一部分是固定值num，另外一部分是客户端在接收num个rtp包的时间里，视频提供端产出多少个rtp包；mtu表示最大传输单元，即1500字节，s表示播放程序每秒钟收到的视频字节数，fps表示视频的分辨率；

右边界wr的表达式如下：wr＝λ×f×num+wl，

wr的值是在wl的基础上，加上一个播放端能够容忍的包间隔；f*num粗略的表示了在理想情况下1秒时间内播放端接收到的包；λ作为程序的配置参数，是播放端接收的最大延迟时间秒数；

滑动窗口将整个数值范围分为三部分，当w＝r-1-n，也就是未收到的包的序号和当前接收包的序号的差值，落在不同的范围内时，进入不同的处理过程：

1)当0<w<wr时，说明未接收到的包与当前接收包的时差较小，此时不解码，继续等待；

2)当wl<w<wr时，则利用整个集合中的rtp包重组nalu，准备进行解码；

若集合中的rtp包是某个关键帧的打包，则需要进行重传处理，这要求发送方或者视频数据中转方有一定的rtp包缓存能力，在播放端请求最近传输过的关键帧的某个rtp包时，重新传递给播放端；对于重传的包，要有超时机制，超时的时间最终对应在包数目上，这种等待是改变wl的值，即wl＝wl+num，进入下次接收；

若集合中的rtp包非关键帧的打包，则是将整个集合中的数据丢弃，并从当前开始丢弃所有非关键帧的rtp包，直到接收到关键帧的rtp包重新开始处理；

3)当w>wr时，则需要丢弃整个集合中的rtp包，从当前接收包pr处开始重新处理。

本发明的有益效果是，针对视频播放端接收rtp(real-timetransportprotocol实时传输协议)协议传输的h.264(视频编解码技术标准之一)视频流，并重组h.264nalu的过程中，根据网络状况、被传输视频的分辨率、帧率等参数，尽可能的利用接收到rtp数据包进行nalu重组并解码，在必要时要求发送方对关键帧进行重传，有效改善了在较差网络环境条件下，视频传输延时和画面质量较差的问题，提高了视频播放质量。包括以下几个方面优点：

1)当前，大部分的nvr/dvr(networkvideorecorder即网络硬盘录像机/digitalvideorecorder即硬盘录像机)的厂商都提供了sdk(softwaredevelopmentkit即软件开发工具包)，开发者通过该sdk得到摄像头的实时视频数据，而具体的视频传输过程、解码过程都需要开发者自主实现，本发明算法实施的阶段是从nvr/dvr得到视频数据，进行打包传输以及在播放端组包、解码播放的这一过程，算法的实现不需要依赖nvr/dvr厂商的修改或者更新。

2)本发明改善实时视频画面的质量。本发明对非i帧的不完整nalu直接丢弃，而对不完整的i帧，则会进行重传，这使得画面的花屏、卡顿次数减少；对部分非i帧的丢弃，可能使得画面有跳跃现象，但在实际监控过程中不会影响监控的整体效果。

3)本发明改变了传统方法根据时戳、序号进行排序的思路，在保证准确性的条件下，简化了视频包排序流程，快速完成视频流的顺序解包及播放过程，并保证结果的实时性和准确性。实验结果表明，使用本发明不仅在网络环境优良的情况下，能保持较高的视频清晰度，而且在网络不稳定的情况下，通过相应处理，依然能保证视频播放的流畅度和准确性。

附图说明

图1是本发明方法中的rtp包采用哈希表缓存；

图2是本发明方法中的rtp传输h.264nalu示意；

图3是本发明与现有技术在不同环境下视频数据的传输速率对比曲线；

图4是本发明与现有技术的画面质量对比曲线；

图5是本发明与现有技术的画面延迟效果对比曲线。

具体实施方式

下面结合附图和具体实施方式对本发明进行详细说明。

rtp协议基于udp协议传输，而且rtp协议本身没有任何机制保证数据传输的有序性和可靠性。由于udp的不可靠性，nalu分割后的rtp包可能会出现乱序(out-of-order)和丢包的现象。

播放端在接收rtp包时，采用一张哈希表来缓存rtp包进行处理，在哈希表中，使用rtp包序号和rtp包一起组成一个键值对。当播放端接收部分，接收到一个rtp包后，将其序号和内容组成一个键值对插入到哈希表中。而播放端解码部分的工作是记录下要解码的rtp包序号，并不断从哈希表中取出rtp包还原nalu后进行解码，如图1所示。处理过程中，只需要记录当前正在处理的rtp包序列号和正在接收的rtp包序号。

在视频传输过程中，同属于一个nalu的rtp包的时间戳相同，且rtp包序号连续。所以，当接收rtp包的时候，若发现包的时间戳发生改变，是接收到了一个新的nalu的rtp包。一个完整的nalu能够直接提供给解码器进行解码播放。

由于是基于rtp包的时间戳发生改变，来判断一个nalu的rtp包是否接收完成，而时间戳的改变，可能会存在两种情形：一种是两个连续的nalu的rtp时间戳的改变；另一种是两个nalu之间的一个或者多个nalu数据丢失，从而使两个不连续的nalu的rtp时间戳的改变，如图2所示，因此，这种不连续可能发生在集合中的某一个元素pn或者多个元素pn，pn-1…(n＝d,d+1,…,r-1)上。

当集合pnalu中的元素出现不连续时，组成的nalu直接交给解码器解码的话，会出现错误，导致画面质量出现问题。

综合考虑以上情况，本发明方法的具体实施过程如下：

本发明主要的创新点在于重新设置了rtp包的视频重组算法，核心思想是对属于同一nalu的rtp包，给出一个可变化的时间范围，在该时间范围内处理该nalu所属rtp包的乱序、丢包，如果该nalu是关键帧的话，还会在一个可变化时间范围内支持重传丢失的rtp包，这个可变化的时间范围称为滑动窗口；对属于关键nalu的rtp包的重传称为关键帧重传；

滑动窗口的核心是将时间范围对应为rtp包的数量，滑动窗口的目地是在一定的时间范围内，等待序号较小但接收较迟的包，而在具体过程上是将时间范围对应为包之间的跨度，具体的说，滑动窗口有两个范围，即左边界wl和右边界wr，

左边界wl的表达式如下：

wl由两部分组成，一部分是固定值num，另外一部分是客户端在接收num个rtp包的时间里，视频提供端产出多少个rtp包；mtu表示最大传输单元，即1500字节，s表示播放程序每秒钟收到的视频字节数，fps表示视频的分辨率；

右边界wr的表达式如下：wr＝λ×f×num+wl，

wr作为右边界的主要目的是为了简化处理逻辑，它的值是在wl的基础上，加上一个播放端能够容忍的包间隔(时间范围)；f*num粗略的表示了在理想情况下1秒时间内播放端接收到的包；λ作为程序的配置参数，是播放端接收的最大延迟时间秒数；

这样，滑动窗口将整个数值范围分为三部分，当w＝r-1-n，也就是未收到的包的序号和当前接收包的序号的差值，落在不同的范围内时，进入不同的处理过程：

1)当0<w<wr时，说明未接收到的包与当前接收包的时差较小，此时不解码，继续等待；

2)当wl<w<wr时，则利用整个集合中的rtp包重组nalu，准备进行解码；

若集合中的rtp包是某个关键帧的打包，则需要进行重传处理，这要求发送方或者视频数据中转方有一定的rtp包缓存能力，在播放端请求最近传输过的关键帧的某个rtp包时，重新传递给播放端；对于重传的包，要有超时机制，超时的时间最终对应在包数目上，这种等待是改变wl的值，即wl＝wl+num，进入下次接收；

若集合中的rtp包非关键帧的打包，则是将整个集合中的数据丢弃，并从当前开始丢弃所有非关键帧的rtp包，直到接收到关键帧的rtp包重新开始处理；

3)当w>wr时，则需要丢弃整个集合中的rtp包，从当前接收包pr处开始重新处理。

实施例

第一、实验准备

当前，大部分的nvr/dvr的厂商都提供了sdk，开发者通过该sdk得到摄像头的实时视频数据，而具体的视频传输过程、解码过程都需要开发者自主实现，本发明方法实施阶段是从nvr/dvr得到视频数据，进行打包传输以及在播放端组包、解码播放的，其中的算法实现不需要依赖nvr/dvr厂商的修改或者更新。

h.264视频的分辨率越大，视频流中的nalu就会越大。为了体现本发明在不同分辨率的实时视频播放中产生的效果，在验证的过程中，以海康摄像头实时产生的视频码流，作为实验的数据，这种码流的编码信息为：15fps、1920*1080。将该编码格式的视频，截取8～10分钟的视频流保存为文件，作为发送方的视频输入源，这就保证了后续所有实验过程是使用同样内容的视频数据。

由于实验数据的范围受到网络环境影响较大，本实验是在大型内网中进行，发送方pc和播放端pc分别处在不同的内网中，发送方pc使用有线连接，播放端pc使用无线连接；该内网中的这两个子网之间的网络传输在一段时间内波动不大，且下文中的实验结果都是在一个连续的时间段内完成的。

本发明主要目标是在传输状况较差的网络环境中，改善实时视频画面质量，且对视频的实时性不会有较大的影响。为了能够更清晰的展示本发明的优点，选择了1080p、15帧的视频，在此使用另外两种传输场景与本发明实现场景进行对比，以分析本发明的优点和不足，这三种传输场景分别是：

场景a、基于udp的标准rtp/rtcp的传输场景，对有丢失rtp分包的nalu，直接丢弃，避免解码器收到错误的nalu后出错，下文中以rtp/rtcp代称。

场景b、基于tcp的nalu传输，通过tcp将nalu传送到播放端进行播放，没有使用rtp协议，下文中以tcp代称。

场景c、基于udp的rtp协议，并结合本文提出算法的传输场景，下文中以rtp+代称。

第二、验证对比

1)验证视频数据的传输速率

在同一网络环境下，分别在场景a、场景b和场景c三种传输场景中进行播放，在播放端通过接收到的数据，来对比视频数据的传输速率，其结果如图3所示。

图3中，场景b是使用tcp进行传输，由于tcp本身的机制，使得其传输视频数据要远远慢于udp，而场景a和场景c都是使用udp进行传输，可见前者的传输效率远慢于后两者；场景c，也就是本发明方法相对于场景b有明显的优势。对于场景a和场景c，单纯从视频传输来讲，场景c需要在关键帧丢失后，进行关键帧重传，其平均传输速率要低于场景a的传输速率。另外，场景a和场景c都包含了控制命令，场景a使用rtcp提供数据发送反馈信息，场景c需要在关键帧丢失时，通知发送方重新传输丢失的数据。rtcp协议包是间隔性发送的，而关键帧重传的请求则只有在关键帧丢失后，才会发出。所以在控制信息上，场景c传输的数据要少于场景a。

当然，网络环境对这种传输速率的对比也有较大的影响。在极差的网络环境下，如果rtp丢包次数频繁，那么关键帧丢失的可能性就会变大，需要重传的次数就会变多。若重传请求若是使用udp实现的话，重传请求因为网络变差的原因，也存在着丢失的可能，使得能被真正重传的关键帧减少，这样本发明方法传输的效率基本和使用场景a的时候一致。

2)验证对视频画面质量的改善

将视频流在同一网络环境下，分别通过在场景a、场景b和场景c三种传输场景中进行播放，来统计大概8分钟的时间内，画面的花屏、不连续画面数，来进行对比，结果如图4所示。

图4中，每种类型的视频类型在不同的传输场景中有两个重要的衡量指标，视频画面花屏和画面卡顿，分别用不同颜色的柱体表示，柱体的高度表示其数量的多少。当在播放1080p时，在场景c播放的画面质量优势就显现出来了，无论是相对于场景b的卡顿，还是相对于场景a的画面花屏数，都有明显的优势。

本发明对非i帧的不完整nalu直接丢弃，而对不完整的i帧，则会进行重传，这使得画面的花屏、卡顿次数减少。对部分非i帧的丢弃，可能使得画面有跳跃现象，但在实际监控过程中不会影响监控的整体效果。

3)验证对nalu传输延迟的影响

以1080p、15fps的h.264视频作为输入源在场景a、场景b和场景c中分别进行播放，在每个播放场景中选取30个i帧的发出时间和提交给解码器的时间，使用δt(该数据包的发送时间记为ts，接收时间记为tv，这两个时间差的绝对值)修改后，用发出时间与提交给解码器的时间作差，差值依序在平面坐标系中显示后，其结果如图5所示。

图5中，在使用场景b，也就是tcp传输的时候，延迟明显大于场景a和场景c，甚至部分nalu成倍数的延时。而使用场景a，也就是标准的rtp/rtcp时，nalu的处理延迟最小。而使用场景c，nalu的处理延迟比较平稳，但略大于使用标准rtp/rtcp的方式。

图5所示的结果也能够通过分析预测到，在传输大量数据的时候，必然会因为拥塞等原因产生丢包，而tcp协议的做法是实现重传并进行确认，而标准rtp/rtcp是基于udp协议的，没有实现任何保证数据可靠性的机制；而本发明只是在处理乱序的基础上，对关键帧丢包进行重传，且这种重传机制具有时效性，并不保证一定能够重传到丢失的数据。

综合上述结果的分析，本发明方法在视频分辨率较大、视频质量较高的情况，均有比较明显的优势。