基于RTP协议的移动视频监控系统的设计

许 宁

(厦门雅迅网络股份有限公司，福建厦门361008)

0 引言

随着移动通信技术的迅速发展，特别是3G、4G移动通信网络技术的成熟和商业化运营，多媒体业务在无线通信领域快速成长，典型应用之一即为无线移动视频监控。相比有线网络，在无线移动网络环境下，通信终端位置不再固定不变，网络的传输环境更加不稳定，视频监控所要面对的数据量大、实时性要求高与网络带宽不足或不稳定之间的矛盾更加突出。如何根据移动通信网络的有效传输带宽的动态变化，实时调整视频数据的发送速率，以获得最佳的视频监控效果，是一个广泛研究的课题。

1 技术原理

1.1 H.264编码

H.264编码是一种面向宏块的基于运动补偿的视频编解码标准，由ITU－T视频编码专家组与ISO/IEC动态图像专家组(MPEG)——联合组成的联合视频组(JVT，Joint Video Team)开发，也即MPEG－4第10部分标准。在同等图像质量的条件下，H.264的压缩比是 MPEG－2的2倍以上，是MPEG－4的1.5～2倍，传输时需要的带宽更小，但仍然保持了较高的图像质量，在不稳定、高误码率的无线移动通信网络环境下有良好的适应能力。

H.264编码在结构上分为2层:视频编码层(VCL，Video Coding Layer)和网络提取层(NAL，Network Abstraction Layer)。VCL承载的是视频编码数据，NAL负责对数据进行打包和传送。这样的分层结构有利于信息的封装，传输时也不依赖特定的的信道和介质。H.264的另一大改进，是将帧级结构进一步划分——图像帧由一个或多个片(Slice)组成［1］，片封装在NAL单元中。片具有一定的独立性，其中I片可单独解码，而不需要依赖其他片，这样就提高了码流整体的抗丢包、抗误码能力。

NAL单元由单元头(1字节)和载荷数据组成。单元头指示了载荷数据的类型等信息。载荷数据可以是图像编码片，也可以是其他编码信息，如序列参数集、图像参数集、附加增强信息、定界符、分割符、结束符等。

视频帧分为I帧、P帧、B帧。I帧采用帧内编码技术，带有全部解码信息，能生成一幅完整图片的独立帧，数据量较大;P帧，采用单向帧间预测编码，需要参考前面的I帧或P帧进行解码，数据量较小，且易受到参考帧误码或丢失的影响而不能正常解码;B帧，采用双向帧间预测编码，需要其前面和后面的帧作为参考帧。IDR帧是一种特殊的I帧，其后的P帧、B帧，不再以该IDR帧之前的任何帧为参考帧。这意味着，如果码流有任何错误，从一个新的IDR帧开始可以重新完整解码。B帧不是必须帧;P帧也不是必须帧，但一般不可少;I帧/IDR帧必不可少。

一个典型的H.264码流结构示例如图1所示。

图1 H.264码流结构示例Fig.1 Example for H.264 coded data structure

在图1中，从IDR帧开始到下一个IDR帧之前的数据，称为一个视频序列。在视频序列内，一部分数据的丢失，将影响其所在帧和后续帧的解码，表现为图像的缺失、残像、马赛克等现象。然而，无论前一个视频序列丢失多少数据，从下一个视频序列开始，总能重新开始完整的解码。为了改善视频监控时由于错误解码导致的不良用户体验，当解码器收到一个不完整的视频序列时，可以丢弃该视频序列中因为缺失参考帧信息而无法正确解码的数据，付出的代价是可能出现不连贯的图像。

1.2 RTP/RTCP 协议

RTP，全称是 Real－time Transport Protocol，即实时传输协议。它是由IETF的多媒体传输工作小组提出的传输标准，目前最新的版本为RFC3550。

RFC3550实际描述了两个关系密切的子协议:RTP和 RTCP。RTCP全称是 RTP Control Protocol，即RTP控制协议。其中，RTP协议用于实时数据的传输，但不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制［2］。RTCP协议则负责传递网络的QoS(Quality of Service，服务质量)信息，并且传送参与多媒体数据收发者的信息。使用者可根据RTCP协议传递的网络传输质量信息，动态调整单位时间传输的数据量，实现流量控制和拥塞控制，以适应网络环境的变化。

RTP/RTCP协议，是建立在传输层协议之上的协议，其所依托的传输层协议，通常是UDP协议。各协议层次关系如图2所示。

图2 RTP/RTCP与其他协议层次关系示意Fig.2 Hierarchical relationship between RTP/RTCP and other protocols

按照规范，RTP使用偶数端口，配对的RTCP协议使用紧随其后的奇数端口。

