【Stones from other hills】手机视频监控系统小结 收藏

【Stones from other hills】手机视频监控系统小结 收藏

 近2个月来忙于开发Windows Mobile手机上的视频监控系统,先上开发成果如下图(图1为取前端DVR实时子码流视频,图2为录像文件回放);手机视频监控系统主要涉及5大方面,分别为最核心的视频编解码,网络传输,UI设计,服务端(手机流媒体)以及与其它系统的结合.在手机上浏览实时视频图像画面一般过程是手机客户端发起一个视频预览请求到手机流媒体,告知流媒体当前客户端想浏览那一路视频,流媒体服务器去连接前端远程的DVR/DVS取其子码流数据,转发传输QCIF画面质量的视频数据到手机上,客户端软件调用解码库对接收到视频数据解码,最终通过DirectShow绘制到界面上显示.

 

视频编解码
   要考虑到采用什么类型编码的视频流是H.264或MPEG4,还是其它格式的视频数据,一般视频监控设备传输的是采用具有高压缩比的H.264数据.确定了视频数据编码类型就好办了,那就去找其相应的编解码库,一般移植开源的ffmpeg到WM上进行优化(已经有人做了,大家可以直接Google一下找到相应的源代码),移植其mpeg4 sp/h.264解码器，在没有任何优化的情况下可支持32K,CIF,5-10fps的效果，对于一般的流媒体应用足够了。以后还要经过算法和汇编优化。解码后还需要经过yuv2rgb和scale，需要注意的是ffmpeg的解码有消隐区的说法，即QCIF的图像其linesize不是176而是192，如果你发现解码后图像呈绿色，需用img_convert()转一下(目的格式也是PIX_FMT_YUV420P)。Symbian上用DSA直接写屏就行。Wndows Mobile上可以用sdl.音频解码主要包括AAC,AMRNB,AMRWB。AAC和AMRNB是gprs和edge带宽支持的音频（aac效果比amrnb好),AMRWB是3G后的音频格式。在ffmpeg 0.5 release中已经支持amrnb/wb的fixed point解码，很强大。或者从TCPMP播放器里面提取相应代码,TCPMP有N多种可用的编解码，其中就有H.264的,解码效率听说不错,可借鉴。

