CN103442204A

CN103442204A - 一种基于dm365的网络视频传输系统及方法

Info

Publication number: CN103442204A
Application number: CN2013103437951A
Authority: CN
Inventors: 孟利民; 周凯
Original assignee: Zhejiang University of Technology ZJUT
Current assignee: Zhejiang University of Technology ZJUT
Priority date: 2013-08-08
Filing date: 2013-08-08
Publication date: 2013-12-11

Abstract

一种基于DM365的网络视频传输系统，所述网络视频传输系统包括视频设备、服务器和客户端，所述视频设备包括用于采集一路CCD摄像头模拟视频信号并转为数字信号的视频采集模块，用于将采集视频进行H.264标准压缩编码并写入共享内存的视频编码模块，用于将共享内存中的H.264数据打包发送并实现实时视频数据的发送的视频发送模块；所述视频编码模块采用达芬奇芯片DM365，所述服务器中，记录和管理设备、用户信息，转发信令和媒体数据；所述客户端查看视频设备的信息，并进行设备查询、控制和实时监控。以及提供一种基于DM365的网络视频传输方法。本发明清晰度较高、流畅度较好。

Description

一种基于DM365的网络视频传输系统及方法

技术领域

本发明涉及视频监控领域，尤其是一种网络视频传输系统及方法。

背景技术

随着社会的快速发展和人们生活水平的不断提高，公众对安防的意识逐渐加深，社会对安防的需求也随之增长。近来，国内提出了建设“平安城市”的概念，就是使用完整的安全防范系统对城市进行覆盖，包括市内视频监控系统、数字化城市管理系统、道路交通等多个系统，利用市区级数据交换平台实现资源共享，作为视频数据的源头，视频监控系统是重中之重。而在视频监控系统中，视频数据的采集、编码、传输的技术是关键。在这种情况下，网络视频传输系统应用而生，它是一个将网络通信技术、嵌入式技术以及视频缩编码、传输、控制技术相结合的系统，它能够提升网络视频监控系统整体性能，具有较高的工程意义和市场价值。

发明内容

为了克服已有网络视频传输方式的视频清晰度较低、流畅度较差的不足，本发明提供一种清晰度较高、流畅度较好的基于DM365的网络视频传输系统及方法。

本发明解决其技术问题所采用的技术方案是：

一种基于DM365的网络视频传输系统，所述网络视频传输系统包括视频设备、服务器和客户端，所述视频设备包括用于采集一路CCD(Charge-coupled Device,电荷耦合装置)摄像头模拟视频信号并转为数字信号的视频采集模块，用于将采集视频进行H.264标准压缩编码并写入共享内存的视频编码模块，用于将共享内存中的H.264数据打包发送并实现实时视频数据的发送的视频发送模块；所述视频编码模块采用达芬奇芯片DM365，所述服务器中，记录和管理设备、用户信息，转发信令和媒体数据；所述客户端查看视频设备的信息，并进行设备查询、控制和实时监控。

进一步，所述达芬奇芯片DM365芯片具有ARM(Advanced RISCMachines，嵌入式系统)核和DSP(digital signal processor，数字信号处理)协处理器双核模式。

一种基于DM365的网络视频传输方法，摄像头捕获的模拟视频信号首先由TVP5146芯片编码成为YUV格式的视频数据，后经过VPFE(Video Processing Front End，视频处理前端)处理之后，然后再通过TMS320DM365的H.264编码器产生压缩后的H.264视频数据，之后将H.264数据以RTP(Real-time Transport Protocol，实时传输协议)格式通过Internet进行打包发送至服务器；在客户端，首先从服务器接收到RTP包中解析出H.264数据，送至解码器解码，最后将解码后的YUV数据实时播放出来。

进一步，所述视频设备包括视频采集模块、视频编码模块和频发送模块，所述视频设备的视频数据处理过程分为两个进程：视频采集压缩encode进程以及视频发送dev_app进程，其中encode进程主要包括两个线程：负责视频采集的capture线程，负责视频压缩video线程；dev_app进程主要负责：RTP数据的打包发送。

所述视频采集过程如下：在创建VPFE视频采集设备驱动实例前，先要向VPFE驱动注册TVP5146设备，TVP5146将采集的数字信号放入等待队列中；VPFE设备通过ioctl方法不断地从等待队列中读取视频数据到缓冲区；应用程序通过V4L2接口和DMAI(DaVinciMultimedia Application Interface，达芬奇多媒体应用接口)接口获取VPFE驱动中采集的视频数据。

