对于市场上的视频监控系统，大家都有一定的了解，就是视频采集，经过无线/有线发送到服务或代理，客户从服务或代理上得到视频/音频流。不复杂。
对于不远的将来，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有一个说明网页，可以明确下载。请参看（http://ffmpeg.arrozcru.org/wiki/index.php?title=MSys_MinGW）其中下载地址我再列一下，以方便大家：
Mingw: http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=240780&release_id=595197
Mingw插件更新：
http://prdownloads.sourceforge.net/mingw/binutils-2.18.50-20080109-2.tar.gz?download
http://prdownloads.sourceforge.net/mingw/mingwrt-3.15.1-mingw32-dll.tar.gz?download
http://prdownloads.sourceforge.net/mingw
http://prdownloads.sourceforge.net/mingw/w32api-3.13-mingw32-dev.tar.gz?download
最稳定的gcc编译器for mingw插件：
http://prdownloads.sourceforge.net/mingw/gcc-core-3.4.5-20060117-1.tar.gz?download
http://prdownloads.sourceforge.net/mingw/gcc-g++-3.4.5-20060117-1.tar.gz?download
至于安装过程，网上搜一下，不会有问题can't miss it
MSys:http://prdownloads.sourceforge.n
... 4.30-1.exe?download
相关插件更新：
http://prdownloads.sourceforge.net/mingw/MSYS-1.0.11-20080821-dll.tar.gz?download
[url]http://prdownloads.sourceforge.net/mingw/bash-3.1-MSYS-1.0.11-snapshot.tar.bz2?download[/url]
[url]http://prdownloads.sourceforge.net/mingw/coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2?download[/url]
[url]http://prdownloads.sourceforge.net/mingw/make-3.81-MSYS-1.0.11-2.tar.bz2[/url]
至一Msys的安装及与Mingw整合在一起，网上查一下，can't miss it,
三 ， 开始for windows的ffmpeg编译。这个ffmpeg论坛上倒有相关的指导。请参照：
http://ffmpeg.arrozcru.org/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吧，根据过去的项目经验，QT在Mac, winodows ,linux上非常完美，（内存占用不小，世界上有完美吗？没有），移植到Wince/Symbian上，先看可行性，据我所知wince有商业版本，也可自己编译源码，QT for Symbian现在也有一个Garden版，当然对5800XM这样的有触摸屏的系统才有最大意义，因为QT都是对界面重新编码，而不是沿用每个OS自己的界面风格太多。期待将来的Symbian触摸屏吧，呵呵，非触摸屏的操作起来一定不方便。
三 ，先拿来源代码编译Qt for wince 这东东编起来也够麻烦的，网上有相关的介绍，可以参考。
四，我是用QT for windows 工具，在Vs2005中写完for windows的界面，再导出QT可以编译的.pro项目文件，然后在用ce 的qmake来编译，不过中途有导出的.pro 文件，qmake对其中一些项不能正确识别，比如对别的库的链接，要手工修改中间的Makefile文件，这个是细活。
五，编译完成，就是要用模块dependency tools来查看运行文件的依赖库，然后要一一找齐，不然，你放到移动平台上，报错莫名的错误，比如“可能组件缺失”“内存不足”真是扯淡的信息，呵呵，
六，总算运行起来，记住，最好要放release版的QT库及目标程序，不然你的手机的内存可真的要不足了。我就遇到这种情况几次，花了很多时间，才知道原因。
七，运行程序后，发现窗口风格真是QT风格，窗口大的看不到边框，一点一点拉动才能正确操作，要是在没有触摸屏的Symbian上你还不晕死。
今天先完成视频监控客户端QT界面从windows平台 到wince 平台的移植。明天有时间再重构程序架构。然后再开始增加新功能