基于ARM的移动视频监控终端设计与实现

摘要：以S3C2440硬件平台为核心基于Linux操作系统实现移动视频监控终端的设计。设计系统的硬件平台和软件方案，监控终端通过无线网络实现RTP协议下接收H．264视频流，在网络不稳定情况下接收视频包时乱序、丢包的处理方法。利用开源解码库ffmpeg实现视频流解码，显示监控画面。通过实验表明，移动视频监控终端具有灵活性高，便于携带等特点，对于QCIF分辨率有较好的实时监控效果。
关键词：ARM；RTP传输协议；H．264解码技术；监控终端

0 引言
随着人们对生活和工作环境的安全性的要求不断提高，安全防范的重要性越来越突出。视频监控技术在各个领域发挥着越来越重要的作用，比如对森林、旅游景点、城市小区等通过视频监控来实时监控现场发生的情况。将嵌入式技术和无线网络技术应用于视频监控终端，与传统的有线视频监控相比，无线视频监控摆脱了网络电缆的束缚，提高了视频监控的灵活性和可扩展性。监控人员可以携带手持监控设备而不必在固定位置值守来监控现场。
在无线网络环境下传输视频，庞大的视频信息量对有限的传输带宽是难以承受的，成为阻碍其应用的瓶颈之一，因此，需要高效率的视频压缩标准来满足无线传输带宽的需求。新一代视频压缩标准H．264是面向Internet和无线网络的视频图像编解码技术，它不仅提高了压缩效率，而且增加了网络适应能力，降低了网络带宽的需求。H．264标准定义了视频编码层VCL(Video Coding Layer)和网络提取层NAL(Network Abstraction Layer)。视频编码层主要采用帧内预测、帧间预测、变换和量化、熵编解码等技术实现视频压缩功能，网络提取层将编码后的数据封装成NALU单元，以适应在无线网络中传输。
移动视频监控终端以ARM微处理器为核心，剪裁适合视频监控终端的嵌入式Linux操作系统。通过配备无线网卡接收监控前端压缩视频数据，解码、显示监控前端发送的视频流，实时显示前端监控画面。本文将重点阐述在视频传输过程中采用RTP／UDP／IP协议时，出现的视频包乱序、丢包处理方法，以及在ARM平台上对H．264解码器的移植和实现。

1 系统的硬件平台
系统硬件平台主要由嵌入式微处理器、NANDFLASH，SDRAM，IEEE802．11协议无线网卡、LCD模块组成。本系统的微处理器选用三星公司ARM9内核的S3C2440，系统时钟采用400 MHz的工作频率。S3C2440内部集成了大量的功能单元，包括：存储器控制器有8个Bank区间、LCD控制器、USB控制器以及丰富的外设接口资源，根据视频监控终端的需求，在此基础上进行外围电路的配置和扩展。视频监控终端硬件框图如图1所示。

存储器包括ROM和RAM两部分，ROM配备了非线性结构的K9F1208UOM容量为64M×8 b的NAND FLASH芯片；RAM配备2片HY57V561620BT—H组成32位数据总线的SDRAM，适用监控终端处理庞大视频数据的需求。在USB Host接口上外接一块基于IEEE802．11协议的无线网卡，通过无线AP端点接收监控前端视频数据。液晶屏选用TFT真彩液晶屏，并配备相应的触摸屏实现人机交互的目的。

2 系统的软件设计
移动视频监控终端软件设计以嵌入式Linux操作系统为核心，作为一种开源操作系统，Linux具有支持多种硬件平台、丰富的设备驱动和良好的网络功能等特点。针对监控终端的具体应用对内核进行配置，剪裁出合适的系统。监控终端应用软件是建立在操作系统之上，为实现RTP／UDP／IP协议下接收H．264视频流和ffmpeg解码库实时解码视频流。
2．1 H．264视频流的传输
2．1．1 传输方式选择
视频的实时传输要求较低的时间延迟，并且允许一定的丢包率。由于TCP协议的3次握手以及丢包重传机制会造成一定的延时，在实时监控系统中有一定缺陷，而UDP协议是面向无链接、不可靠的传输层协议，具有消耗资源小，传输速度快等特点，在视频传输过程中偶尔丢包不会对监控画面产生较大影响。UDP协议不提供数据包分包、封装、数据包排序等缺点，为保障视频流传输的可靠性，网络传输部分采用建立在UDP协议之上的RTP(Real-time Transport Protocol)实时传输协议来实现，通过套接字与前端建立连接，以接收视频流数据。RTP提供带有实时特性的端对端数据传输服务，包括有效载荷类型的定义、序列号、时间戳和传输检测控制。基于RTP／UDP／IP协议传输视频流封装格式如图2所示。

2．1．2 视频流传输
采用UDP协议传输RTP包时会出现乱序的现象，所谓乱序就是监控终端接收到RTP包顺序可能前端发送的顺序不一致，因此，首先要对接收的RTP包排序。采用在内存中建立一个双向链表来保存接收的RTP包，按照RTP报头的序列号(Sequence Number)顺序存放到链表中，双向链表结构体定义如下，部分变量用于RTP分片封包模式。