所述视频编码过程如下：配置编码引擎文件encode.cfg，由于DaVinci软件框架是一个高度模块化的编程框架，DaVinci软件的功能实现都已封装成模块，应用程序如果需要使用某个模块，通过配置cfg文件，将用到的模块配置好，之后使用，只要调用API即可；配置cfg文件，主要是配置Codec Engine以及相应的多媒体算法，参考TI提供的编码demo的cfg文件。

视频采集和视频编码的两个线程实现如下：capture线程将采集原始帧数据写入缓存区，通过管道Fifo_put()接口将缓存区地址发送给video线程；video线程通过Fifo_get()接口收到数据后，利用CodecEngine调用H.264编码算法实例进行编码，并把编码好的一帧数据写入共享内存，等待dev_app进程来读取，若没有被读取，video线程进入阻塞状态，整个encode进程也被阻塞。

共享内存的过程如下：首先在两个进程中分别调用createShm()函数申请一块共享内存，各自进程调用shmat()函数将共享内存映射到本进程内存空间中，之后进程就可以对这块共享内存进行操作。

本发明的有益效果主要表现在：（1）结合摄像头以及DM365芯片视频采集前端，采集获取更高的清晰度的视频数据；（2）对于视频压缩功能，采用进程线程同步技术和TI的DM365芯片的特点，实现较高的视频压缩率和较低的功耗；（3）采用开源库JRTPLIB，通过开源库，更快捷的实现视频数据的传输，可充分利用现有资源，减少开发工作量。（4）不需要专门的监控中心或监控管理部门，只要能连接Internet，用户就可使用该视频传输系统，实现实时监控的功能。综上，该系统具有门槛低、网络化、覆盖面广、经济实用、实时性高，清晰度高、功能低等优点。

附图说明

图1是基于DM365的网络视频传输系统的原理框图。

图2是设备端的原理框图。

图3是视频采集模块流程图。

图4是视频编码模块流程图。

图5是采集、编码循环实现图。

图6是共享内存实现图。

具体实施方式

下面结合附图对本发明作进一步描述。

实施例1

参照图1，一种基于DM365的网络视频传输系统，所述网络视频传输系统包括视频设备、服务器和客户端，所述视频设备包括用于采集一路CCD摄像头模拟视频信号并转为数字信号的视频采集模块，用于将采集视频进行H.264标准压缩编码并写入共享内存的视频编码模块，用于将共享内存中的H.264数据打包发送并实现实时视频数据的发送的视频发送模块；所述视频编码模块采用达芬奇芯片DM365，所述服务器中，记录和管理设备、用户信息，转发信令和媒体数据；所述客户端查看视频设备的信息，并进行设备查询、控制和实时监控。

进一步，所述达芬奇芯片DM365芯片具有ARM核和DSP协处理器双核模式。

本实施例的系统由视频设备、服务器、客户端3个部分组成。视频设备是该系统中的数据捕获源，主要指有线网络的前端设备。前端设备主要完成视频的采集、压缩，并通过有线网络发送视频至服务器。客户端在本文指个人电脑监控程序，它可随时查看前端设备的信息，并进行相应的操作，如设备查询、控制和实时监控。服务器是系统中的核心部件，在服务器端需要实现设备、用户信息的记录和管理以及信令和媒体数据的转发。通过该视频传输系统可以实现视频数据的实时监控。

达芬奇芯片DM365，采用H.264编码标准，支持标清/高清视频编码，在视频图像的清晰度和编码效率上都有很大的提升，而且支持常用的网络传输协议。DM365芯片有着特殊的ARM核和DSP协处理器双核模式有着特殊的数据处理方式。DM365视频处理模块由3个模块构成：应用处理层、信号处理层和输入/输出接口层。视频捕获处理模块属于应用处理层，它运行在ARM端，通过Codec Engine的VISAAPI调用DSP协处理器端的H.264编码算法完成视频压缩编码。通过进程线程同步技术，实现采集、编码、发送的同步。

压缩编码后数据通过RTP(Real-time Transport Protocol，实时传输协议)协议传输给视频服务器，服务器转发给客户端。RTP提供了时间戳、序列号，以及其他能够保证传输正确性和有效性的方法，以便于实现时间信息和流信息的同步，实现实时监控。通过开源库JRTPLIB实现视频数据的传输。

