移动视频监控.doc

项目综述 对于市场上的视频监控系统，大家都有一定的了解，就是视频采集，经过无线/有线发送到服务或代理，客户从服务或代理上得到视频/音频流。不复杂。 对于不远的将来，3G，4G的到来，对移动的业务有一个推动，监控自然有了称动的一个特性，废话少说，先说说一般常用的架构。客户端采集-通过无线数据网-服务器-移动客户端(手机)取得视频流,可行性：技术环节纵观： 采集端： ARM/DSP从视频头得到采集数据，进行开发（也有现成硬件），主要是编码，可以采用很多开源跨平台编码器（ffmpeg/xvid/xh264),标准流可以采用开源（Live555/vlc)，也可自定义协议 服务器： 可以用Live555实行RTSP及流媒服务器， 开源跨平台编码器， 客户监控端： 可以用Live555/vlc 实现RTSP， ffmpeg/xvid/xh264编解码，由于客户端操系统的多变性，可以用采跨多种移动平台的SDL进行开发流的播放及界面的显示。 至于需求就不多说了， 至于技术系统分析及设计也不多说了，自有文档：） 计划： 1，原型开发（3weeks) 2, 总体设计（2weeks) 3, 制定开发计划，组织开发(1week) 4,实现第一架构版（1month)，严格测试 5, 迭代3个周期 6测试发布Alpha版。原型开发-总体分析。原型开发，重点是解决一些关键问题，处理技术风险列表中关键项：此项目中，采集，上传到服务器的系统都常见，关键是服务器到移动端， 服务器可以先用RealNetworks的 Helix Server搭建，很简单，10分钟下载，10分钟配置。 客户端开发： 寻找跨平台的几个关键环节的部分： RTSP（including RTP/RTCP)，编解码，跨移动平台的显示。 RTSP，live555是开源以C+编写，处理起来容易，不同平台移植不错。VLC的看着很庞大，看了一会，觉得有点乱。什么都有。先做备选。 编解码，ffmpeg 资料多，看一下，也很容易懂， xvid代码据说效率高，不过用ffmpeg中的h264简化代码处理H264应该不错。 显示， QT写界面不错，就是查了一下，往上面绘解码视频帧不容易呀（render),就用SDL吧，这个东东跨平台，多个常用移动平台都支持。Symbian也OK，不过Sybmain的DSA也没有问题，有这样的经验。 那么就先从RTSP着手。研究 Live555. 以后几天会写live555的分析文档，做为此项目的日志。原型开发-(RTSP)Live555一，Live555开发环境搭建：二，Wince 平台的移植： 由于Live555是一种跨平台的库，虽然没有专门for WINCE的，有人会说，既然跨平台，为何不支持CE，呵呵，近来看了很多跨平台的库，他们的代码注释中常看到这样的话“since winodows OS is not POSIX, it is a silly system，not supported by our product, 这些人好像都看不起windows OS，呵呵，没关系，这是他们的立场与观点，幸好移植起来并不复杂。 1，把源码依次加出到Window CE项目中。进行编译，有一堆错误，没关系，只是热身。 2，首先会有Winsock2相关的问题，没关系，找到一个与winsock2相关的定义“”把这个宏定义为1即可。编译此项目无法链接，当然了，wince中的网络库是ws2.lib,而不是 ws_2.lib. 3, windows 平台不支持strstream,因此要在工程中 定义“NO_STRSTREAM宏。三，Live555框架分析: 几个主要的类。四，live555 Client 使用活动图：原型开发-(音视频编解码多平台移植（for window/wince）)(音视频编解码多平台移植（for window/wince）)ffmpeg -自由之路即是曲折之路 终于完成了了第二个Client side原型（for Wince)，其中花掉我最多时间的就是ffmpeg的对WINCE的移植。其中有大半时间是由于网上的一些不完整及不正确信息所误导，但是没有这些零星的信息，我可能花费更多的时间。现在我把自己的移植过程分享给大家，我尽量做到事无巨细，也好让大家少走弯路，省去我们程序员们的时间。那可是大把的银子与信心浪费。呵呵，书归正传。 一，第一个想法，仍像从前移植平台代码一样，先找到这种跨平台代码的自己的特定平台的make文件或工程：可惜没有发现ffmpeg 有for windows 及 for wince的make 及工程。再细读 ffmpeg的官方网站，让人仰天大笑，其中说到，由于VC/Visual studio 开发环境的编译器，对C99支持不好，而ffmpeg又是follow这些C语言规范写的，因此，不支持VC/VS的编译器。这比一些跨平台项目说windows OS is silly OS, not popular POSIX 从而不支持的说法更有趣。其实，从IT行业而言，这些理由都不是那么的合逻辑，也不够严谨。但代码是别人写的。我们又能如何呢？呵呵。 二，曲径通幽，既然ffmpeg不支持windows的编译器，那我们还有一个曲折的办法，它不是支持POSIX嘛 ，也就是支持linux/unix嘛 ，那我们就有了我们的办法，我们的windows平台上的linux编译器（算一种交叉编译吧，呵呵）于是大家想到了Cyxwin及 Mingw+Msys,其它，Cyxwin中编译出windows的平台上可用的库，还是调用了Mingw的编译器，于是我们就直接研究Mingw +Msys吧，但是这个东东有一个致命的弱点，就是要安装，分别要更新一堆组件，更新到什么版本呢，天知道，都用最新的吧。去相关的网站去下载他们（http:/）不过Mingw的 sourceforge 网站真不是人去的，里面乱放，而且目录没有一个明确的索引，网站又慢，我是花了一天时间才找齐，后来发现ffmpeg有一个说明网页，可以明确下载。请参看（/wiki/index.php?title=MSys_MinGW）其中下载地址我再列一下，以方便大家：Mingw: /project/showfiles.php?group_id=2435&package_id=240780&release_id=595197Mingw插件更新： /mingw/binutils-2.18.50-20080109-2.tar.gz?download /mingw/mingwrt-3.15.1-mingw32-dll.tar.gz?download /mingw /mingw/w32api-3.13-mingw32-dev.tar.gz?download最稳定的gcc编译器for mingw插件： /mingw/gcc-core-3.4.5-20060117-1.tar.gz?download /mingw/gcc-g+-3.4.5-20060117-1.tar.gz?download至于安装过程，网上搜一下，不会有问题cant miss it MSys:http:/prdownloads.sourceforge.n . 4.30-1.exe?download相关插件更新： /mingw/MSYS-1.0.11-20080821-dll.tar.gz?download url/mingw/bash-3.1-MSYS-1.0.11-snapshot.tar.bz2?download/url url/mingw/coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2?download/url url/mingw/make-3.81-MSYS-1.0.11-2.tar.bz2/url 至一Msys的安装及与Mingw整合在一起，网上查一下，cant miss it,三 ， 开始for windows的ffmpeg编译。这个ffmpeg论坛上倒有相关的指导。请参照：/wiki/index.php?title=Static这里有一个静态库的编译。按向导完成编译成静态lib库，可以址接进行编译链接到 windows项目中（only for windows平台，not for wince),好放到一个新的window项目中，编译成功，链接，一堆的库找不到，哈哈，仰天大笑，用工具一查相关引用，原来这些找不到函数，还在mingw的库中，也就是说要在项目中用ffmpeg的静态库，你还要搭上一堆mingw的库，就像现在市场上的搭配销售。再笑，我先找个地方睡半天，缓解我的想扁人的冲动。睡醒之后，换种用法，我编动态库，这下你不会不把我的所有函数给我加到我的DLL里吧，再换了一些ffmpeg的./configure参数。搞定。生成了动态库，及lib.用到项目里，编译通过。不过，这只是万里长征第一步，我还要最痛苦的for wince的库。四，for wince 的ffmpeg: 从linux的代码用mingw编成 for windows那是人家mingw的任务，我们也只绕了一道弯，for wince的mingw不存在呀，怎么办，忽然想到linux上的交叉编译，人家可以在linux用定制的gcc交叉编译器弄出for wince的库，那我们何不在Mingw上搞出for wince的库，一查，网上果然仅有的解决方案，也就是交叉编译成for wince 的ffmpeg，所用交叉编译器，大家可以看仔细了，网上有绝大多数的相关贴子给的交叉编译器是不正确的（下载的地址不正确）真搞不懂网上一堆人转载别人的文章，也不去验证一下，转载干嘛？，我就是由于用了网上这些人转载地址去下载编不正确的编译器，浪费了3天的时间，无功而返。记住，下载的交叉编译器是 cegccmingw 下载地址是：（）进行编译。编译最新的库，会有一些汇编通不过。自己对汇编不熟悉，不过要是在linux上交叉编译应该没问题，有兴趣的话，可以自己试那个环境，那样的话，用的交叉编译器就应该是cegcc.没办法，为了节省我的时间，我可是要在两周内完成三个平台的原型开发的。就拿了2007年的ffmpeg来编。其中也改了不少东西才编译能通过，首先，./configure 之后，在生成的config.mak中，要修改“SLIB_EXTRA_CMD=-lib /machine:i386 /def:$(:.dll=.def)”为“SLIB_EXTRA_CMD=-lib /machine:arm /def:$(:.dll=.def)”,及 “EXTRALIBS= -lm”改为“EXTRALIBS= -lm -lws2.lib”，其中编译过程中采取了perror禁用，有seek函数禁用与替换（由于没有用zlib,linux平台估计会没有问题).细节，可以有时间再写，有兴趣的话，可以加我MSN。编译成功后。用在C+环境中。测试普通函数通过，不过在视频编换时，效率不高。换了一下网上的别人编译的ffmpeg库，（网上有一个下载，不过此SDK在wince上用时，用在C+项目中有问题。头文件中有重复定义，解决办法是放在.c文件中，由Cpp文件来调用，这样可以规避这些问题，但这样就存在了一些全局变量.这样的头文件是不能用在Sybmian平台的。另外一种思路就是不用ffmpeg.用Xvid解 mpeg4（测试下来效率好像要高于ffmpeg,毕竟是专门for mpeg4）,用xh264解 H264,拿过他们的源代码一看，还是人家这跨平台，现成的for windows平台的工程make文件，这才是真正的跨平台。当然想要更多功能，ffmpeg地位还是无人能及。如果有人对编解码做简单的跨平台移植有兴趣，可以加我MSN一起学习探计，相互学习，搞技术嘛，大家一起共享信息，会省掉多少人的多少个不眠之夜，我就是因为一些信息的不准确，害得我移了一周，每天可都工作到凌晨2点多。好了，今天就写到这里，至于Symbian平台的移植，改天再写。原型开发-Symbian客户端进展。上周完成了windows/wince两个平台的原型开发，总结起来，ffmpeg 花了太多时间，这个跨平台库的确不够友好。编好的for wince的动态库 在windows mobile 6.X上出现无法正常加载现象，所以现在的wince平台客户端，只能在windows mobile5, ppc2003上正常运行。期待该库新的进展。不过我过于求功能全面化，不然完全可以改用Xvid 及xH264进行解码。由于我采用的库全是跨平台，其它的RTSP库（live555)及播放库（SDL），所以移动Symbian理论上没有什么问题。不过说到Symbian,想必大家都有些头痛，我是从Series60 SDK0.9开始用Symbian 的，那时文档少得可怜，SDK本身也一堆的问题没有解决，那时没有线程，没有openC,RSS文件式的界面开发，一堆标新立异的API。全新不兼容标准C+的SymbianC+，连用个STL都要去国外代理网站上去下载 STLPorts来用，呵呵，想起来头就大。已致于我没放太多时间在这个平台上，直到看到了openC 及QT Garden版。扯得有点远，近来手头项目太忙，Symbian客户端不大。一，完成了ffmpeg for symbian的编译，这个只花了一天的时间去编译及改代码。出现最多的，只是一些tprintf 及 AV_DEBUG的一些宏定义，编译器无法识别，这算不错的了，如果是C+，SymbianC+对模板及一些类型定义typeinfo问题处理起来可就难了。 我用的是carbide 1.2编起来还算好，就是每次重编不能clean要手工清除一些中间文件，否则人家就罢工，不能go on compiling.这是symbian 开发环境一直以来的垢病，答案是：无解。一直无解。二，SDL的移植，很简单，有专门的工程，编译成功，还没试三，RTSP（Live555）,我先进行了自己的整理与封装，以减少移植中的麻烦，毕竟是一套C+的库。完成了一半，如果有问题我就从VLC或者Darwin，或者其它开源库中找一套简单的RTSP来备用，不会有问题。四，整体架构的整理与设计。这是以后开发迭代的基石，也是我对项目的习惯，这一点上，我较喜欢所谓的RUP方式。原型开发-原型跨平台界面装饰QT一，两个操作系统的客户端已完成。现在就尝试用一些界面工具来修饰。SDL当然是一套很简单的界面库，不过写起界面来，太麻烦，代码量太大，简直就是重新写一套界面库，因为没有按界面控件，窗口元素，手工来封装，可行，但工作量，呵呵二，那就用常用的QT吧，根据过去的项目经验，Q