基于TMS320DM8168的RTSP服务器系统设计及实现*

付 雄，卿粼波，何小海，尹 雷，白 勇

（四川大学 电子信息学院图像信息研究所，四川 成都 610065）

0 引言

随着信息化科技、网络技术的不断发展，流媒体技术已变得日趋成熟，在网络数据传输中变得尤为重要，极大地方便了人们与外界的通信，成为了网络应用的重要发展方向。传统的传输方式是通过网络将视频或者音频下载到本地硬盘上，而且必须等下载完成后才能播放观看，针对这种缺点，提出了流媒体技术。流媒体技术涉及到视频的采集、预处理、编码、解码、网络传输等多方面,它将经过压缩编码后的视频放到网络服务器上，使用户可以直接通过网络IP来实时观看视频，适用于远程视频监控、在线直播、实时视频会议等场合。

目前，国内外对实时视频监控都进行了深入研究，并在实际产品中进行应用，其技术方案越来越成熟。目前的主流监控系统，虽然都集成了网络监控和本地监控功能，但由于受网络带宽的限制，每秒钟只能传输有限的数据量，实时性较差，同时绝大多数系统都是在PC上实现，只能满足单路的视频传输。通过对一些常用的应用层协议（如 RTSP、HTTP、SSDPD 等）进行统计分析[1]，本文比较了在服务器高并发条件下这些协议在系统性能和稳定性方面带来的影响。文献[2-3]比较了RTSP协议和HTTP协议在网络监控系统中的性能，分析出RTSP协议在针对帧率和花屏方面的性能有很大幅度的提升，并具有较好的实时性。随着嵌入式系统的快速发展，如何在嵌入式平台上实现多路视频实时监控已成为非常热门的研究方向。为此，本文设计了一套基于TMS320DM8168嵌入式平台的RTSP服务器系统，该系统能同时实现16路D1 30 Fps视频的远程实时监控并进行本地存储，解决了常见网络监控系统在监控画质和视频实时性方面的缺陷。经测试，该系统实时性好、可靠性高，具有一定的应用价值。

1 硬件平台选择

本文选用TI公司推出的基于达芬奇架构的TMS320-DM8168作为硬件平台，其总体架构如图1所示，它具有处理能力强和运算速度快等特点，能同时实现16路D1 30 Fps视频的采集、编码以及网络传输，还支持3个60帧/s的1080P通道，编解码器时延低于50 ms，满足本文多路视频监控的需求。

图1 系统硬件框图

1.1 TMS320DM8168芯片结构

TMS320DM8168内 部 集 成 了 ARM Cortex A8、DSP C674X+、M3 VIDEO、M3 VPSS 4个处理器。 Cortex A8处理器作为系统的主控制器，时钟频率高达1.2 GHz，负责整个系统的运行、控制外设管理，可运行 Linux、Android等操作系统，适合用于多任务多线程的操作。C674X架构的浮点型DSP处理器的最高时钟频率为1.0 GHz，主要运行BIOS6实时系统，用于对视频图像的处理。在视频图像方面，TMS320DM8168内部集成了两个Cortex M3处理器，其中VPSS Cortex M3处理器主要控制HDVPSS高清视频处理子系统，用来实现视频的捕获、去噪、缩放、显示等功能。Video Cortex M3处理器主要控制3个HDVICP高清视频图像协处理器，用于对视频图像进行编解码，如H.264、MPEG4，还有两个 Video Port输入和输出端口，可配置成高清或者标清模式，用于采集或输出视频。

1.2 多通道视频处理框架

由于TMS320DM8168是一款多核异构的芯片，同时拥有4个核心处理器，如何控制4个核心处理器之间的协同工作成为了一个至关重要问题。对此，本系统采用了一套多处理器软件编程框架——多通道视频处理框架(Multi channel framework，MCFW)。MCFW 针 对视 频的采集、处理和显示等，为开发者创建了一系列的处理节点(Link)，屏蔽了底层硬件平台的细节，为上层的应用程序开发提供了丰富的API接口[4]。Link是MCFW软件框架中最基本的视频数据流单元，每一个Link都是一个独立的线程，各Link之间通过指针来实现数据流的相互传递，也可以并行执行。对于每一个核心处理器，在它们内部的数据处理都是由Link来实现的，典型的Link有视频采集 Link(Caputre Link)、去噪 Link(Nfs Link)、编码 Link(Encoder Link)、解码 Link(Decoder Link)、显示Link(Display Link)等，开发者可以直接利用MCFW中的Link建立需要的视频链路(chain)，无需去研究每一个link的具体实现过程。

