|
近期完成一个MJPEG图片传输型网络摄像机, 以适应当前互联网的网络状况. 网络摄像机在三四年前大家可能还比较陌生, 现在基本上都已耳熟能祥了, 不过作为刚出现几年的新生事物, 在应用方面应该会有很大的空间, 特别是现在的监控市场这么"火爆", 正是"不怕做不到, 就怕想不到". 在此将开发心得及这个作品的应用与各位探讨探讨, 所谓"见仁见智", 有不同看法欢迎交流. 首先, 先介绍一下相关技术现况. 如大家所知网络摄像机的主要两个技术核心有两个: 图像压缩方式和网络传输协议. 其中目前的图像主要有以下几种: MPEG-4压缩, H.264压缩(有些开发比较早的公司有用过H.263压缩), MJPEG压缩, 为了避开压缩专利的问题(如目前国内倍受压迫的MPEG-2在DVD上的专利费及MP3的专利费的问题及有可能发生在有线数字电视机顶盒上的专利费), 有的开发公司往往在压缩标准上做一些小修改. 庆辛的是国标的AVS在2006年终于有了小小的突破, 视频部分终于出镖了, 虽然在实现上做的人还不算多, 但有总比没有好, 根据过往的经验, 鬼子都是在我们开始赚钱时就带着"斧头"过来乱"砍"了(没赚钱没话说, 一赚钱就来, DVD如此, MP3如此, 机顶盒如此....). 网络传输协议在传输层有TCP和UDP两种. 到应用层相应的有HTTP和RTP/RCTP以及开发者自定义的应用层协议. 其中HTTP以TCP为传输协议, RTP以UDP为传输协议, RTCP以TCP为传输协议. 对于开发者自定义的应用层协议有的用TCP有的用UDP. MPEG-4及H.264压缩标准其实已经预留好了网络传输的接口, 如果直接采用RTP/RTCP协议可以很方便地实现, 在实现上, 由于数据通道RTP协议采用的是UDP协议传输(UDP协议不保证发出的数据接收方能可靠的收到), 在互联网上传输往往会因为网络因带宽不够而丢失, 为了发现这种情况同时配备了控制通道RTCP协议采用的是TCP协议传输(TCP协议可以保证收发两端保持数据完整传输), 摄像机端收到由RTCP协议反馈回的情况后通过降低画面质量以适应数据通道的传输带宽, 这样在实际应用中就往往会出现画面马赛克, 更严重时根本没有图像(如2006年底海底电缆故障时,国际线路带宽大降, UDP协议的数据包首当其冲的要被丢掉). 这种方式在风调雨顺时没有问题, 但是一碰到出现冬瓜豆腐时就问题大大, 而这个时候往往是最需要保持图像通信畅通的时候. 当然, 有问题就有解决办法, 网络摄像机的大哥安士迅(AXIS)就推出了MPEG-4/MJPEG双压缩模式的网络摄像机, 我想这也说明MJPEG这种压缩模式在网络摄像机里还存在的缘故, 另外还有一个解决就是多铺几条光缆. 也有的开发者不用RTP/RTCP应用层协议, 通过自定义采用TCP协议来传输, 这也是一种变通, 不过任何变通都是有代价的, 最明显的就是, 在网络带宽不够的时候, 采用TCP协议传输因为要保证数据完整性, 将花费更多的时间在重传上, 这样实时性就会受影响, 这个也还可以接受, 麻烦的是不小心的话搞不好摄像机本地缓存爆掉了(高手做的当然不会出现这个问题), 而且对网络带宽的抖动尤其敏感. 这个方法不是不好, 只是如果将来给了专利费却不能完全享受MPEG-4/H.264带来的快感, 钱花得有点冤. 至于MJPEG压缩, 其实就是连续的JPEG压缩的图片流, 因为JPEG采用单帧内压缩, 为保证数据的完整性, 不管应用层采用何种模式一般都采用TCP协议传输, 即使有的开发者为了提高在城域网间(如在同省内, 国内跨省容易碰上两网的问题, 以前的经验是带宽奇窄)的传输速度采用UDP协议传输, 但为了保证数据完整性都加了相应的控制, TCP协议本身有数据完整性控制机制, 如数据确认, 丢失重传等等, 所以在提交给互联网做网路交换时会花比较长的时间, 而且基于摄像机用户带宽的限制(一般用户的ADSL或小区宽带的上传限制对TCP协议很严, UDP协议相对宽松, 因为如果网络拥塞的话, 服务商是可以丢包的)往往会有所制肘, 如果采用UDP协议传输, 自定义一些控制虽然在为实现控制的软件复杂度上比直接采用TCP协议省不到哪里去, 但是带来了速度和带宽限制上的好处, 出发点是可以的. 不过, 对前面提到的出现大冬瓜豆腐的时候, 那也就没辙了. 不管如何, 采用MJPEG压缩而且用TCP协议传输有一点是保证的, 就是除非互联网全断, 不然一定能够传得出去清晰完整的图像, 最多就是快慢问题. 由此来看, 虽然MJPEG这个东东效率并不高(在MPEG-4/H.264里面, 如果不要帧间压缩, 其实单帧的压缩就和JPEG差不多), 也还是有用的, 另外吸引人的还有没有专利费的问题. 以上只是说明一下各个压缩标准和采用的传输协议带来的问题, 当然任何东西都是有利有弊的, 没有绝对的好也没有绝对的不好, 只是适用场合不同, 大家如果觉得这个分析对今后采用网络摄像机时有帮助就好了. 说完压缩和传输, 接下来的就是应用层协议, 现在看到好多在浏览器里看的都是用插件的模式, 通过摄像机下载插件到用户端, 还有的先需要在用户端安装一些环境(如 Framework 等). 这样带来的问题是用户的后端录像管理软件基本上没有多大的自由度, 只此一家别无分店(当然有些开发者向特定软件开发商开放协议的除外, 象网上看到的Netcam Watcher Professional这家公司开发的录像软件可以支持多种主流品牌的网络摄像机), 同时对摄像机开发者来说也会被用户的各种录像要求搞得很累, 用户流失往往不完全是摄像机本身的原因而是管理软件不好. 互联网的发展壮大靠的就是网络的开放性, 既然是网络摄像机, 不如采用开放的协议接口, 让软件开发商们有所作为, 前面卖的只是摄像机, 后面爱用哪家的管理就用哪家的管理, 各取所需才能繁荣经济. 最后还有一个就是图像的传感器, 这个东东大家一说都明白, 不外乎CCD和CMOS. 但是用在网络摄像机上就有差别了. 由于网络摄像机是传输的数字压缩图像, 因此在输入到压缩模块时图像已经是给数字化的了, 而CCD图像传感器输出的是模拟图像, 所以前端需要做数字化处理. 有的网络摄像机在压缩的软件模块前端有相应的硬件做数字图像处理, 而现在大部分都是延用目前监控摄像机的数字输出接口, 图像的数字化效果完全由现在的监控摄像机的数字输出接口决定. 也就是说, 要高清的网络摄像机, 它的前端就必须是高清的数字处理器, 像2163B这个东东. 这个东东说起来有气, 看看现在的监控摄像机市场, 基本上都是日本人的天下, 不是SONY就是SHARP, 从CCD到处理器, 日本人说提价全体摄像机价格就上去, 日本人说降价全体摄像机价格就下来, 一个CCTV摄像机成本中90%都在日本人手里控制, 国人为了10%的加工费拼得死去活不过来. 而CMOS本身输出的就是数字信号, 在网络摄像机的应用上就手到擒来, 当然CMOS的效果存在差距, 但有很多仁人志士正在为缩短这个差距做努力, 所以, 在条件允许的情况下采用CMOS也无妨, 实在没办法了就只好给中日友好做贡献了. 基于以上的认识, 制作完成了这个MJPEG的CMOS的TCP传输的HTTP应用层的接口开放的网络摄像机, 用户只要以最简单的链接网络图片的方式将实时的图片链接到需要的地方(如下图, 中国时间, 白天黑夜), 同时可以采用Java 虚拟机平台显示实时流(当然不用Java也行, 只要按取图片方式不断去取就行). 在此愿聆听大家的应用想法. 
[此贴子已经被作者于2007-6-19 9:53:56编辑过]
|
tanyonggen01
发表于 2007-4-18 17:12:00
转播
分享
淘帖
分享到新浪微博