参照图1，该网络视频传输系统由客户端、前端视频设备、服务器端3个部分组成。摄像头捕获的模拟视频信号首先由TVP5146芯片编码成为YUV格式的视频数据，后经过VPFE处理之后，然后再通过TMS320DM365的H.264编码器产生压缩后的H.264视频数据，之后将H.264数据以RTP格式通过Internet进行打包发送至服务器。在客户端，首先从服务器接收到RTP包中解析出H.264数据，送至解码器解码，最后将解码后的YUV数据实时播放出来。

实施例2

参照图1～图6，一种基于DM365的网络视频传输方法，摄像头捕获的模拟视频信号首先由TVP5146芯片编码成为YUV格式的视频数据，后经过VPFE处理之后，然后再通过TMS320DM365的H.264编码器产生压缩后的H.264视频数据，之后将H.264数据以RTP格式通过Internet进行打包发送至服务器；在客户端，首先从服务器接收到RTP包中解析出H.264数据，送至解码器解码，最后将解码后的YUV数据实时播放出来。

参照图2，该视频传输系统中，设备端视频处理相关的部分主要是视频的采集、编码、发送。因此将该部分划分为视频采集模块、视频编码模块、视频发送模块三个基本功能模块，而且各功能模块间相互独立又互相联系。网络视频传输系统设备端各个模块功能分别是：视频采集模块：采集一路CCD摄像头模拟视频信号，并转为数字信号；视频编码模块：将采集视频进行H.264标准压缩编码，并写入共享内存；视频发送模块：将共享内存中的H.264数据打包发送，实现实时视频数据的发送。根据模块的划分，整个设备端视频数据处理部分分为两个进程：视频采集压缩encode进程以及视频发送dev_app进程。其中encode进程主要包括两个线程：负责视频采集的capture线程，负责视频压缩video线程。dev_app进程主要负责：RTP数据的打包发送。

参照图3，TI针对DaVinci平台提供了DMAI。DMAI为我们提供了Capture模块来实现视频采集，它处于V4L2和应用程序之间，是对V4L2接口的进一步封装。本系统的视频采集程序是基于DMAI实现的，VPFE在内核中的文件是/dev/video0，所有对VPFE的操作转化成对视频设备文件/dev/video0的操作。总体过程：在创建VPFE视频采集设备驱动实例前，先要向VPFE驱动注册TVP5146设备，TVP5146将采集的数字信号放入等待队列中；VPFE设备通过ioctl方法不断地从等待队列中读取视频数据到缓冲区；应用程序通过V4L2接口和DMAI接口获取VPFE驱动中采集的视频数据。

参照图4，H.264编码标准提供了Baseline-profile和high-profile两种编码标准，我们使用TI官方提供的H.264Baseline Profile的demo包，其中包含了编译好的H.264Codec算法实例。我们这里的视频编码程序也是基于Codec Engine编写的。编写应用程序之前，首先配置编码引擎文件encode.cfg，由于DaVinci软件框架是一个高度模块化的编程框架，DaVinci软件的功能实现都已封装成模块，应用程序如果需要使用某个模块，通过配置cfg文件，将用到的模块配置好，之后使用，只要调用API(Application Programming Interface，应用程序接口)即可。配置cfg文件，主要是配置Codec Engine以及相应的多媒体算法，参考TI提供的编码demo的cfg文件。

参照图5，视频流处理的同步即进入主循环后的同步。两个线程都初始化完毕后，进入主循环，在主循环中两个线程分别实现视频采集、视频编码的过程。具体过程：capture线程将采集原始帧数据写入缓存区，通过管道Fifo_put()接口将缓存区地址发送给video线程；video线程通过Fifo_get()接口收到数据后，利用Codec Engine调用H.264编码算法实例进行编码，并把编码好的一帧数据写入共享内存，等待dev_app进程来读取，若没有被读取，video线程进入阻塞状态，整个encode进程也被阻塞。