链路层的载荷数据有最大传输单元(MTU，Maximum Transmission Unit)大小限制，超过限制无法传输，因此网络层协议在将数据传入链路层之前，若发现会导致链路层载荷数据长度超过MTU限制，则先将数据分成若干数据片(数据片长度满足MTU限制约束)，再将数据片交链路层发送。接收方在收到全部网络层数据片后按原顺序重组，只要有一个数据片未接收完整则无法还原，表现为整个数据包的丢失。因此，为了降低数据的丢失概率，应对每次发送的RTP/RTCP数据长度进行限制，以确保网络层处理时不进行分片操作。按照以太网的一般限制，RTP/RTCP包大小不能超过1 472字节。实际上，网络传输路径上的某些节点对MTU的实际限制可能更低，RTP/RTCP数据包大小可能需要进一步降低，可参照RFC1191的描述，使用ping命令(参数为不允许分片)探索和确认网络传输路径的MTU值。

传输时，视频编码数据作为RTP协议的负载字段填入。为了确保RTP包不超过上述限制，有2种方法:方法1，当编码器输出的NAL单元超长时，可以在应用层将NAL单元分片，打入序列号连续递增的多个RTP包，RFC3984对此进行了描述和规范;方法2，对编码器配置输出NAL单元的长度限制，使得一个较长的NAL单元被编码器自动拆分为多个较短的NAL单元输出，这需要编码器支持。

接收方根据RTP数据包中的序列号信息对数据排序重组，并结合来自发送方的SR包(RTCP数据)判断丢包情况;RTP和RTCP数据中还包含时间戳信息，接收方可分析时间戳信息判断数据传输的延迟和抖动情况。根据数据的丢包和延时抖动情况，可判断网络QoS的变化情况，从而调整数据传输速率，适应网络带宽变化。发送速率调整算法一般使用加性增加乘性减小［3］(AIMD，Additive Increase and Multiplicative Decrease)。

2 系统的实现

移动视频监控系统，由视频采集终端(以下简称终端)、监控平台(以下简称平台)，以及它们之间的通信网络组成，结构示意图如图3所示。

图3 移动视频监控系统结构Fig.3 Mobile video monitor system structure

终端采集视频图像，经压缩编码后得到H.264数据，使用RTP协议封装和发送，传输层使用UDP协议。终端数据的上传，经过3G/4G移动通信网络进入Internet，最后到达平台。平台解析RTP数据包，提取出H.264数据，解码并播放;同时，终端定期发送RTCP协议封装的SR包(发送者报告)到平台，平台对收到的RTP数据和SR包进行分析统计，得到丢包率等信息，并生成RTCP协议的RR包(接收者报告)反馈到终端。本例中，终端仅根据RR包中的丢包率信息评估有效带宽的变化，然后调整编码输出码率达到调整发送速率的效果，以适应动态变化的网络环境。

2.1 视频采集终端

视频编码芯片选用海思Hi3511。Hi3511同时具有通用CPU的处理功能，内核为ARM926EJ－S，是32位 RISC处理器，工作频率达264 MHz，有16KB指令 Cache和16KB数据Cache，支持 H.264视频编解码，具备320fps@CIF编解码能力，运行的操作系统是Linux。视频采集芯片使用Techwell公司的TW2685，作用是将摄像头输出的CVBS信号，转换为BT.656信号输入Hi3511进行编码。通信模组使用SIMCom公司的SIM5218，传输网络为WCDMA。

Hi3511支持NAL单元长度限制，在视频帧较长时编码器可自动拆分为多个NAL单元输出。使用时，设定输出的NAL单元限制长度为650字节。实际输出的NAL单元长度有时会超过该限制值，经测试最长不会超过1 300字节。

为了接收方更好地分辨收到的RTP数据是否同属一帧，进一步判断一帧或者一个视频序列是否接收完整，实现时，在RTP载荷中增加了附加信息字段，附加信息格式为“帧编号(2字节)+帧内NAL单元总数(1字节)+NAL单元序号(1字节)”，帧编号取值为0～65 535，循环使用。于是，RTP的载荷结构变为“附加信息(4字节)+NAL单元(不定长)”。利用此附加信息，平台能判断一帧、一个视频序列接收的完整度，评估对图像解码造成的影响，再做进一步处理。

按如上设计，RTP载荷长度将不超过1 304字节(最长NAL单元1 300字节+附加信息4字节)，加上RTP包头12字节(本例的RTP包头只用到12字节固定字段)，则RTP数据包整体长度不超过1 316字节。为判断RTP包是否会超过链路层的MTU限制，在终端上使用命令“ping －f－l1316xxx.xxx.xxx.xxx”(xxx.xxx.xxx.xxx 为平台 IP 地址)测试有成功回应，说明未超过MTU限制。

为简便计，无论NAL单元有多长，均使用一个RTP包封装一个NAL单元。RTP时间戳T的计算公式为:T=T0+Td，其中T0表示上一视频帧的时间戳，Td表示两帧间的时间戳增量。第一个RTP包的T0为随机计算得到的时间戳起始值。Td的计算公式为:Td=90000/F，F为视频编码输出帧率(即每秒输出多少视频帧)。多个RTP包若属于同一个视频帧，则填入的RTP时间戳相同。