2 RTSP协议分析

RTSP(Real-Time Streaming Protocol[5])协议是由 Real Networks和Netscape共同提出的一种客户端到服务器端的多媒体描述协议，它是一个多媒体控制协议，能控制媒体流在IP网络上的实时传输，同时提供视频和音频的远程控制，如快进、后退、暂停/播放等。RTSP在体系结构上位于实时传输协议(Real-time Transport Protocol，RTP)和实时传输控制协议(Real-time Transport Control Protocol，RTCP)之上，它使用 TCP、UDP或 RTP完成数据传输。其体系结构图如图2所示。

图2 RTSP体系结构图

根据RTSP协议的工作原理[6]，RTSP服务器与客户端通过会话交互的方式连接。在一次完整的交互过程中，首先，客户端需要按顺序依次向RTSP服务器发送OPTIONS、DESCRIBE、SETUP、PLAY 命令请求消息，并从RTSP服务器得到反馈信息。然后，客户端再对这些信息进行分析并响应。其中，OPTIONS命令目的是得到服务器提供的可用方法，DESCRIBE命令用于得到会话描述信息(SDP)，SETUP命令提醒服务器建立会话并确定传输模式，PLAY命令告诉服务器开始在SETUP建立的流上传输数据。在播放过程中客户端还可以发送可选命令对媒体流进行控制，比如快进、后退、暂停/播放等。最后，客户端可发送TERADOWN命令请求关闭会话。

3 RTSP服务器系统实现

本文软件架构的设计均在MCFW框架中实现，按照不同的功能进行划分，系统主要分为视频采集、视频处理、视频编码、本地存储以及RTSP服务器5个部分。

3.1 视频采集处理和编码设计

本文通过MCFW中的Link搭建了一条数据链路来实现RTSP服务器前端的视频采集、预处理以及视频编码。该数据链路能完成16路D1 30 Fps的视频采集，通过配置TVP5158视频解码芯片的参数，采集的模拟视频数据经过解码芯片转换成YUV格式数字视频，同时传递给TMS320DM8168内部的4个核心处理器分别进行相应处理，包括 nfs（去噪）、dei（去隔行）、scalar（缩放）和encoder（编码）等。视频编码采用 H.264编码，H.264是一种高性能的视频编解码技术，在具有高压缩比率的同时还能拥有高质量流畅的图像，并可以采用4种压缩方式，分别是 BP（基本画质）、EP（进阶画质）、MP（主流画质）、HP（高级画质）。H.264编码完成后，由 ARM Cortex A8处理器完成H.264视频数据的本地存储和网络传输，本地存储直接采用写文件的形式，存储在SATA硬盘中，具体的数据链路如图3所示。

图3 视频采集编码框图流程

3.2 RTSP服务器设计

RTSP服务器主要实现从TMS320DM8168 Cortex A8端获取编码后的H.264码流并进行RTP封包发送[7]。当接收到客户端的连接请求时，RTSP服务器先完成与该客户端的会话交互，然后把封装好的RTP包发送给客户端。根据RTSP协议的实现原理，RTSP服务器端主要由RTSP会话交互线程和码流获取线程组成。

3.2.1 RTSP会话交互线程

RTSP会话交互线程主要负责RTSP服务器的创建、初始化、关闭以及与客户端之间的消息应答。首先进行套接字创建，建立TCP socket，绑定服务器 IP，用来传送和接收消息，同时进行RTSP端口监听和会话处理，并完成服务器与客户端之间的消息交互。RTSP服务器的会话控制通过TCP连接，监听是否建立在TCP之上，使用RTSP的通用 554端口号和listen（）函数进行监听，当有客户端发出与RTSP服务器进行连接请求时，服务器能立刻监测到，并与客户端建立会话。

会话成功建立后，RTSP服务器会依次接受到客户端发送的会话命令，其中包含IP地址、端口号以及要获取的码流通道等信息，对这些信息进行分析处理后，将该客户端加入会话列表中，使能RTP发送状态并继续监听，查看是否有其他客户端的连接请求并作类似处理，这样便实现了一对多的并发功能。程序流程图如图4所示。

图4 RTSP会话交互线程

3.2.2 码流获取线程

