毕业设计（论文）-基于Apple-Darwin的摄像机客户端推送器的设计与实现.doc

华中农业大学楚天学院本科毕业论文（设计）目 录摘要I关键词IAbstractIKey wordsI1 系统的可行性研究概述11.1 系统研究的意义11.2 系统研究的目的11.3 国内外研究现状11.4 课题研究内容22 主要技术分析与简介22.1 DSS分析22.1.1 DSS概要及主体框架22.1.2 核心流媒体框架32.1.3 DSS服务器调用模块的主要流程42.2 开发平台的软件介绍42.3 TS流简介52.4 流媒体系统结构图52.5 H.264编解码规范62.6 Darwin支持的两种视频转发模式72.6.1 先拉后推72.6.2 先侦听后推送72.7 流媒体技术概述83 摄像机推送器的设计与实现83.1 摄像机主要模块83.2 摄像机各模块的设计与实现93.2.1 语音对讲模块的设计与实现93.2.2 参数配置模块的设计与实现103.2.3 报警模块的设计与实现113.2.4 实时数据流模块的设计与实现113.2.5 云台控制模块的设计与实现123.3 模块的加载过程133.3.1 采集模块143.3.2 推送模块143.4 推送模块的设计与实现细节153.5 RTSP请求的处理153.6 EasyPusher函数153.7 摄像机配置163.8 推送音视频数据的缓存设计174 系统测试184.1 测试方法184.2 TS推送测试184.3 摄像机功能测试205 总结22参考文献23致谢24 摘 要 本课题是基于苹果公司的Darwin Streaming Server，这是苹果公司的一个开源项目，对它做一些功能扩展，以满足系统的需求。首先我们对DSS的源代码进行了分析，然后着手将TS流推送模块添加到这个系统中。考虑到RTP/RTCP协议相比较与UDP协议对服务器的压力，最后决定使用UDP协议，并且系统支持了H.264 TS流。本课题最后测试的效果表现出画面清晰、无卡顿、无马赛克等优点，并且实现了对MPEG-2和H.264的支持。并且因为本课题严格的按照了TS流的理想码率进行推送，所以误差非常小，平均在5毫秒下，并且不会随系统工作时间增加而增长。而且，本课题设计的摄像机客户端推送器是彻底符合ISMA标准的，所以它也使用于所有基于IP网络的环境，接收终端可以是DVB、IP和PC。所以本系统对DSS进行扩展后，是具有多适应性的。关键词达尔文流媒体服务器；TS流；推送器；摄像机； AbstractThe project is based on Apples Darwin Streaming Server, which is an open source project of Apple. We will do some functional expansion to meet the needs of the system. First of all we have the DSS source code analysis, and then proceed to add TS stream Module to this system. Taking into account the pressure made by RTP / RTCP protocol and the UDP protocol, we finally decided to use the UDP protocol, and the system supports the H.264 TS stream.The results of the final test of this subject show the advantages of clear picture, no standstill, no mosaic and so on, and realize the support of MPEG-2 and H.264. Because the subject is push in accordance with the TS stream ideal rate, so the error is very small, with an average of 5 milliseconds, and will not increase with the system working hours. At the same time, the camera system design of the push function is fully in line with the ISMA standard, so it is also used in all IP-based network environment. Its receiving terminal can be DVB STB, IP STB and PC. So after the expansion of DSS, the system is more adaptable.Key wordsDarwin Streaming Server; TS Streaming; Pusher; Camera;241 系统的可行性研究概述1.1 系统研究的意义随着互联网越来越多的应用于现代人的生活当中，音视频通过网络传输的情况也越来越多，导致传输量也越来越大。现在很多的互联网公司都希望通过互联网流媒体技术推送给用户来获取更多的用户量。但是音视频数据的数据量是很大的，如果要下载下来会耗费很大的网络带宽和流量。目前网络带宽平均情况下还不算很大，在这种情况下，流媒体技术的出现就让这种情况有了很大的改善。现在网络的带宽虽然越来越大，但是对于日益增加的音视频传输量，显然还需要更为优秀的流媒体技术进行传输。由于流媒体技术为互联网传统的媒体播放上带来了更多的机会现在网络用户对媒体的需求越来越大，用户也更喜欢在网络上选择自己需要的音视频。过去，传统媒体更多的是使用“推”式传播，而流媒体技术将其变为“拉”式传播，而受众也不再是只被动的接收广播电视等节目，而是通过网络寻找自己需要的内容，随时随地的就可以播放。这将在一定程度上提高了用户的选择空间，使他们在各种媒体云集的今天占据着主动，也由于这种变化的产生导致媒体行业积极的改变来迎合用户的需求。本系统做的就是关于基于Apple Darwin流媒体服务器的一整套服务，而本课题负责的部分就是摄像机客户端推送器。1.2 系统研究的目的本课题是基于摄像机方案商提供的SDK基础上，在Windows平台上与摄像机的主服务进行交互，功能包括实时视频、语音对讲、云台控制等功能，摄像机客户端推送器一边通过SDK和摄像机的主进程进行交互（获取音视频数据，控制云台，联动报警等交互），一边和Darwin服务器、CMS服务器和RMS服务器进行对接，上传数据、接受指令的控制，形成一整套的音视频摄像机方案，为了能够适用于更多的不同的场景和设备，在本系统中添加了RTSPClient模块，可以设置为通过RTSP协议推送H.264视频流到流媒体服务器。整个系统可以应用于生活中的方方面面，包括了远程监控、视频直播、网上点播、远程教育等等。从现在互联网行业的趋势来看，音视频业务以及流媒体服务肯定会越来越重要。所以本课题的研究不管在生活中，还是在技术层面上，都是很有意义和价值的。1.3 国内外研究现状目前有一些厂商已经拥有基于IPQAM的VOD业务的解决方案，国内有SiHua和华为，国外有Motorola、挪威泰德、Cisco等。然而SiHua的产品即便不是基于ISA规范，但是那么昂贵的价格还是国内企业所不能接受的。Video Sever是VOD系统的核心部分，并且使用UDP协议传送TS流。为了降低系统的成本，首先应该考虑如何降低Video Sever的开发成本。因而，本文通过扩展DSS的功能，使其支持TS流推送功能，以满足一些小型运营商的需求。网络监控系统已经渗透到日常生活中的各个行业：在商场超市里，视频监控系统可以对顾客以及市场内实时场景进行监控。通信运营商可以利用网络监控系统对位置偏僻的通信基站进行监控。城市道路公交系统中，监控系统实时获取路况车流信息，便于交管部门交通流量调度。此类系统的最新应用模式是，幼儿园里面安装了这一类的系统以后，家长就能够对教师的教育情况和孩子的情况进行随时的了解。总的来说，在各行各业中网络监控系统都得到了非常广泛的应用。网络实时视频系统主要是使用网络来把不同地点的，甚至相隔了数千里的一些图像采集点和采集图像的播放终端之间形成一种互联的多对多关系，同时在这样的基础之上提供了一个开发平台，专门用于对视频音频扩展应用进行开发。而网络实时视频监控系统则属于一种全新的互联网应用型系统，这种系统融合了非常多的新型信息技术，包括了互联网传输应用技术、音视频数据采集和编解码、流媒体应用技术等等。网络实时视频监控系统的特点主要有三点，第一是网络监控，因为互联网络的连通性，系统监控硬件设备的布设不再受到彼此物理位置的局限。网络监控打破了原本监控系统对接入设备数量方面的限制和对距离方面的限制，对相关的网络资源进行了最大程度的利用。第二是数字化信息，目前音视频所采集得到的数据使用的是数字信号，目前已经出现了性能非常高的音视频编解码技术，因此对于数据的传输来说，其效率有了明显的提升，这一技术可以确保那些低带宽的播放终端同样能够得到非常好的采集图像。第三是支持无线网络，目前无线网技术发展的速度很快，而且无线网相关应用也得到了普及，新一代互联网的发展已经开始转向了移动互联网，这个时候，手机就变成了移动播放终端。这种移动播放终端的实时性非常好，同时能够支持流媒体视频数据，也就是说其图像播放效果可以和计算机相比，并且能够随时随地对监控区域所采集到的图像进行实时地获取。1.4 课题研究内容本课题并不是要做摄像机的硬件方案，或者说本课题是与硬件芯片无关的一套对于云平台对接方案，本系统在摄像机方案商提供的功能接口的基础上，通过摄像机提供的SDK，在摄像机ARM系统内部和摄像机的主服务进行交互，包括了摄像机提供的实时音视频、联动报警、云台控制等功能，Darwin开源流媒体解决方案整体采用的是行业通用的RTSP、RTP、RTCP、HTTP、RTMP、RESTful协议和标准，对于开发者和企业来说，通用性和可读性都极强。能够广泛的用于安防监控、智能家居、教育直播、幼儿园直播等项目，尤其是在安防行业结合移劢互联网方面，Darwin开源流媒体解决方案提供了非常完善的实现方案。我们在摄像机的内部植入程序，摄像机客户端推送器一边通过SDK和摄像机的主进程进行交互（获取音视频数据，控制云台，联动报警等交互），一边和Darwin服务器、CMS服务器和RMS服务器进行对接，上传数据、接受指令的控制，形成一整套的视频摄像机方案。2 主要技术分析与简介2.1 DSS分析2.1.1 DSS概要及主体框架Darwin Streaming Server是苹果公司的一个开源实时流媒体服务器程序。整个系统由C+开发，在设计上它遵循高效的性能、简单的设计、模块化开发等设计原则，要求程序做到高效的同时，可扩充性也要很好。并且DSS是一个开发源代码的流媒体服务器，可以在Windows，UNIX，MAC OS X，Linux，Free BSD，Solaris等操作系统上运行。DSS的核心服务器的部分是由一个父进程和一个子进程构成，这个子进程是由父进程fork构成的，该父进程就成为了整合的流媒体服务器。在运行时，主要由子进程完成，如果在子进程运行期间产生了错误就会退出该进程，并且fork出一个新的子进程。网络客户和服务器的对接是靠Darwin服务器来直接对接的。通过RTSP over RTP来发送或者接受请求。接收到请求后服务器就通过相应的模块来处理这个请求并且向客户端发送数据流。核心流媒体服务器是由四种不同类型的线程来处理事务的，每个线程的类型具体如下：服务器主线程，当服务器处理在关闭检查以及在检查之前需要记录相关状态打印和统计相关信息等任务时，就由这个线程来处理。事件线程，对接口以及和接口相关的事件都是由这个线程监听的，当有RTSP请求或者RPT数据包请求时，事件线程就会把这些任务就给任务线程来处理。任务线程，任务线程在事件线程处理事务时会把事件从事件线程中取出来，并把事件传递到需要处理的相应的服务器模块进行处理，在一般情况下，每一个处理器核都会有一个任务线程由核心服务器创建。空闲任务线程，空闲任务线程，该线程负责对一个周期的任务队列进行管理，主要有两种任务管理，超时任务和Socket任务。如图2-1服务器架构所示。 图2-1 服务器架构2.1.2 核心流媒体框架如图2-2核心流媒体框架，首先由客户端发起视频请求到接入服务器，服务器处理完毕请求之后发送将请求发送到前端设备，前端设备收到请求后进行响应，接入服务器收到设备响应后向分发服务器发送视频通知，同时前端设备向分发服务器发送数据流推送请求，分发服务器收到前端请求后给前端设备与接入服务器响应，前端设备收到分发服务器的响应后向分发服务器推送RTP数据流，同时接入服务器收到分发服务器的响应后给客户端发送响应信息并进行重定向操作。分发服务器向客户端发送RTSP视频请求，客户端响应RTSP视频请求，分发服务器向客户端推送实时视频流。图2-2 DSS核心流媒体框架2.1.3 DSS服务器调用模块的主要流程在DSS中的模块分为两种，一种是动态模块，一种是静态模块。动态模块在服务器启动伊始就会加载，而静态模块在这之后才会加载。所以建议将写好的功能模块全部编译为动态模块来替换以及扩展DSS原有的服务器模块，那么我们自己的功能模块就会首先被加载。Register是每个模块中必须支持的一个角色，服务器会在每个模块被装载后，就调用这些模块的Register角色。Register角色的主要工作就是初始化，例如对数据结构的初始化和内存分配的初始化等。它会调用QTSS Add Role来记录这个模块支持的其他角色，之后服务器就会初始化角色并且调用每个拥有这个角色的模块。在关闭服务器时，Shutdown角色就会被各个模块调用，然后这些模块就会释放内存完成结束工作的处理。通过这些角色流媒体服务器就可以完成它的任务了。图2-3服务器启动和关闭的流程显示的是服务器在启动和关闭的时候如何和Register（登记），Initialize（初始化），和Shutdown（关闭）这些角色协同工作的。图2-3 服务器启动和关闭流程2.2 开发平台的软件介绍DSS是支持多个操作系统的。其中包括Windows，而且Darwin流媒体服务器源代码完全采用标准的C+语言写成，所以本课题采用的开发平台软件是在Windows平台上的Microsoft Visual Studio 2015。Visual Studio是一套基于组件的软件开发工具和其他技术，可用于构建功能强大、性能出众的应用程序。并且它继承了对构建跨设备应用的支持，以及用于跨平台开发的功能。所以本课题使用它作为开发工具是十分合适的。由于Darwin采用标准C+语言来完成，所以它的编程风格是十分优秀的，它的每以个C+类都对应一对和类同名的.h和.cpp文件。但是也因为它大量的采用了面向对象的概念，其中继承，多态等，因此它的代码复杂性还是很高的。图2-4就是开发环境界面。图2-4 开发环境界面2.3 TS流简介TS一般我们认为是MPEG-2 TS标准，它是一种非常成熟的数据传输技术，它是对音视频数据复用的一种说明，音视频数据经过TS封装之后，再通过网络IP协议栈进行二次封装，然后就可以传输了。但如果需要进行一些互动性的内容，就需要对它进行扩展。这种传输方式同样采用了C/S的方式，另外由于应用在IPTV领域，控制层可以使用RTSP协议或者HTTP协议。在DSS服务器中，为了减少网络抖动更好地控制传输流量，我们对UDP协议数据包又增加了关于RTP协议数据封装。这样系统就能够有效的减少网络丢包，视频卡顿等影响客户体验的现象。TS over IP的传输过程如图2-5所示。图2-5 TS over IP的传输过程2.4 流媒体系统结构图Darwin开源流媒体解决方案可分为流媒体数据流、信令控制流两大部分，接入管理接口服务器CMS、流媒体服务器Darwin、存储不回放服务器RMS可直接运行在阿里云主机ECS上，CMS服务器负责进行设备和客户端的接入不管理，Darwin服务器负责进行流媒体音视频的分发和HLS切片，RMS服务器负责对直播流进行实时存储和录像检索，还有其他功能模块。CMS服务器设备管理与接入服务器，Darwin流媒体服务器，RMS录像存储服务器，都能够分布式、平行部署、无限扩容，云端各个节点的服务单元都将负载信息写到共享的Redis中进行数据共享，CMS将在线设备相关信息写入到Redis，Darwin服务器将负载信息和流媒体直播相关信息写入Redis，这样在多个CMS服务器、Darwin服务器之间就可以进行直播级联，Session共享，Token验证等功能。本课题负责的Camera摄像机硬件启动后，启动Camera进程。Camera向CMS服务器发送注册报文，并定期发送报活报文，维持摄像机与CMS服务器的TCP连接。CMS服务器会对Camera发送注册报文进行权限验证，通过验证后的设备信息写入Redis中，也会将CMS服务器的信息一起写入。Client向CMS服务器请求直播视频流，CMS服务器会在Redis中查找设备是否在线，第二步会查找该设备是否存在流媒体转发消息。如果存在，则直接将改直播流信息响应给Client，如果不存在，CMS服务器需要向Camera发送启动直播流推送的命令，CMS服务器再将Camera反馈的结果响应给Client，Client根据收到的结果进行播放。如图2-6流媒体系统结构图。图2-6 流媒体系统结构图2.5 H.264编解码规范正是由于标准化的视频压缩技术的出现使得图像技术得到了更为广泛的应用，例如DVD视频和数字电视彻底改变了家庭娱乐以及广播电视的传统模式。图像视频在互联网中的应用与MPEG标准中的MPEG-4有密不可分的联系，ITU-T H.263标准是当前大多数视频会议使用的视频压缩标准。MPEG-4视觉标准和H.263标准是在1995年开始制定的，视频编码以及视频压缩技术是这两种标准建立的技术基础，对此类标准进行负责的是电影专家集团以及视频编码专家组。在这两种标准的开发进行到后期的时候，出现了一套更加优秀的新的标准，也就是H.264高级视频编码标准，这套标准所提供的图像视频压缩效果更加优秀，同时其在保证比特率非常低的同时还保证了高品质。H.264编解码协议规范可以用四个方面概括其技术特点，第一个方面是关注实用性问题，摒弃了原本这类编解码技术里面的一些存在着缺陷的编码方案，如机遇内容的编码等，以更加简洁的格式，以提升编码效率为目的，从而运用合适的技术。第二方面则是使用了多种的新算法和新技术，在混合编码的基础上，新增了4*4整数变换技术、基于内容的变长编码技术及多帧预测和帧内预测技术等。第三方面，对于算法而言，突出了信道的特点。从分层的角度来看，信道编码和信源编码在形式上采取了分离。第四方面则是使用了针对IP以及无线网络的相关策略，为了方便那些经过压缩之后的视频在丢包率较高和误码率较高的网络环境之中进行传输，使用了一些用来对差错进行消除的工具。所具有的主要优点如下：图像质量非常高。H.264标准想要实现的是在对图像进行还原的过程之中能够保持较高质量，同时还为此采用了一系列的算法，其目的为实现图像的高质量；为了能够和不同的信道相适应，以及各种应用形式，区分各种图像层次从而采用相应的算法；在熵编码等步骤中，为达到较低比特率的目标从而采用节约码流的算法；系统的健壮性增加，H.264提供了掩盖错误的组件并应用了环路滤波结构。2.6 Darwin支持的两种视频转发模式Darwin支持两种自动播送的场景：先拉后推。为了发起自动播送，RTSP客户会发送标准的RTSP请求来向服务器请求一个流，然后服务器将该流中继到一个或者多个流媒体服务器。这种场景在“先拉后推”部分中加以描述。先侦听后推送。在这个场景中，自动播送在流媒体服务器接收到ANNOUNCE请求时被发起。这个场景在“先侦听后推送”部分中进行描述。2.6.1 先拉后推用户可以通过发送标准的DESCRIBE/SETUP/PLAY请求来向远程的源中请求一个流，然后将它中继转发到一个或者多个目的地。当只希望让外部流的一份拷贝占用其内部连接的带宽时，这个功能可能有用。中继转发获取一份拷贝进行多份的复制和转发、分发到请求的客户端。图2-7提供了一个先拉后推（pull-then-push）场景的实例。图2-7 先拉后推场景实例流媒体服务器A（转发服务器）发送标准的RTSP客户DESCRIBE/SETUP/PLAY请求给远程服务器，即流媒体服务器B。发起请求的中继“客户端”（流媒体服务器A）开始接受流，然后向该输入流的中继配置中列出的所有目的地发送ANNOUNCE推送请求。2.6.2 先侦听后推送流媒体服务器可以被配置为将ANNOUNCE请求创建的输入流自动发送到一个或者多个目的地。这可能可以用于配制自动播送网络。图2-8提供了一个先侦听后推送的场景的实例。图2-8 先侦听后推送场景实例先侦听后推送场景的步骤如下：远程机器（IpCamera等前端设备或者中继服务器）向流媒体服务器A发送一个ANNOUNCE请求。流媒体服务器可以接受或者否认这个请求。如果它接受了请求，则流媒体服务器会检查其中继配置，以确定这个流是否应该被中继。如果该流应该被中继，则流媒体服务器将向自身发送标准的RTSP客户DESCRIBE/SETUP/PLAY请求。发出请求的中继“客户”（流媒体服务器A）开始接收流，然后向相应的输入流的中继配置中列出的所有目的地发送一个ANNOUCE请求。2.7 流媒体技术概述随着互联网越来越多的应用于现代人的生活当中，现在很多的互联网公司都希望通过互联网流媒体技术推送给用户来获取更多的用户量。但是音视频数据的数据量是很大的，如果要下载下来会耗费很大的网络带宽和流量。目前网络带宽平均情况下还不算很大，在这种情况下，流媒体技术的出现就让这种情况有了很大的改善。让网络客户通过互联网收看互联网节目能够更加的方便。流媒体技术的成熟，让PC可以在接收数据的同时马上进行数据解码，而不需要整个音视频文件全部下载，所以客户只需要等待数据初始化完成就可以在线观看了。当音视频这些数据通过互联网流媒体服务器在PC上播放的同时，数据的剩余部分还会同时继续在服务器上下载。在互联网上传输音视频数据就好像在日常生活中从水龙头接水一样，以前旧的互联网传输模式必须要等所有的数据下载完成，就像必须等水装满才能使用，而水流的大小直接影响着接满水所需要的时间。现在流媒体传输方式的出现和完善，包括互联网带宽越来越大，让用户能够在收看的同时也能够继续下载未观看的部分。目前，流媒体传输技术大致上可以分为两类，一种是流实时传输，另一种是流式的顺序传输。顺序传输就是说按照数据的顺序进行下载，所以用户可以边下边看，但是服务器的数据推送和用户对数据的接收不是同时的，而是服务器将数据推送后，用户经过一定的网络延时才能接收到并且使用。所以这种传输方式用户看到的视频并不是实时的而是之前一段时间推送的，中间存在一定时间间隔。在这种情况下用户只能观看已经下好的数据而不能跳跃时间看文件后面的节目。因此对画面质量要求高的传输可以采用这种模式，但是流式传输可以保证比较好的传输质量。显而易见，流式传输更适合在网络上用于点播或者直播音视频节目。相反的实时流式传输这种传输模式，音视频信息可以通过网络进行实时的使用和播放。在播放数据过程中可以对观看进度进行对节目的实时控制比如快进或者拖放，然而使用这种模式进行传输不能很好的保证接受质量，会发生数据丢包等情况影响收看质量。3 摄像机推送器的设计与实现3.1 摄像机主要模块摄像机主要有连接网络，与摄像机进行通讯、获取码流、设置参数、语音对讲、录像等功能。按照实现的功能可以分为五个模块，实现每个模块的功能时首先要初始化摄像机网络库然后进行用户注册，在结束功能时就需要注销设备和释放网络库，这四个流程是每个模块必不可少的。摄像机在开机时会向本系统的中心管理服务器发送注册请求，这个注册请求是定时的，在发送时还会携带快照，保证连接保活。中心管理服务器会记录所以在线的Camera信息。摄像机连接服务器时，首先需要对摄像机网络库进行初始化，设置定期连接时间和超时连接时间。用户注册设备需要调用HI_NET_DEV_Login接口，在注册成功后，会返回一个Session id作为其他操作的唯一标识。设备在接入到服务器后，会与接入服务器建立一个交互的会话，以TCP方式进行连接并发送保活包，在原有DSS的RTSPSession基础上进行改造，修改为属于自定义协议的交互流程，底层的网络读取与发送结构完全一致，只需要修改上层对收到的报文的处理，那么对于多路会话的维护也可以直接用原来对RTPSession列表的维护方式，如前端设备的ID、IP等。自定义协议部分参考DSS对RTSP的处理，修改为自己的协议处理（文本协议、字节流协议）就可以完成基本的设计。如图3-1是摄像机对主要模块的实现流程。图3-1 摄像机主要模块实现流程3.2 摄像机各模块的设计与实现3.2.1 语音对讲模块的设计与实现首先客户端使用POST在body中携带协议报文向云平台发送开始对讲命令，云平台组织协议报文向指定的设备发送。如图3-2语音对讲实现的流程图。设备执行开始对讲命令后向云平台返回相应报文，云平台将响应报文返回给客户端，客户端请求开始对讲成功后，开始向云平台发送采集的音频数据，云平台将音频数据转发给设备，设备将音频数据播放出来。转发语音数据首先调用netDevStartStream()，开启摄像头流转发。在该函数中调用摄像头的请求流转发数据的API，并且设置回调函数myStreamProc来接收数据，具体的流转发在EasyCameraSource:PushFrame函数中实现转发。PushFrame函数被摄像头回调函数直接调用，首先调用GetH246FromPS（frame, len, &h264Buf, h264Len, isVideo, isAudio）。从摄像头的H.264编码的PS流中解析得到H.264标准流，标准流中包含视频帧、语音帧（摄像头内设置为复合流才能获取到）和H.264的其他帧。相关接口有：启动语音对讲HI_NET_DEV_StartVoice、停止语音HI_NET_DEV_StopVoice、转发数据HI_NET_DEV_SendVoiceData。图3-2 语音对讲模块的实现流程图3.2.2 参数配置模块的设计与实现实现参数配置必须初始化网络库和用户注册这两个步骤。如图3-3参数配置模块的实现流程。图3-3 参数配置模块的实现流程在摄像机连接到服务器之前，就应先在Camera服务中获取到摄像机的具体参数，才能够继续进行其他服务。，将用户注册接口返回的句柄作为配置接口的首个参数。相关接口有：设置摄像机参数HI_NET_DEV_SetConfig、摄像机翻转HI_NET_DEV_CMD_DISPLAY_EXT。3.2.3 报警模块的设计与实现报警回调可分为“移动报警”和“输入报警”两种数据。移动报警，当检测到镜头相应区域有移动，回调函数将移动区域的相关数据输出。输入报警，摄像机参数有数据变更时有输入报警信息。联动报警在初始化网络库和注册设备后就可以使用，相对来说比较的简单，首先根据客户端调用的命令，调用摄像头相关的SDK函数就可以了。从摄像机上发现画面上有移动的物体，首先摄像机向CMS服务器发送一个请求，报告有移动的信息。CMS回复MSG_SC_BG_ACK给Client后，会将报警信息发给客户端，客户端拿到报警信息后，再根据自己的实现的功能推送给用户。如图3-4摄像机报警模块的具体流程。相关接口有：报警信息回调HI_NET_DEV_SetDataCallBack、启动实时数据HI_NET_DEV_StartStream。图3-4 报警模块的实现流程3.2.4 实时数据流模块的设计与实现实时数据流启动后通过回调函数获取摄像机的当前实时数据。获取到的摄像机视频画面每一帧数据都是完整的数据帧，数据帧包含帧头用于区分数据的类型，以及后面的视频数据。具体的实时数据流实现首先需要调用CameraLogin()，之后需要获取到连接摄像头的具体配置信息。然后注册流推送事件的回调，根据接收到的命令生成流信息。最后调用netDevStartStream()来开启摄像头的流转发。如图3-5实时数据流的实现流程。图3-5 实时数据流模块的实现流程相关的接口有：启动实时数据HI_NET_DEV_StartStream 、关闭实时数据HI_NET_DEV_StopStream 、实时数据回调HI_NET_DEV_SetStreamCallBack。3.2.5 云台控制模块的设计与实现首先根据客户端调用的命令，调用摄像头相关的SDK函数就可以了。从客户端上云台控制Camera，首先Client通过RESTful接口向CMS服务器发送一个请求，内容包括设备序列号、动作等。CMS组织控制控制命令报文回复Client之后，会将请求内容发送给对应的Camera进行控制，在EasyPlayerActivity.java中增加4个按键，分别为上下左右，并增加OnTouchListener接口，当按键按下时持续转动，释放按键时停止转动。Camera在执行云平台发送的控制的报文之后向Client返回控制的结果。云台控制包括上下左右，方向停止，聚焦等扩展功能。云台控制在实际生活和工作中的用途是非常大的，例如监控报警和实时移动检测，都需要用到摄像头的转动来实现更大角度的监控。所以这个模块的实现是十分有用的。如图3-6云台模块的实现流程。相关接口有：开始云台控制操作HI_NET_DEV_PTZ_Ctrl_Standard、云台上仰HI_NET_DEV_PTZ_UP、停止云台控制HI_NET_DEV_PTZ_STOP等。图3-6 云台模块的实现流程3.3 模块的加载过程每一个模块必须实现两个线程，一个是Main函数，在DSS服务器开始启动的时候就调用这个函数，对所在开发的模块库进行初始化。一个是Dispatch函数，也就是分发函数，服务器在做某种特定的目的时需要调用这个函数。对一个编写好的模块，在服务器启动的时候就应该自动的加载这个模块。对于DSS模块加载的整个过程，首先我们应知道在DSS中模块实际上就是类，我们完成的功能实际是通过这些类的方法来实现的。界面调用函数主要介绍了Client数据获取来源，主要通过采集数据，得到数据后停止采集，进行推流，流推送完毕之后停止推流，得到输出的流进行开始播放和播放完毕的停止播放为一个主流程。首先开始捕获（采集），传递采集参数SOURCE_TYPE（资源类型）、nCamId（摄像机ID）、nAudioId（音频ID）、hCapWnd（云平台对象）、szURL（云平台地址）、nVideoWidth（视频宽度）、nVideoHeight（视频高度）、nFps（文件）、nBitRate（字节频率）。传递参数后调用接口。再调用停止采集函数，停止采集。接下来进行视频播放的第二步开始推流。调用推流函数传递推流参数ServerIp（服务器ip）、nPushPort（推流端口）、sPushName（推流名称）、nPushBufSize（推流大小）。推流完成后调用停止推流函数，进行视频播放的第三步播放。首先流已经得到解析流并进行播放调用播放函数、传递播放函数参数szURL（播放停止）、HWND（播放流）。当播放完毕后调用停止播放函数，停止播放。如图3-7为界面回调的主要流程。图3-7 界面回调函数流程图3.3.1 采集模块采集分为本地音视频采集和RTSP流采集。本地音视频主要通过DShow进行采集，函数如下：int CSourceManager:StartDSCapture（int nCamId, int nAudioId,HWNDhShowWnd,int nVideoWidth, int nVideoHeight, int nFps, int nBitRate）该函数主要实现本地音视频采集和音视频编码器的初始化，需要注意的是这里的参数设置：1）本地采集的视频宽高和x264编码器的宽高需一致，数据格式建议设为YUY2（程序中默认为“YUY2”），因为在DShow的数据采集线程中需要进行编码前的格式转换（YUY2-I420），如果格式不统一，这里将要重写转换函数。2）本地音频采样率默认为16000，这个设置在Pusher中表现最佳，其他采样率还有待测试。3）其他设置请参照DEVICE_CONFIG_INFO结构和Encoder_Config_Info结构的详细说明。而RTSP流采集和流播放采用的是同一个类ClassPlayerManager实现，主要实现方法为：接收网络RTSP流进行推流EasyPlayerManager m_netStreamCapture;接收Darwin推出的RTSP流进行播放m_netStreamPlayer。这个类封装了libEasyPlayer库提供的接口，方便调用；这个库集成在EasyClient源码中，也是EasyPlayer的核心；她主要实现了从网络接收RTSP流进行解析，获取H264编码数据和AAC编码数据分别进行解码并呈现和播放。当然，作为Capturer而言，我们只需要用它获取到编码数据即可。3.3.2 推送模块首先开始推流，调用推流函数传递推流需要的参数ServerIp（服务器IP）、nPushPort，（服务器端口）、sPushName（推送流名称）、nPushBufSize（推送流大小）。创建推送器指针，指针先实例化对象，设置推送流编码格式、设置推送回调，可以获取推送器反馈的信息，最后开启流推送调用流回调方法。这个时候回调方法开始生效回传推送器反馈信息，当反馈信息大于等于0时说明流推送完毕，如果反馈失败停止推流。停止推流之后关闭流接口，释放流，将流信息置空保证下次推送可以继续。唯一需要注意的是推送标志m_bPushing，这个标志将在数据回调函数中起到真正的推送开关的作用（严格的说在StartPush中也应该调用m_bPushing判断是否推送已经进行）。3.4 推送模块的设计与实现细节模块的主程序就是在收到RTSP命令之后模块执行的总程序。分别是对文件的解析，文件读写等各个功能的调用。因为流推送模块首先需要获得数据才能推送，所以文件的读写性能也十分重要，这样才不会因为数据读写对推送数据造成不必要的影响。因此我们使用了双队列缓存，使文件从读取到发送是一个平滑的过程，所以可以让数据发送的数率能够稳定发送。双队列缓存的使用大大提高了读取数据的平滑性，在客户端播放的时候能够明显的减少因发送导致的画面不流畅。Darwin服务器在接收到Camera直播推送后，将该设备的直播流信息写入到Redis中，这样就方便CMS服务器直接对设备直播流信息进行检索。Darwin服务器会定期检查设备直播流的客户端数量检查，当设备的Output数量由0减为0，或者在Darwin服务器内部巡检中发现规定事件内没有客户端请求，Darwin服务器会向CMS服务器发送设备直播流释放请求，CMS服务器再通过信令发送给Camera，停止Camera向Darwin服务器推送直播流。3.5 RTSP请求的处理当接收到用户端的RTSP请求，DSS服务器就会解析请求，在RTSPSession:Run函数中根据RTSP请求内容的不同，将其分派给相应的模块来处理，而这个Module会根据RTSP请求内容，对用户端做出对应的处理。RTSP支持的操作是客户端可以请求通过HTTP展示说明。含多播的地址和端口，如果演示文稿正在多播，和包含目的地提供的客户端，如果演示文稿是单播。媒体服务器可以加入到现有的会议服务器和客户端之间的对话。由上述的分析可知，当接收到DSS服务器分派来的任务，QTSSTSModule模块也未必一定会处理这个请求。QTSSTSModule首先会解析用户的RTSP请求，根据内容判断用户请求播放的文件是不是TS格式，再检查服务器目录中是否存在这个文件，再决定是否继续预处理请求。模块与用户之间有一个交互过程，首先客户端向DSS服务器询问有哪些方法可用，服务器回复诸如DESCRIBE，SETUP，TEARDOWN，PLAY等；其次客户端请求DSS服务器提供的媒体描述信息，比如编码格式、播放时长、传输协议等等，Server以SDP形式回复；客户端请求服务器建立会话，服务器建立会话，返回会话相关信息。最后，客户端请求播放节目，服务器应答并且向其发送数据流。3.6 EasyPusher函数EasyPusher是一个推送RTSP流媒体音/视频流给RTSP流媒体服务器的标准RTSP/RTP协议推送库，通过EasyPusher就可以避免接触到稍显复杂的RTSP（ANNOUNCE、SETUP、PLAY）/RTP/RTCP推送流程，只需要调用EasyPusher的几个API接口，就能轻松、稳定地把流媒体音视频数据推送给RTSP服务器（Darwin Streaming Server）进行转发和分发，EasyPusher经过长时间的用户检验测试，稳定性非常高。具体的调用过程首先在Callback函数中可以获取到H.264视频流和音频流。调用下图3-8EasyPusher基本调用流程中的EasyPusher_PushFrame接口，将音视频流推送到Darwin等RTSP服务器。图3-8 EasyPusher基本调用流程通过这种方式就可以将实时通话的过程通过RTSP、RTP的形式推送给第三方流媒体服务器做视频通话监视，第三方录像，级联等等功能。3.7 摄像机配置本系统选择的摄像机是海康萤石云基于海思HI3518C方案摄像头，该摄像头可以水平、垂直双方向转动，具有360度的视野控制，具有720P的高清分辨率。下面是摄像头的配置流程：（1）连接网络将摄像机通过有线的方式连接到摄像机，路由器需要开启DHCP功能，给摄像机分配到IP地址（如果路由器没有开启DHCP功能，摄像机连接网线后，摄像机的默认IP就是8）。（2）查找摄像机打开HiCamSearcher.exe，搜索摄像机，如图3-9查找到摄像机的具体IP地址后就可以进行下一步的操作。图3-9 找到摄像机分配的网络地址（3）进入摄像机的Web管理通过获取的摄像机IP地址登陆摄像机的Web管理界面，默认用户名：admin，默认密码：admin；如图3-10摄像机管理界面。图3-10 摄像机web管理界面（4）区分摄像机硬件方案进入设备信息页面，找到“软件版本”或者“固件版本”项，如果版本号以V6打头，那么摄像机是海思HI3518C方案。如果版本号以V7打头，那么摄像机就是海思HI3518E方案。如图3-11设置摄像机的具体参数。图3-11 设置摄像机具体参数3.8 推送音视频数据的缓存设计Camera在向Darwin云平台推送音视频数据时，有时一个I帧会很大，从摄像机SDK中获取的数据就会被拆分。我们使用Pusher向云平台推送时需要每次发送一整帧数据，这时我们就需要设计一个缓存机制将SDK拆分的帧组成一个完整的帧数据，再使用Pusher推送给Darwin云平台。如图3-12这里我们可以看到图片的第三行到第十行是一帧数据。由于数据过大，SDK将其拆分为8个包。我们就需要将这8个数据包组合正一个完整的关键帧推送给云平台。图3-12 摄像机SDK获取的帧数据具体的设计思路我们建立一个固定大小的缓存区buffer，和一个用于标记偏移的pos并初始化为0；当我们获取第一个数据包的时候我们判断数据包是否为0x00、0x00、0x00、0x01开头，则表示这是一个I帧或P帧，判断pos是否为0，若为0，则将数据放入buffer。若不是，说明buffer中已经存在一个完整的I帧或者P帧数据，则发送。若获取到的数据开头不为0x00、0x00、0x00、0x01，则判断pos是否为0，若是，则丢弃，若不是，则说明这个数据为拆分的数据，需要加入buffer。4 系统测试4.1 测试方法本次测试使用的方法是黑盒测试方法，这是一种通用的软件测试方法，它直接通过测试软件或系统设计的功能是否能够正常使用来作为测试准则。在黑盒测试的过程中，我们把要测试的功能当做一个不能打开的黑盒子，不需要考虑其内部的结构和特效，直接调用程序的接口测试，功能能否达到系统设计需要的要求。这是一种十分简便而且高效的测试方法。4.2 TS推送测试本系统同时支持MPEG-2 TS流和H.264 TS流，所以现在对两种流分别进行测试，我们找到了两种不同流的文件共十五个，对其进行了推送的测试。首先我们进行对MPEG-2 TS流的测试，我们共做了十次不同文件的测试，测试过程中视频的播放十分流程清晰，没有视频中断卡顿，或者马赛克和延时的现象。表4-1 推送MPEG-2 TS流测试前置条件：Darwin服务器配置成功和摄像机推送模块开启测试方法：黑盒测试。输入数据：共10组MPEG-2数据。执行步骤：开启摄像机推送服务。预期输出：数据推送成功，误差符合要求。实际