参照图6，具体过程为：首先在两个进程中分别调用createShm()函数申请一块共享内存，各自进程调用shmat()函数将共享内存映射到本进程内存空间中，之后进程就可以对这块共享内存进行操作。进程操作共享内存主要有读取和写入两种操作。按照视频流传递的方向，encode进程将H.264流写入共享内存，而dev_app进程从内存读取H.264流。两个进程的同步采用信号量的方式实现。信号量(Semaphore)是一种多线程（进程）访问共享资源进行控制的机制，一种用于解决互斥共享资源的同步问题而引入的机制。信号量通过PV操作来实现进程的同步和互斥。一般上来说，信号量S>=0，S表示可用资源的数量。执行一次P(S)操作代表请求分配一个单位资源，S减1；当S小于0时，表示无可用资源，请求进程必须等待的进程释放该类资源，才能运行下去。而执行一次V(S)操作表示释放一个单位资源，S加1；若S小于0，表示有进程正在等待该资源，因此可以唤醒一个等待状态的进程去运行。本项目中，给共享内存申请两个信号量write和read，初始赋值：write=1（共享内存可写），read=0（共享内存不可读）。encode进程将要写入共享内存时，进行P(write)操作，此时write=0（共享内存不可写），V(read)，read=1（共享内存可读），经过一次写入操作之后，共享内存状态变成可读不可写，video线程处于阻塞状态。同样，在dev_app进程处，因为此时共享内存的read信号量大于0，表示可读，dev_app进程进行P(read)操作，read=0，正常读取视频数据之后，进行V(write)操作，write=1，经过一次读取操作之后，共享内存状态变成可写不可读。encode进程和dev_app进程通过对共享内存读写，完成同步。encode进程中共享内存读写操作代码如下所示，dev_app进程中共享内存读写操作与其类似。

Claims

1.一种基于DM365的网络视频传输系统，其特征在于：所述网络视频传输系统包括视频设备、服务器和客户端，所述视频设备包括用于采集一路CCD摄像头模拟视频信号并转为数字信号的视频采集模块，用于将采集视频进行H.264标准压缩编码并写入共享内存的视频编码模块，用于将共享内存中的H.264数据打包发送并实现实时视频数据的发送的视频发送模块；所述视频编码模块采用达芬奇芯片DM365，所述服务器中，记录和管理设备、用户信息，转发信令和媒体数据；所述客户端查看视频设备的信息，并进行设备查询、控制和实时监控。

2.如权利要求1所述的基于DM365的网络视频传输系统，其特征在于：所述达芬奇芯片DM365芯片具有ARM核和DSP协处理器双核模式。

3.一种用如权利要求1所述的基于DM365的网络视频传输系统实现的方法，其特征在于：摄像头捕获的模拟视频信号首先由TVP5146芯片编码成为YUV格式的视频数据，后经过VPFE处理之后，然后再通过TMS320DM365的H.264编码器产生压缩后的H.264视频数据，之后将H.264数据以RTP格式通过Internet进行打包发送至服务器；在客户端，首先从服务器接收到RTP包中解析出H.264数据，送至解码器解码，最后将解码后的YUV数据实时播放出来。

4.如权利要求3所述的方法，其特征在于：所述视频设备包括视频采集模块、视频编码模块和频发送模块，所述视频设备的视频数据处理过程分为两个进程：视频采集压缩encode进程以及视频发送dev_app进程，其中encode进程主要包括两个线程：负责视频采集的capture线程，负责视频压缩video线程；dev_app进程主要负责：RTP数据的打包发送。

5.如权利要求3或4所述的方法，其特征在于：所述视频采集过程如下：在创建VPFE视频采集设备驱动实例前，先要向VPFE驱动注册TVP5146设备，TVP5146将采集的数字信号放入等待队列中；VPFE设备通过ioctl方法不断地从等待队列中读取视频数据到缓冲区；应用程序通过V4L2接口和DMAI接口获取VPFE驱动中采集的视频数据。

6.如权利要求3或4所述的方法，其特征在于：所述视频编码过程如下：配置编码引擎文件encode.cfg，由于DaVinci软件框架是一个高度模块化的编程框架，DaVinci软件的功能实现都已封装成模块，应用程序如果需要使用某个模块，通过配置cfg文件，将用到的模块配置好，之后使用，只要调用API即可；配置cfg文件，主要是配置CodecEngine以及相应的多媒体算法，参考TI提供的编码demo的cfg文件。

7.如权利要求6所述的方法，其特征在于：视频采集和视频编码的两个线程实现如下：capture线程将采集原始帧数据写入缓存区，通过管道Fifo_put()接口将缓存区地址发送给video线程；video线程通过Fifo_get()接口收到数据后，利用Codec Engine调用H.264编码算法实例进行编码，并把编码好的一帧数据写入共享内存，等待dev_app进程来读取，若没有被读取，video线程进入阻塞状态，整个encode进程也被阻塞。

8.如权利要求6所述的方法，其特征在于：共享内存的过程如下：首先在两个进程中分别调用createShm()函数申请一块共享内存，各自进程调用shmat()函数将共享内存映射到本进程内存空间中，之后进程就可以对这块共享内存进行操作。