每当接收到一个新的RTP包后，根据序列号从链表尾开始搜索并插入到合适的位置，比如，接收到一个序列号SN=26的RTP包在链表中分配内存，找到位于25，27之间的位置插入该包，RTP包排序过程如图3所示。

H．264视频流NALU单元封装成RTP包时，要遵循RTP负载格式标准，H．264负载格式定义了3种类型的负载结构：单一NALU模式、组合封包模式、分片封包模式。单一NALU模式是一个RTP包仅由一个完整的NALU组成；组合封包模式是可能由多个NALU组成一个RTP包；分片封包模式是将一个NALU单元封装成多个RTP包，采用分片封包模式的原因是网络传输协议有最大传输单元(MTU)一般为1500B上限，如果NALU大于MTU，IP层将其自动分割为几个小于MTU的数据包，这样无法检测数据包是否有丢失，所以有必要采取分片封包模式，在接收端把拥有相同时间戳的多个RTP包按照序列号重组成一个完整的NALU。分片封包模式的RTP包格式如图4所示。

FU indicator的Type字段表示RTP采用的负载结构，28，29时表示采用分片封包模式，NRI字段的值根据NALU的NRI值设置。FU header的S位置1时表示该包是NALU的起始分片，E位置1时表示该包是NALU的结束分片。
2．1．3 RTP丢包处理
由于网络稳定性原因，可能造成RTP丢包的情况。针对单一NALU模式和组合封包模式丢包不会影响解码器的正常工作，会导致监控画面花屏或跳帧想象，但对于实时监控是在可承受的范围。对于分片封包模式丢包会造成接收端收到一个不完整的NALU，对一个不完整的NALU解码可能造成解码失败，甚至系统崩溃。因此，对于分片封包模式的RTP包需要判断接收的NALU是否丢包。
传输分片封包模式的NALU时，一个NALU分割封装成若干个RTP包具有相同的时间戳、依次递增的序列号。对接收的RTP包根据FU header头信息做不同的处理：接收到起始分片(S=1)，根据序列号在链表中添加节点，保存视频数据、起始分片序列号，计数器加1；接收到中间分片，在链表中找到时间戳相同的节点，将此RTP包序列号与起始序列号相减，计算出视频数据在链表的相对偏移，存储视频数据到链表相应位置，计数器加1；接收到结束分片(E=1)，同中间分片一样，但还需要保存结束分片序列号。每接收一个RTP包后判断NALU完整性，在接收到起始分片、结束分片的前提下，结束分片序列号与起始分片序列号之差是否等于计数器的值，以此判断一个NALU是否接收完整，若接收到所有分片，置位结构体中FrameCompelere，解码器可根据此位判断NALU完整性。
2．2 H．264解码器的实现
监控终端通过网络接收到H．264视频流后，需要移植H．264的解码库实现实时解码。在众多解码器中经对比和分析，选用ffmpeg开源解码器来实现。ffmpeg库为音视频数据分离、转换、解码提供了完整解决方案，其中两个重要库libavformat和libavcodec，分别支持各种音视频文件格式和音视频解码器。
利用ffmpeg的API函数进行视频流解码，先做好解码前的准备工作。调用av_register_all()函数注册所有的文件格式和编解码器的库，也可以只注册特定的解码器。关于解码器的信息在AVCodecContext结构体中，它包含解码器所有信息，查找H．264解码器CODEC_ID_H264，通过avcodec_open()函数打开解码器。用avcodec_alloc_frame()函数分配一帧的存储空间，存储解码后输出的数据。
在双向链表中已经保存了接收的视频流，从链表头读取NALU进行解码，每读取一个NALU将链表头指向下一个单元，释放已读取NALU占有的内存。NALU的头信息定义了视频流所属类型，一般包括增强信息(SEI)、序列参数集(SPS)、图像参数集(PPS)、条带(Slice)等。先将SPS、PPS参数集通过解码器解码出来设置解码图像尺寸、片组数、参考帧数、量化和滤波参数等。依次从链表头读取NALU，调用avcodec_decode_ video()函数解码输出到分配的存储空间，当完成一帧的解码，就需要对解码后的图像显示到液晶屏。解码输出的图像格式为YUV420P，可以采用ffmpeg提供的sws_seale()把图像格式转换为RGB格式显示，也可以采用其他SDL之类的库直接YUV覆盖显示。整个解码流程如图5所示。

3 结语
系统采用S3C2440硬件平台和嵌入式Linux操作系统相结合，设计了移动视频监控终端，重点阐述了用RTP协议在网络中通过套接字传输视频流，结合开源解码库ffmpeg实时解码H．264视频流的解决方案。经测试，对于QCIF分辨率监控画面具有较好的实时性和可靠性。当视频分辨率增大时，解码器的解码性能成为视频监控终端的瓶颈。因此，本文的后续工作就是针对ffmpeg解码库在ARM9平台的优化，提升解码性能。