网络传输
  视频数据是采用TCP还是UDP呢,是自定义通信报文还是采用RTSP/RTP/RTCP这类通信协议加以封装.

  流媒体网络传输要满足高带宽，低传输延迟，支持组播模式，基于差错恢复的可靠保证和通道同步（尤其是视频和音频流的同步）。RTP/RTCP是一种基于组播的应用层协议，也是流媒体传输使用最广泛的协议。

  实时传输协议RTP（Realtime Transport Protocol）在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM协议上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

  实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。

  RTSP则是当前流媒体传输的主流标准，连微软都抛弃了MMS而转而支持RTSP， RTSP可以支持客户端暂停回放停止等操作，基本不用考虑音视频同步问题（因为音频视频分别从不同RTP PORT读入缓冲）。值得说明的是，RTSP成功后，就开始RTP传输，分为RTP OVER TCP和RTP OVER UDP，前者保证每个数据包都能收到，如果没收到就重传，而且不用考虑防火墙NAT；后者只保证尽最大努力的传输，不会重传丢帧，实时性好，要解决防火墙和NAT问题,因为世界上60%的GSM运营商是这样做的,使流媒体服务器根本不能连接到手机。如果对帧率要求比较高的手机电视，推荐采用UDP传输，因为延迟较大的重传数据对用户是没有意义的，宁可丢弃。如果你决定使用RTP/PTSP,网络部分可以采用强大的开源库live555来实现RTSP/RTP协议，其性能稳定而且支持大多数音视频格式的传输。(当然ffmpeg也实现了网络传输部分,经过改动后也能用）对live555经过裁剪后可移植到symbian和windows mobile上.

  现在手机上网,其网络传输速率一般不成问题,2.75G EDGE网络有高速度（最多236 kbps，对QCIF视频画面质量传输来说足够了）和低能耗，据我了解与GPRS相近。当前的3G模块比较耗电.未来随着3G的推广,以及有消息称中国移动TD-LTE(4G)2010年会进入商用,下载一部164兆的电影，仅花了不到2分钟，而通常300兆的电影，则只要3到5分钟就能下载完毕。对此，业内人士介绍，4G可以达到百兆以上的速率，对于3G来说又是一个质的飞跃。如果说3G是国道，4G就是高速公路。而对于4G与2G、3G之间最大的不同，技术人员介绍，除了速度比他们快之外，视频监控、视频通话效果也将更加流畅、高清。在网上看高清视频，不用担心画面卡或声像不同步……与3G相比，4G带宽可达到170M以上，其下载速度比3G快80倍。

UI

  用户对手机软件的界面是很在意的，做的好看了他会觉得有技术含量，做的好用了他会更加喜欢我们的产品。所以一套好的UI是必不可少的。手机软件开发的大部分工程是在做UI系统。一套好的自主的手机软件UI系统是产品核心竞争力的一部分。在Windows Mobile的界面开发,使用C + SDK做漂亮的界面不容易,一旦在界面上控件比较多，控件的布局更是头痛。 横竖屏切换的时候也得考虑，不同手机屏幕尺寸可能也不一样;不同的字体下,界面差异也非常大……
  其实要做出好的界面最后还是要回归RECT，也就是自己绘制贴图。 如果要做的很漂亮，那还是自己封装一套界面控件，这样控制起来方便。 横竖屏问题，你绘制的时候不应该写死的位置坐标，应该取相对坐标。 在横竖屏切换的时候会触发WM_SIZE等一些消息，里面改变相对坐标的横竖屏大小就OK啦. 做界面推荐一个MFC的扩展，Xtreme ToolkitPro，里面有大量的类，可以参考他们的类来写写自己的控件.这就是现状，没办法，刚开始的时候会比较艰难。 积累以后有自己的一套控件库，开发速度会提高.

  开发应用每种方式都各有其优势, 没有最好，只有更适合。看具体应用, 选择最适合自己的技术，自己熟悉的技术。
Win32 开发的效率相对较低，但是灵活性较高。
WTL 对它不了解，不加评论，但似乎它的资料相对较少。
MFC 开发效率不错，但编译后的程序体积较大。对了，它的资料也非常丰富。
还要提一下C#，感觉.Net Compact Framework的封装会越来越完善，技术的趋势将向此发展，能给开发效率带来极大提升。

服务端

  作为服务端的手机流媒体要从安全性,稳定性,并发性等各性能指标综合考量,为客户端提供良好的视频服务访问;它主要具有以下几个功能:
 
1.其中一个基本功能就是鉴权,验证登录请求过来的客户端具有那些权限,可以浏览那路视频,可不可以进行云台控制,点播回放那些文件等

2.核心功能是对资源进行有效地管理,如视频源,当前登录用户等;要做到下面几点

1)对DVR/DVS登录用户能够复用,如果同时有多人浏览一台监控设备的视频,登录到该设备的用户只有1个;如果每一个客户端都独自使用不同的用户登录到DVR上,有可能会造成DVR忙,资源占尽,无法响应;

2)对于多个客户端浏览同一路视频,只需向DVR请求一次数据,然后由服务器把视频数据一一转发给连接该路视频的客户端;

3)能够对每一路正在浏览的视频的客户端连接数目进行管理,如果一段时间内其连接数目为0,服务端应主动断开与该路视频的连接,以减少监控网点到中心的数据上传量,降低网络堵塞风险,因为网络带宽资源有限而宝贵;

4)对每一路视频可以灵活配置传输码流大小,帧率等,以适应不同客户端接入带宽环境;一般手机如多普达S1主频220MHz,可以传输6-10fps的数据,而对于高端手机实时查看视频可达20帧左右.

3.与中心其它应用进行通信交互,传递数据;如传递报警事件到客户端

与其它系统的结合

  与GIS(一般以Web形式提供)的结合显示当前监控点位置信息(周边环境,交通情况等);MIS系统提供一些相关信息,比如对重大危险源的监控如化工厂等,可以显示企业基本情况,危险源等级,危险物质名称以及相应的应急预案或者显示前端传感器监控的气体浓度,温湿度,压强等数值;学校教学区监控如教室,可以与教务系统互动显示授课教师姓名,课程名称,所在院系等情况.

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/embedesign/archive/2009/10/21/4705232.aspx