数字视频监控系统

一、论文用A4（210×297mm）大小的白纸打印 毕业设计（论文） 数字视频监控系统 客户端的设计与实现 学 院: 计算机科学技术学院 专 业： 姓 名： 指导老师： 软件工程 伍智斌 学 号： 职 称： 0602231022 肖友清 讲师 中国·珠海 二○一○年五月 北京理工大学珠海学院毕业设计 诚信承诺书 本人郑重承诺：我所呈交的毕业设计《数字视频监控系统客户端的设计与实现》是在指导教师的指导下，独立开展研究取得的成果，文中引用他人的观点和材料，均在文后按顺序列出其参考文献，设计使用的数据真实可靠。 承诺人签名： 日期： 年 月 日 数字视频监控系统客户端的设计与实现 摘 要 数字视频监控系统的客户端的需求主要来自于远程视频监控，面对计算机和移动设备的普及，用户已经不再满足于只能在监控室或保安室里观看查看监控视频，用户希望能随时随地地通过计算机和移动设备远程地查看他们关心的监控视频。为了满足需求，数字视频监控系统的客户端已经成为了数字视频监控系统中重要的组成部分。 数字视频监控系统是以数字视频处理技术为核心，综合利用光电传感器、计算机网络、自动控制和人工智能等技术的一种新型监控系统。与数字视频监控系统相关的主要技术有视频数据压缩，视频的分析与理解，视频流的传输与回放和视频数据的存储。而数字视频监控系统中的远程监控客户端则是使用现代计算机技术和现代网络技术实现远程实时视频监控。 本文介绍在HiRay公司基于TI DM365SoC的数字视频监控系统上，使用Gstreamer框架实现数字视频监控系统中客户端软件。 关键词：数字视频 远程监控 视频监控 流媒体 GStreamer DM365 Digital Video Surveillance System Design and Implementation of the client ABSTRACT Digital Video Surveillance System client demand mainly comes from the remote video monitoring, the face of the popularity of computers and mobile devices, users are no longer satisfied only in the control room or security room watching view the surveillance video, the user would like to anytime, anywhere computers and mobile devices through the remote to view the surveillance video they care about. To meet demand, digital video monitoring system client digital video surveillance has become an important part of the system. Digital video surveillance system is based on digital video processing technology as the core, comprehensive utilization of photoelectric sensors, computer networks, automatic control and artificial intelligence technology, a new monitoring system. Digital Video Surveillance System with the main technologies related to video data compression, video analysis and understanding of video streaming and video transmission and playback of data storage. The digital video surveillance system remote monitoring client is the use of modern computer technology and modern network technology for remote real-time video surveillance. This article describes the company based on TI DM365SoC in HiRay digital video surveillance systems, using the Gstreamer framework for digital video monitoring system client software. Key words：Digital Video Remote Surveillance Gstreamer DM365 目 录 TOC \o "1-3" \u 摘 要 I ABSTRACT II 目 录 III 1绪论 1 1.1课题研发的目的与意义 1 1.2 视频监控技术的发展趋势 2 2客户端#设计# 4 2.1设计要求 4 2.2设计方案 4 2.2.1 DirectShow 4 2.2.2 VLC 5 2.2.3 MPlayer 6 2.2.4 GStreamer 7 3 Gstreamer基本概念 11 3.1 元素和插件 11 3.2 箱柜和管道 11 3.3 衬垫 12 3.4 缓冲 12 3.4 缓冲 13 4 客户端的实现 15 4.1视频回放管线的实现 15 4.1.1 udworklive 元件的实现 16 4.1.2 udworksdemux 元件的实现 19 4.2通用设备管理的实现 19 5 结论 24 参考文献 25 附 录 26 谢 辞 34 1绪论 视频监控近年来得到了迅速的发展，应用范围不断地扩展。以往国内使用的视频监控系统主要是模拟系统，到了20世纪90年代末，随着网络带宽、计算机处理能力和存储容量的迅速提高，以及各种实用视频信息处理技术的出现，视频监控从模拟视频监控进入了数字化的网络时代，即数字视频监控系统。数字视频监控系统将摄像机获得的模拟视频信号转变为数字视频信号，便于计算机处理，或者由数字摄像机直接输出数字视频信号。在计算机显示器上显示多路实时活动图像的同时，还可将各路信号分别存储于计算机的硬盘内，或者在网络上进行传输。数字视频监控系统以计算机为中心，信息处理技术为基础，是符合图像数据压缩的国际标准 (JPEG、MPEG-4或H.264)，综合利用图像传感器、计算机网络、自动控制和人工智能等技术的一种新型监控系统。 1.1课题研发的目的与意义 带网络应用的日趋普及以及数字技术在安防产品中的应用，为整个安防产业带来革命性的改变。在图像监控产品领域，数字网络技术的导入大大拓宽了产品的应用范围，使得以往费用代价高昂或难以实现的远程监控应用变得轻而易举，远程医疗会诊、远程幼儿看护、连锁店远程监控管理、街道治安远程监控、考场远程监控、海关进出口远程监控、网吧远程监控等新兴应用脱颖而出，市场前景日益广泛。中国成功申办“2008年奥运会”和“2010年亚运会”，为体育场馆建设创造不可限量的商机。幼儿园的安全问题是学生家长和幼儿园管理者最担心的问题。是否有一套安全可靠的安防监控系统和身份识别系统，已经成为了家长选择幼儿园的一项重要标准。网络视频监控打造平安的体育场馆 中国成功申办“2008年奥运会”和“2010年亚运会”，为体育场馆建设创造不可限量的商机。以 2008年北京奥运会为例，为满足比赛的需要，中国北京计划准备37座一流比赛场馆，58个训练场馆，其中14座为新建场馆，对场馆设施安全性、先进性的要求也提到空前的高度，“人文奥运、绿色奥运、科技奥运”的理念将贯穿所有奥运场馆建设；而2010年的广州亚运会则同样令人兴奋不已，据了解广东省为迎接这一亚洲体坛盛事，计划兴建或改造44座场馆，其中新建场馆12座，其中包括广东奥林匹克体育中心体育馆、广州极限运动基地自行车赛场、白云体育馆等大型建筑。 大型体育场馆属于比较特殊的建筑，它专为举办运动赛事而建，因此其安防系统在使用上具备鲜明的特点：首先体育场馆属于大型的综合性公共设施，建设目的是为了综合性、高等级的体育赛事，体育场馆安防设施是为了保障大型比赛开幕、闭幕和人员撤离的安全而设，保证各项赛事完满举行，万无一失；另一方面一旦比赛结束，人群散去，安防设施也就没有赛时那么突出了，这时候安防设施将主要为体育场馆内的健身休闲、信息服务、会展服务以及商贸区、居住小区的日常生活提供安全保障来解决会场安全、物品安全、防盗等一系列问题。 运动场馆的安防设计主要考虑以下方面： 1、人员密集区 召开正式比赛、运动会时，体育场满座可达数万名观众，这么多的人员聚集在一个区域内，本身就存在很大的安全保障问题。对视频监视系统的要求是系统可靠、稳定，反应速度快捷，能够在第一时间发现警情，并且具有多种联动功能，可以及时通知各个安全保卫部门做出最及时的反应，并且在事后可以保存下全部过程的图像，作为重要资料备查。 2、来宾、要员保护由于将要承办奥运会这样的大型国际性赛事，与会的包括各国首脑、奥委会官员、国家及省市的官员、国外媒体记者、各界知名人士、运动明星等等。对于这些人员需要我们对他们的行动进行特别的、重点的监视与保护。需要对重要设施实施24小时实时监控；对重要领导、重要运动员所在区域、所经通道等实施重点全方位不间断跟踪保护，保证他们的安全。 3、运动中心整体防护运动场馆一般是一个由主体育场、训练场、体育馆、游泳馆、商业区等组合而成的一个建筑群，在我们设计安全防范系统的整体方案时，不仅要考虑主体育场本身的安全防护需要，还要从体育中心这一建筑群的整体出发，为其设计安全有效的技术防范体系。 4、赛场防暴与反恐 历史上球场暴力、球迷骚乱导致大规模人员伤亡的事件屡见不鲜，加之当前世界各国都在加强反恐怖力量，对抗恐怖主义分子发动的突然袭击。从这个角度出发，一定要采取必要的技术手段，加强防范措施，坚决杜绝此类事件的发生。要求前端设备能对敏感地区及目标实行电子布防、撤防，同时可以与周界报警、防盗报警、紧急报警、门禁报警系统联动，报警后调出相应防区的电子地图，同时弹出实时图像，并对目标进行跟踪和锁定，并可与摄像机进行联动报警。 5、场内重要设施的防护体育场内的空调、照明、水、电、消防等系统保证了体育场的正常运行，这些大型设备的安全同样不容忽视。另外，体育场内的商贸区、娱乐区在日常营业过程中，需要提供必要的技术措施来解决物品安全、防盗等一系列问题。 我们以天津某大型体育场馆监控系统为例，描述一下天地伟业网络视频监控系统在运动场馆中的实际应用，系统的核心是天地伟业高清网络视频服务器、预置位网络一体球、网络矩阵。 在室外广场、大门口、室内场地、观众席、主席台、记者席、新闻中心等多处需要快速反应、瞬时定位的场所大量应用智能高速球型摄像机，摄像机视频信号接入 1.2 视频监控技术的发展趋势 随着社会的不断进步，技术以一种前所未有的速度发展并越来越深入的应用到各个领域。同样在监控领域，技术仍然是行业发展的主导推动力。 当前在国内外市场上，前端设备一体化、视频图像处理数字化和智能化、监控传输网络化、系统集成化是视频监控系统的主要发展方向。而数字化和智能化是网络化的前提，网络化又是系统集成化的基础，系统集成化的发展将赋予视频监控系统更为广阔的应用空间。 视频监控系统的数字化和智能化是将系统中的信息流(包括视频、音频、控制等)从模拟状态转为数字状态，根本上改变视频监控系统从信息采集、数据处理、传输、系统控制的方式和结构形式。信息流的数字化、编码压缩、开放式的、视频图像智能化分析与处理，使视频监控系统与安防系统中其它各子系统间实现无缝连接，并在统一的操作平台上实现管理和控制，这也是系统集成化的含义。 视频监控系统的网络化意味着系统的结构将由集总式向集散式系统过渡。 集散式系统采用多层分级的结构形式，具有微内核技术的实时多任务、多用户、分布式操作系统以实现抢先任务调度算法的快速响应。组成集散式监控系统的硬件和软件采用标准化、模块化和系列化的设计，系统设备的配置具有通用性强、开放性好、系统组态灵活、控制功能完善、数据处理方便、人机界面友好以及系统安装、调试和维修简单化，系统运行互为热备份，容错可靠等优点。监控系统网络化将使整个网络系统硬件和软件资源的共享以及任务和负载的共享，这也是系统集成的一个重要概念。 目前，随着计算机技术、网络技术、图像处理技术、GIS技术在视频监控系统中的深入应用。视频监控系统从单一的视频图像监看、录像、回放向关联视频图像同步监看、录像、回放的方向发展，比如同一时段的多点同步回放，单点不同时段的同步回放；从视频图像的简单监看、录像、回放向视频图像智能化分析处理的方向发展，比如动态物体的侦测与分类、特定绊线的监控、长时间滞留报警、遗留物危害性判别等智能化分析处理的应用；从基于多媒体电子地图的应用向具有矢量概念GIS平台的整合的方向发展，比如动态跟踪监控、设置防御层、定义监控场景等功能的应用；从单一产品、单一系统向多产品多系统的集成与联动的方向发展，比如与其他安防系统、公安110接处警指挥系统和智能卡口系统等联动集成，实现信息资源共享；逐步实现从被动监控向主动监控的方向发展。 2客户端设计方案 2.1设计要求 数字视频监控系统中的客户端软件的作用主要是让用户通过网络远程地观看DVR或IPC的实时视频。所以数字视频监控系统客户端的主要需求是远程和实时，为了实现远程需要有可靠的网络传输保障，而实时则需要远程的编码性能，传输性能和本地的解码性能同时保障。数字视频监控系统客户端在实际生产环境中衍生出来的需求是广泛，根据经验的总结衍生的需求主要有以下几方面：客户端软件的国际化支持，主要表现为和用户交互的语言和风俗习惯；客户端软件的跨平台支持，主要表现为需要支持Mac和Linux平台，尤其是Mac平台在北美地区市场占有率接近10%。 2.2设计方案 数字视频监控系统中的客户端软件的设计方案主要由视频回放，通用设备管理与控制两部分组成。视频回放管线方案： 2.2.1 DirectShow DirectShow（有时缩写如DS 或DShow），开发代号Quartz ，是一种由微软公司开发的能够让软件开发者对媒体文件执行各种不同处理的应用程序设计接口。它是微软公司对早先Windows 视频科技的一次更新。基于微软公司Windows 构成物件模型（COM）框架，DirectShow 为大部份微软公司程序设计语言提供了一个媒体的普遍接口，而且是一个可扩展的，能在使用者或开发者的命令下播放或记录媒体文件的，以Filter为基础的框架。 DirectShow 开发工具及凭证被加入到微软公司SDK 平台的一部份。 Windows Media Player 这样的应用程序运用DirectShow 或者它的各种衍生来播放来自文件或是互联网上的内容。 DirectShow's 的最值得注意的竞争是苹果计算机的QuickTime 框架。 应用程序与DirectShow组件以及DirectShow所支持的软硬件之间的关系，DirectShow的概览图如下： 图2-1 DirectShow概览图 2.2.2 VLC VLC 多媒体播放器（最初为VideoLAN Client，是VideoLAN计划的多媒体播放器。）支援众多音讯与视讯解码器及档案格式，并支援DVD影音光碟，VCD影音光碟及各类串流协定。它也能作为unicast 或multicast的串流伺服器在IPv4 或IPv6的高速网路连线下使用。调用FFmpeg计划的解码器与libdvdcss程式库使其有播放多媒体档案及加密DVD影碟的功能。VLC概览图如下 图2-2 VLC概览图 2.2.3 MPlayer MPlayer是一款为Linux编写的电影播放器(在其他Unix 上也可运行，并且很多非x86CPU。）。它能播放大部分由许多本地，XAnim，RealPlayer及Win32 DLL解码器支持的MPEG, VOB, AVI, OGG/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA, Matroska文件。你也可以观看 VideoCD, SVCD, DVD, 3ivx, RealMedia, Sorenson, Theora, 及MPEG-4 (DivX)影片。MPlayer 另外一个很大的特点是支持广泛的输出驱动。它能工作在X11, Xv, DGA, OpenGL, SVGAlib, fbdev, AAlib, libcaca, DirectFB下，但你可以使用GGI及SDL(此种方式下的所有驱动) 以及一些低端的特定显卡驱动(针对Matrox, 3Dfx及Radeon, Mach64, Permedia3)！他们大多数支持软件或硬件视频伸缩，所以你能以全屏幕欣赏影片。 MPlayer支持一些硬件MPEG解码器的显示，例如 DVB及DXR3/Hollywood+。并且你认为那些又大又漂亮的不重名的有阴影修饰的包括欧洲ISO 8859-1,2（匈牙利语，英语，捷克语等等），西里尔语，韩语字体的子标题 (支持14种类型)，以及屏幕显示(OSD) 此播放器能稳定的播放损坏的MPEG文件（对于一些VCD很有用），并且它能播放著名的 windows media player不能播放的损坏的AVI文件。甚至能播放没有索引部分的AVI文件，并且你还可以用-idx选项暂时重建索引，或者用 MEncoder永久性的建立索引，以此支持定位查找！如你所见，稳定性及质量是最重要的，但速度也让人赞叹。还有一套强大的拥有视音频处理功能的滤镜系统 2.2.4 GStreamer GStreamer是一个创建流媒体应用程序的框架。其基本设计思想来自于俄勒冈(Oregon)研究生学院有关视频管道的创意, 同时也借鉴了DirectShow的设计思想。 GStreamer的开发框架使它有可能被用来编写任何类型的流媒体应用程序。基于GStreamer的程序开发框架使得编写任意类型的流媒体应用程序成为了可能。在编写处理音频、视频或者两者皆有的应用程序时, GStreamer可以让你的工作变得简单。GStreamer并不受限于音频和视频处理, 它能够处理任意类型的数据流。管道的设计对于一般应用的滤镜（filter）绰绰有余。这使得GStreamer成为一个优秀的框架，它甚至可以用来设计出对延时有很高要求的高端音频应用程序。 GStreamer最显著的用途是在构建一个播放器上。GStreamer已经支持很多格式的文件了, 包括:MP3, Ogg/Vorbis, MPEG-1/2, AVI, Quicktime, mod等等。从这个角度看,GStreamer更象是一个播放器。但是它主要的优点确是在于: 它的可插入组件能够很方便的接入到任意的管道当中。这个优点使得利用GStreamer编写一个万能的可编辑音视频应用程序成为可能。 GStreamer框架是基于插件的, 有些插件中提供了各种各样的多媒体数字信号编解码器,也有些提供了其他的功能。所有的插件都能够被链接到任意的已经定义了的数据流管道中。GStreamer的管道能够被GUI编辑器编辑, 能够以XML文件来保存。这样的设计使得管道程序库的消耗变得非常少。 GStreamer核心库函数是一个处理插件、数据流和媒体操作的框架。 GStreamer核心库还提供了一个API, 这个API是开放给程序员使用的---当程序员需要使用其他的插件来编写他所需要的应用程序的时候可以使用它。Gstreamer的概览图如下： 图2-3 Gstreamer概览图 设计是跨平台的，它是已知的在Linux上工作（86，PowerPC和ARM），Solaris操作系统（英特尔和SPARC）和OpenSolaris的FreeBSD，OpenBSD以及NetBSD和Mac OS X，微软Windows和OS/400。 GStreamer的已编程一样的Python，瓦拉的C + +，Perl中，吉尔和Ruby语言的GNU绑定。 GStreamer的授权下的GNU通用公共许可证。 综合上边的多种技术方案，最终以需求作为依据，选择了GStreamer做为视频回放管线的实现基础。首先，VLC和MPlayer虽然都是优秀的开源多媒体播放器项目，而且VLC更加有优秀的的插件结构，非常适合进行二次开发使用。当VLC和MPlayer的项目基础都是以多媒体播放器为目标，对于多视频数据流的并发的支持有较明显的不足，主要表现为对多个视频数据流的高精度同步的支持问题，因为作为一个媒体播放器，对多个视频数据流的同步问题明显不在需求的范围之内。然后，DirectShow和GStreamer是非常相识的技术，它们都是要实现一个通用的多媒体框架，而且它们的实现都基于非常相识的技术基础。至于选GStreamer而不是DirectShow主要是因为GStreamer能够很好地实现对跨平台支持，并且能和GTK等UI框架实现完美的兼容，而DirectShow是Microsoft Windows平台的专属技术 2.3 通用设备管理与控制 关于设备管理与控制没有现成的方案可以参考，需要自行设计和实现 。考虑到以后对新类型设备的兼容和支持，设备将会被以树形结构加以组织，最终将组成一棵设备数。如下图： 、图1-2 通用设备管理类图 所有的设备类型都将继承于Device这个根类型，Device类派生出RootDevice类和SubDevice类。RootDeivce类是现实设备的一个抽象，RootDevice类的所有子类对应现实的一类具体设备，实现对这类设备的支持，RootDevice类的子类的实例对应一台本地或远程的设备。如图中的dm365Dvr，就是一类使用TI dm365 SoC的并支持UD works的视频协议的DVR设备，内部的命名为 DM365DVR－1。而fh35Dvr则是一个计划中产品，将会在以后的版本中提供支持。SubDevice类是对现实设备的一部分功能的抽象，与RootDevice类的根本区别在于SubDevice类并不对应一个具体的设备。SubDevice类可能只是对应RootDevice类的一部分功能，而RootDevice类实例可能会包含多个SubDevice类实力。如上图中的dm365Camera类，所抽象的是一个视频摄像机，对应了一个视频数据流的处理流程。而一个DM365DVR－1设备可以同时处理4个或8个视频数据流，所以dm365Dvr类实例可能包含4或8个dm365Camera实例，而dm365Dvr具备本地的存储功能，所以dm365Dvr的实例将会包含一个LocalStorage类的实例 3 Gstreamer基本概念 3.1 元素和插件 元件是GStreamer的核心。在插件的开发中，一个元件就是继承于 GstElement的一个对象。元件在与其他元件连接时提供了如下一些功能 ：例如，一个源元件为一个流提供数据，一个滤镜元件对流中的数据进行操作。没有了元件，GStreamer只是一堆概念性的管道，没有任何东西可供连接 。GStreamer已经自带了一大堆元件，但是我们仍然可以编写额外的元件。 然而，仅仅写一个新的元件并不够，为了使GStreamer能够使用它，你必须将元件封装到一个插件中。一个插件是一块可以加载的代码，通常被称为共享对象文件（shared object file）或动态链接库（dynamically linked library）。一个插件中可以包含一个或若干元件。为简单起见，本手册主要涉及只包含一个元件的插件。 滤镜是一类处理流数据的重要插件。数据的生产者和消费者分别被称为source和sink元件。 箱柜（Bin）元件可以包含其它的元件。箱柜的主要职责是调度它包含的元件并使得数据流更平滑。热插拔（autoplugger）元件是另一种箱柜，它可以动态的加载其它元件，并将它们连接起了形成一个可以处理两个任意流的滤镜。 GStreamerr充斥着插件的概念，即使你只使用到一些标准的包。核心库中只有少量基本函数，其它所有的功能都由插件来实现。一个XML文件被用来保存所有注册的插件的详细信息。 这样，使用GStreamer的程序可以只在需要时加载插件，而不必事先全部加载。插件也只在需要它们的元件时才被加载。 3.2 箱柜和管道 箱柜(Bins)是一个可以装载元件(element)的容器。管道(pipelines)是箱柜(Bins)的一个特殊的子类型,管道(pipelines)可以操作包含在它自身内部的所有元件(element)。因为箱柜(Bins)本身又是元件(element)的子集,所以你能够象操作普通元件(element)一样的操作一个箱柜(Bins), 通过这种方法可以降低你的应用程序的复杂度。你可以改变一个箱柜(Bins)的状态来改变箱柜(Bins)内部所有元件(element)的状态。箱柜(Bins)可以发送总线消息(bus messages)给它的 子集元件(element)(这些消息包括:错误消息(error messages),标签消息(tag messages),EOS消息(EOS messages))。 管道(pipeline)是高级的箱柜(Bins)。当你设定管道的暂停或者播放状态的时候,数据流将开始流动,并且媒体数据处理也开始处理。一旦开始,管道将在一个 单独的线程中运行,直到被停止或者数据流播放完毕 3.3 衬垫 在GStreamer中，衬垫是用来在元件间协商连接和数据流的。衬垫可以看作元件间互相连接的 “接口”，数据流通过这些接口流入流出元件。Pad具有特殊的数据处理能力：衬垫可以限制通过它的数据类型。只有当两个衬垫允许通过的数据类型兼容时才可以将它们连接起来。 也许打一个比方可以有助于理解这些概念。衬垫类似于物理设备上的a plug or jack。想象一个包含功放，DVD播放器和一个视频投影仪器的家庭影院系统。将投影仪和DVD播放器相连是允许的，因为这两个设备具有兼容的video jacks。而要将投影仪和功放连起来也许就行不通了，因为它们之间的jack不同。GStreamer中的衬垫具有和家庭影院系统中的jack相同的功能。 大部分情况下，所有在GStreamer中流经的数据都遵循一个原则。数据从元件的一个或多个源衬垫流出，从一个或多个sink衬垫流入。源和sink元件分别只有源和sink衬垫。 3.4 缓冲 缓冲区是一块可以存放各种数据的内存。缓冲区的内存一般用malloc()函数分配。这样虽然很方便，但不总是最高效，因为数据经常需要被显式的拷入缓冲区。 有些特殊的元件创建指向特殊内存的缓冲区。例如，filesrc 元件通常会（使用 mmap()）将一个文件映射到应用程序的地址空间，并创建指向那个地址范围的缓冲区。这些由filesrc创建的缓冲区具有和其它通用的缓冲区一样的行为，唯一的区别是它们是只读的。释放缓冲区的代码将自动检测内存类型并使用正确的方法释放内存。 另一种可能得到特殊缓冲区的途径是向下游同伙（downstream peer）发出请求。这样得到的缓冲区称为downstream-allocated缓冲区。元件可以请求一个连接到源衬垫的同伙创建一个指定大小的空缓冲区。如果下游元件可以创建一个正确大小的特殊缓冲区，它将会这样做。否则，GStreamer将会自动创建一个通用缓冲区。接着，请求缓冲区的元件就可以将数据拷入缓冲区，并将缓冲区push给创建它的源衬垫。 许多sink元件的将数据拷到硬件的函数都经过了优化，或者可以直接操作硬件。这些元件为它们的上游伙伴创建downstream-allocated缓冲区是很平常的事。其中一例是ximagesink。它创建包含XImage的缓冲区，因此当一个上游伙伴将数据拷入缓冲区时，数据被直接拷入XImage，这样ximagesink可以直接将图象画到屏幕上而不用先将数据拷到一个 XImage中。 滤镜元件通常有机会可以直接作用于缓冲区，或者在将数据从源缓冲区拷入目标缓冲区时发生作用。最佳方案是两种算法都予以实现，因为GStreamer框架会在可能的时候选择最快的算法。自然地，这只在元件的源和sink衬垫完全一致的情况下才有效果 3.4 缓冲 GStreamer使用一个类型系统来保障流经元件的数据格式是可识别的。当连接元件中的衬垫时，类型系统对于确保特定的参数有着非常重要的作用，这些参数对正连接的元件间的衬垫的格式匹配有着特定作用。元件间的每一个连接有一个指定的类型和可选的属性集。 GStreamer已经支持许多基本的媒体类型。下表是GStreamer中的缓冲区所使用的一些基本类型。表中包含了类型的名字("mime type")和对类型的描述，类型相关的属性，以及每个属性的意义。已定义类型列表一节中列出了所有支持的类型。 Mime 类型 描述 属性 属性类型 属性值 属性描述 audio/* 所有音频类型 rate 整型 大于0 数据的采样率，每秒的样本数（每个声道）。 channels 整型 大于0 音频数据的声道数。 audio/x-raw-int 未结构化的及未压缩的原始整型音频数据. endianness 整型 G_BIG_ENDIAN (1234) or G_LITTLE_ENDIAN (4321) 样本的字节序列。 signed 布尔型 TRUE或FALSE 整型样本值是否带符号。 带符号的样本值用一个位来指示符号位（正或负）。不带符号的样本值总为正。 width 整型 大于0 每个样本的最大位数。 depth 整型 大于0 每个样本所使用的位数。 audio/mpeg 使用MPEG音频算法压缩过的音频数据。 mpegversion 整型 1, 2或4 压缩数据的MPEG-版本。值1表示MPEG-1, -2 和-2.5 layer 1, 2或3。值2和4表示MPEG-AAC 音频压缩算法。 framed 布尔型 0或1 true值表示每个缓存只包含一帧。false 值表示缓存数和帧数并不是1：1。 layer 整型 1, 2,或3 用来压缩数据的压缩策略层次。 (only if mpegversion=1). bitrate 整型 大于0 位率，每秒的位数。对于VBR (variable bitrate) MPEG 数据，这是个平均位率。 audio/x-vorbis Vorbis 音频数据       对这种类型的数据通常没有特定的属性。 表3-1 MIME 类型表 4 客户端的实现 4.1视频回放管线的实现 图4-1演示程序运行效果图 视频回放管线由Gstreamer的元件对像组成，共分为7个部分。分别是udworkslive,udworksdemux,queue,ffdec_h264,ffmpegcolorspace,videoscale,cluttersink。udworkslive负责网络协商和接收数据，udworksdemux负责多接受到的数据进行缓冲和解复合，queue的作用主要是避免管线被堵塞，ffdec_h264是ffmpeg的一个分包，通过调用ffmpeg对H.264码流进行解码，ffmpegcolorspace把解码后的每一视频帧进行从YUV到RGB的色彩空间转换，接着videoscale对每一视频帧进行缩放，最后由cluttersink复制把每一个视频帧贴图投影到OpenGL的3D空间中。其中queue,ffdec_h264,ffmpegcolorspace,videoscale是GStreamer已经实现的元件。cluttersink是clutter库里实现的元件。udworkslive和udworksdemux需要自行实现，因为与DVR产品的底层协议密切相关，故没有的现成的通用元件可以提供支持。 图4-2在终端里用命令行运行视频回放管线 udworklive和udworksdemux实现的是韩国UDworks公司的网络视频协议。 4.1.1 udworklive 元件的实现 udworkslive继承于Gstreamer的GstBaseSrc 元件，继承了基本source elemnt的所有功能。然后重载了start函数，stop函数和create函数。代码如下： base_src_class->get_caps = gst_udworks_live_src_getcaps; base_src_class->start = gst_udworks_live_src_start; base_src_class->stop = gst_udworks_live_src_stop; base_src_class->unlock = gst_udworks_live_src_unlock; base_src_class->unlock_stop = gst_udworks_live_src_unlock_stop; push_src_class->create = gst_udworks_live_src_create start函数在管线的状态从NULL变化到READY的时候被调用，主要实现和远程设备的协商。首先客户端要向服务器端进行认证，客户端会向服务器的一个指定端口发起TCP链接，请求一个Public Key，然后客户端会用接收到的Public Key对将要发送给服务器的认证信息进行加密，最后服务器端会返回一个认证结果，如果用户信息和PublicKey均为有效，客户端将会收到一个AuthValue，这个值将会在以后和服务器的交流中用于认证。客户端和服务器的认证协议如下图： 图4-3 远程认证过程示意图 相反stop函数则在管线的状态从READY变化为NULL的时候被调用，主要实现优雅地中断和远程设备的链接。在断开auth port上的链接前要先保证control port和data port上的链接已经断开。 create函数则最为重要，实现从远程设备读取数据并组合成完整的GstBuffer，提供下游元件处理，当管线在PAUSE或PLAYING状态下create函数会被反复调用。在create函数里，首先会从input stream里读取一个数据包头大小的数据，然后检查数据包是否合法，接着分析数据包头部信息创建一个特定大小的GstBuffer，这个GstBuffer用以存放将要接收到的所有数据，等数据都接收并存放到这个GstBuffer后，GstBuffer将会被加入到一个预先创建的GstAdapter中，最后检查GstAdapter中的数据是否完整，例如一个完整的视频帧，如果数据已经完整则把数据Push到source衬垫，否则进入下一次读取数据的流程。 读取数据的基本流程如下图： 图4-4接收数据流程图 4.1.2 udworksdemux 元件的实现 udworksdemux继承于GstElement，GstElement是所有Gstreamer 元件的父类，是最基本的元件。udworksdemux对udworkslive提供的数据动态地分为视频数据和音频数据，并动态地创建GstPad，通知下游的元件处理相应的数据。 4.2通用设备管理的实现 基于通用设备管理的基本设计思想，按产品计划的需求视频监控系统的客户端的第一个版本需要实现对DM365DVR-1系列中4路的产品提供支持。支持DM365DVR-1需要实现的类如下图： 图4-5 dm365Dvr类图 Dm365DvrPreview的中的dm365dvr_live_mixin类主要负责实现dm365dvr的live功能，其中dm365dvr_live_mixin_constructed构造函数主要负责构造live的视频回放管线。实现代码如下： static void dm365dvr_live_mixin_constructed(GObject *object) { Dm365dvrLiveMixinPrivate *priv = DM365DVR_LIVE_MIXIN_GET_PRIVATE(object); GstElement *source, *demux; priv->pipeline = gst_pipeline_new("root device nane"); // make #if 0 source = gst_element_factory_make("udworkslivesrc", NULL); g_assert(source != NULL); demux = gst_element_factory_make("udworksdemux", NULL); g_assert(demux != NULL); #else source = gst_element_factory_make("filesrc", NULL); g_assert(source != NULL); demux = gst_element_factory_make("ffdemux_mov_mp4_m4a_3gp_3g2_mj2", NULL); g_assert(demux != NULL); #endif // add gst_bin_add_many(GST_BIN(priv->pipeline), source, demux, NULL); // link if(!gst_element_link(source, demux)) g_error("Failed to link source and demux"); // ghost pad ?? // connect signal g_signal_connect(GST_ELEMENT(demux), "pad-added", G_CALLBACK(dm365dvr_live_mixin_pad_added), object); g_signal_connect(GST_ELEMENT(demux), "pad-removed", G_CALLBACK(dm365dvr_live_mixin_pad_removed), object); // keep in private priv->source = source; priv->demux = demux; } 首先要构造一个Gstreamer的pipeline： priv->pipeline = gst_pipeline_new("root device nane"); 再一次构造source, demux： source = gst_element_factory_make("filesrc", NULL); demux = gst_element_factory_make("ffdemux_mov_mp4_m4a_3gp_3g2_mj2", NULL); 然后把source，demux添加到pipeline中： gst_bin_add_many(GST_BIN(priv->pipeline), source, demux, NULL)； 接着要连接source和demux： if(!gst_element_link(source, demux)) 最后就是要把dm365dvr_live_mixin_pad_added回调函数连接到”pad-added”信号上去： g_signal_connect(GST_ELEMENT(demux), "pad-added", G_CALLBACK(dm365dvr_live_mixin_pad_added), object) dm365dvr_live_mixin_pad_added的主要作用是完成pipeline的后半部分的构建。当demux element接受到live elemnt处理过的网络数据后，如果是一个新的live流的的开始，demux element会发出”pad-added”信号。上面的g_signal_connect会使dm365dvr_live_mixin_pad_added捕捉到”pad-added”信号。信号的处理代码如下： static void dm365dvr_live_mixin_pad_added (GstElement *demux, GstPad *pad, Channel *chl) { GstElement *decode, *queue; g_print("Add demux pad: channel %i\n", chl->index); // new element decode = gst_element_factory_make("ffdec_h264", NULL); g_assert(decode != NULL); queue = gst_element_factory_make("queue", NULL); g_assert(queue != NULL); // add to bin gst_bin_add_many(GST_BIN(chl->dm365bin), decode, queue, chl->sink, NULL); // link gst_element_link_many(demux, decode, queue, chl->sink, NULL); // clutter g_signal_connect(G_OBJECT(chl->texture), "size-change", G_CALLBACK(size_change_cb), chl); clutter_container_add(CLUTTER_CONTAINER(stage), chl->texture, NULL); //clutter_actor_show(chl->texture); //clutter_actor_show_all(stage); if(gst_element_is_locked_state(demux)) g_print("demux is locked state\n"); // restate gst_element_set_state(GST_ELEMENT(chl->sink), GST_STATE_PLAYING); gst_element_set_state(GST_ELEMENT(queue), GST_STATE_PLAYING); gst_element_set_state(GST_ELEMENT(decode), GST_STATE_PLAYING); //gst_element_get_state(GST_ELEMENT(pipeline), NULL, NULL, GST_CLOCK_TIME_NONE); } 在上边的代码里先是构建decode 元件和sink 元件，然后要添加到上文创建的pipeline中。视频回放管线的后半部分的构建有两个关键点，首先就是要在demux 元件和deocde 元件之间加入queue 元件。Queue 元件的作用是创建一个队列缓冲和一个独立的线程，主要是为了避免多路回放时是因为时间差部分sink 元件把管线堵塞，而导致整个视频的回放管线死锁。加入queue 元件后，各路的decode和sink，与source和demux在分开的线程内运行，然后通过queue 元件内部的队列缓冲共享数据。另外一个关键点是要把queue ，decode和sink的状态单独提升到Playing，因为pipeline，source和demx的状态已经提升到了Playing, 而在新加入的元件的状态还在NULL，需要提升到Playing，但应为pipeline已经处在Playing的状态了，所以不能通过把pipeline的状态设置为Playing从而递归地提升所有元件的状态，所以要单独地提升新加入的元件的状态。 Pipeline的组成如下图： 图4-6视频回放管线组成图 5 结论 本文通过在HiRay公司基于TI DM365 SoC的视频监控系统的环境下，实现数字视频监控系统客户端的视频回放管线和通用设备管理的设计与实现。介绍了如何用GStreamer现有元件和自行设计元件配合组织视频回放管线，和基于面向对象的可扩展通用设备管理模块的设计与实现。 参考文献 [1]Richard John Boulto：《GStreamer Plugin Writer’s Guide》[EB/OL],gstreamer.org，第1-124页。 [2]Wim Taymans：《GStreamer Application Development Manual》[EB/OL]，gstreamer.org，第1-114页。 [3] Intel Corporation：《Clutter Reference Manual》[EB/OL]，clutter-project.org，第1-302页。 [4]Diomidis Spinellis & Georgios Gousios：《Beautiful Architecture》[M]，O’REILLY，第1-365页。 [5] Texas Instruments：《TMS320DM365 Digital Media System-on-Chip》[M]，Texas Instruments，第211页。 附 录 演示程序的源代码： /* * UDworks Plugins Test * Copyright (C) 2010 Zhibin Wu */ #include #include #include #include #include #include #define MAX_CHANNEL 8 // Channel typedef struct _Channel { int index; GstElement *source; GstElement *sink; GstElement *dm365bin; ClutterActor *texture; } Channel; // Application static GtkWidget *window; static GtkWidget *embed; static ClutterActor *stage; //static ClutterTimeline *timeline; static GstBus *bus; static GstElement *pipeline; static Channel *chl_array[MAX_CHANNEL]; void size_change_cb(ClutterTexture *texture, gint width, gint height, Channel *chl) { //ClutterActor *stage; gint row, col; gfloat pos_x, pos_y; gfloat space; gfloat stage_width, stage_height; //stage = clutter_actor_get_stage(CLUTTER_ACTOR(texture)); //if(stage = NULL