终端每隔5 s向平台发送SR包(发送者报告)，同时接收每隔5 s从平台发来的RR包(接收者报告)，并对RR包中的QoS信息进行分析处理。本例中采用的方法是根据丢包率的变化，终端动态调整编码输出的码率大小，达到调整发送速率的效果。设丢包率门限值Lc，作为判断网络是否拥塞的标准。当丢包率低于门限值时，可加性增加码率;当丢包率达到或高于门限值时，应乘性减小码率。设丢包率为L，当前码率为Rc，码率加性增加值为K，期望码率为Re，最小码率为Rm，调整后码率为Rp，公式如下:

本例中，Lc=0.03，Re=200 kb/s，K=2 kb/s，Rm=64 kb/s。需要说明的是，参与上述计算的丢包率L，是对RR包中反馈的原始丢包率经过低通滤波平滑处理后得到的值，目的是降低网络传输质量突然随机波动的影响。设Ln、Ln－1分别为当前时刻和上一时刻的滤波后丢包率，Ln0为当前时刻原始丢包率，权重常数为a(0≤a≤1)，则计算公式为:Ln=(1－a)Ln－1+aLn0。可以看出，增大a值，会增加新值Ln0对当前时刻滤波结果的影响;而减小a值，将增加上一时刻滤波结果Ln－1对当前时刻滤波结果的影响，经测试调整，本例中a=0.6。

2.2 监控平台

平台使用了海思提供的PC端解码库，操作系统为Windows。平台对RTP数据的处理流程如图4所示。

图4 平台处理RTP数据的流程Fig.4 RTP data processing procedures at platform

如图4所示，软件使用了双缓冲设计［4］。接收缓冲，用于保存收到的RTP数据，经排序、检测、过滤等处理后再送入播放缓冲;播放缓冲负责将数据按照帧间隔时间，顺序解码播放。为了尽可能避免因丢包造成的不正常解码，从而影响视频播放效果，在接收缓冲区对数据排序之后，在送入播放缓冲区之前，应对编码数据做检测和过滤处理。本例中，根据终端在RTP载荷中增加的附加信息字段，平台快速判断视频数据丢失情况，当一个视频序列出现一个NAL单元丢失时，该单元所在帧和其后的同一序列内的其他帧，均不参与解码播放。

需要注意的是，按照RFC3550规范，RTP协议使用偶数端口，相应的RTCP协议使用紧随其后的奇数端口。但是，即使终端严格按此规定配置自己的端口，在平台“看到”的终端所用的通信端口，却很可能不满足此规定。这是因为，通过3G/4G移动通信网络接入Internet时，运营商的网络接入设备对终端的IP、端口进行了映射，平台“看到”的是经过映射后的IP、端口，而非终端原始绑定的IP、端口，映射后就失去原有的绑定关系了。例如，终端原始端口7818(RTP)、7819(RTCP)，在映射后变为10527(RTP)、10360(RTCP)。因此，平台在具体实现时必须对此做一点“让步”，不能严格按照RFC3550规范推定终端RTP/RTCP通信端口是相邻的。本例中，平台从收到的RTP数据和RTCP数据(SR包)中的共同字段——发送者SSRC(同步源标识)，判断源是否相同，确认RTP、RTCP通信链路是否配对。

平台每隔5 s对收到的RTP数据和RTCP数据(SR包)进行分析统计，得到丢包率、抖动信息等，即QoS信息，然后使用RTCP协议发送RR包到终端。同时，平台将从RTP数据中提取出的H.264数据解码为YUV编码数据，再转换为RGB数据，最后用DirectShow技术播放。

3 结语

文中搭建监控平台，将终端安装在行驶的车辆上测试无线移动网络环境下的视频监控效果。实验表明，相比不能自适应调整的系统，本系统的视频监控效果更为流畅，马赛克、残像、缺失等现象基本消失，用户体验效果良好。

［1］刘高平，李国胜，宋执环.基于窄变带宽的实时视频传输算法［J］.光电子·激光，2012，23(03):548 －550.LIU Gao － ping，LI Guo － sheng，SONG Zhi－ huan.Real－Time Video Transmission Algorithm based on Narrow and Variable Bandwidth［J］.Journal of Optoelectronics·Laser，2012，23(03):548 －550.

［2］谢红辉.基于网络的视频通信系统的设计［J］.通信技术，2009，42(07):131.XIE Hong－hui.Design of Network－based Video Communication System［J］.Communications Technology，2009，42(07):131.

［3］吴作绥.基于RTP的实时H.264网络视频监控系统的实现与QoS研究［D］.西安:西安电子科技大学，2009.WU Zuo － sui.The Realization and QoS Researchof RTP－based Real－ Time H.264 Net Video Monitor System［D］.Xi'an:Xidian University，2009.

［4］程堂勇.浅谈RTP/RTCP的网络视频监控系统［J］.科技信息，2009(17):40.CHENG Tang－yong.Discussion on Network Video Monitor System based on RTP/RTCP［J］.Science＆Technology Information，2009(17):40.