码流获取线程主要实现H.264码流的实时获取、RTP封包及发送。如图5所示，由于TMS320DM8168最多能同时支持16路视频输入，因此该线程包含了16个子线程，每一个子线程分别对应TMS320DM8168的16路视频通道号。首先，利用MCFW中的IpcBitsInLink_getFull-VideoBitStreamBufs（）函数从 TMS320DM8168 Cortex A8 端获取H.264视频数据，分析视频数据的输入通道号，并送入对应的子线程，按照RTP封包策略进行RTP封包。通过标记正确的时间戳以及序列号等信息封装成RTP数据包，然后判断有无客户端存在，若存在客户端且RTP发送状态使能，则利用sendto()函数发送视频数据，发送完后释放资源并返回准备接受下一帧数据；若不存在客户端，则释放资源后返回继续获取码流进行RTP封包。

图5 码流获取线程

RTSP的数据流发送基于RTP/UDP协议，因此，无论是否有客户端发出连接请求，数据都会持续发送。按照RTP数据传输协议的封包格式[8]，RTSP服务器接收到H.264视频数据后，首先过滤出每一帧视频数据的NAL单元，将其装入RTP报文数据负载段进行RTP封包，配置12 B的RTP报文头，包括版本号、标志位、填充位、时间戳、序列号等信息，然后经传输层封装UDP报头，在IP层封装IP报头，最后发送到网络上。由于每一个网络抽象层单元（NALU）包含的数据量不同，其大小也会不一样，因此，当要传输的NALU超过最大传输单元MTU（Maximum Transmission Unit）时，为了减少丢包率，需要进行NALU分片，在以太网中默认的MTU为1 500 B。本系统选择以1 400 B作为最大传输单元，如果一帧视频数据小于1 400 B，一般采用单个NAL单元模式，直接将视频数据进行RTP封包并发送出去，若大于1 400 B，则需要对视频数据进行分割，把NALU单元进行分片RTP封包发送。

4 实验结果及数据分析

本文设计的RTSP服务器流媒体系统运行在TMS320-DM8168嵌入式开发平台上，RTSP服务器端通过实时监听网络上的请求，在与客户端进行RTSP交互认证后，把视频数据发送给客户端，客户端通过IP地址网络访问RTSP服务器，就能实时接收到服务器端发送的视频数据。这里以4路视频为例，图6为利用ffmpeg播放器实时接收RTSP服务器端的4路视频。

视频的延时大小直接体现了服务器端性能的好坏，造成视频延时的原因主要包括以下几部分：视频采集时间、H.264编码时间、RTP打包时间、网络传输时间以及ffmpeg播放器的解码时间。本文分别用H.264的4种画质级别在局域网环境下进行测试，由于ffmpeg播放器的网络缓存时间会对视频的延时产生影响，这里我们采用ffmpeg播放器默认的网络缓存时间，延时情况如表1所示。

表1 远程实时显示延时测试

通过数据分析表明，在稳定的网络环境下，视频画质越高和视频通道数越多，最终的视频延时就越大。经测试，在采集16路D1 30 Fps视频和采用H.264高级画质(HP)编码的情况下，最大的延时为0.84 s，监控视频具有较好的实时性，可以实现流畅、清晰的多路远程视频监控。

5 结论

本文设计并实现了一套基于TMS320DM8168嵌入式平台的RTSP服务器系统。首先以TMS320DM8168为核心实现了16路D1 30 Fps视频的采集、预处理、H.264编码以及本地存储。其次，在远程视频监控方面，以RTSP流媒体协议为基础，设计并实现了RTSP服务器系统。最后，测试结果表明该服务器工作稳定，具有较好的实时性和可靠性。

[1]李军，倪宏，陈君，等.一种应用层协议解析加速算法[J].四川大学学报(工程科学版)，2014(4)：014.

[2]CAI X，OUYANG G，ZHANG X.The design of streaming media video terminal based on embedded linux[C].Future Generation Communication and Networking(FGCN)，2014 8th International Conference on IEEE，2014：68-71.

[3]茅炎菲，黄忠东.基于RTSP协议网络监控系统的研究与实现[J].计算机工程与设计，2011，32(7)：2523-2526.

[4]管庆，朱海，王凯，等.基于 TMS320DM8168的视频监控跟踪系统[J].数据采集与处理，2013(6)：652-657.

[5]RFC2326.Realtimestreamingprotocol(RTSP)[S].

[6]CHU D，JIANG C，HAO Z，et al.The design and implementation of video surveillance system based on H.264，SIP，RTP/RTCP and RTSP[C].Computational Intelligence and Design(ISCID)，2013 Sixth International Symposium on.IEEE，2013，2：39-43.

[7]郑亮.基于DM8168多路视频监控系统研制[D].杭州：杭州电子科技大学，2014.

[8]李校林，刘利权，张杰.基于 RTP的 H.264视频流实时打包传输的研究[J].计算机工程与科学，2012，34(5)：168-171.