手機遠程監(jiān)控系統(tǒng)主要涉及5大方面，分別為最核心的視頻編解碼、網(wǎng)絡(luò)傳輸、UI設(shè)計、服務(wù)端(手機流媒體)以及與其它系統(tǒng)的結(jié)合。

　　在手機上瀏覽實時視頻圖像畫面一般過程是手機客戶端發(fā)起一個視頻預(yù)覽請求到手機流媒體，告知流媒體當前客戶端想瀏覽那一路視頻，流媒體服務(wù)器去連接前端遠程的DVR/DVS取其子碼流數(shù)據(jù)，轉(zhuǎn)發(fā)傳輸QCIF畫面質(zhì)量的視頻數(shù)據(jù)到手機上，客戶端軟件調(diào)用解碼庫對接收到視頻數(shù)據(jù)解碼，最終通過DirectShow 繪制到界面上顯示。

　　視頻編解碼

　　要考慮到采用什么類型編碼的視頻流是H.264或MPEG4,還是其它格式的視頻數(shù)據(jù),一般視頻監(jiān)控設(shè)備傳輸?shù)氖遣捎镁哂懈邏嚎s比的H.264數(shù)據(jù).確定了視頻數(shù)據(jù)編碼類型就好辦了,那就去找其相應(yīng)的編解碼庫,一般移植開源的ffmpeg到WM上進行優(yōu)化(已經(jīng)有人做了,大家可以直接Google一下找到相應(yīng)的源代碼),移植其mpeg4 sp/h.264解碼器，在沒有任何優(yōu)化的情況下可支持32K,CIF,5-10fps的效果，對于一般的流媒體應(yīng)用足夠了。以后還要經(jīng)過算法和匯編優(yōu)化。解碼后還需要經(jīng)過yuv2rgb和scale，需要注意的是ffmpeg的解碼有消隱區(qū)的說法，即QCIF的圖像其linesize不是176而是 192，如果你發(fā)現(xiàn)解碼后圖像呈綠色，需用img_convert()轉(zhuǎn)一下(目的格式也是PIX_FMT_YUV420P)。Symbian上用DSA 直接寫屏就行。Wndows Mobile上可以用sdl.音頻解碼主要包括AAC,AMRNB,AMRWB。AAC和AMRNB是gprs和edge帶寬支持的音頻(aac效果比 amrnb好),AMRWB是3G后的音頻格式。在ffmpeg 0.5 release中已經(jīng)支持amrnb/wb的fixed point解碼，很強大?；蛘邚腡CPMP播放器里面提取相應(yīng)代碼,TCPMP有N多種可用的編解碼，其中就有H.264的,解碼效率聽說不錯,可借鑒。

　　網(wǎng)絡(luò)傳輸

　　視頻數(shù)據(jù)是采用TCP還是UDP呢,是自定義通信報文還是采用RTSP/RTP/RTCP這類通信協(xié)議加以封裝.流媒體網(wǎng)絡(luò)傳輸要滿足高帶寬，低傳輸延遲，支持組播模式，基于差錯恢復(fù)的可靠保證和通道同步(尤其是視頻和音頻流的同步)。RTP/RTCP是一種基于組播的應(yīng)用層協(xié)議，也是流媒體傳輸使用最廣泛的協(xié)議。實時傳輸協(xié)議RTP(Realtime Transport Protocol)在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。RTP的典型應(yīng)用建立在UDP上，但也可以在TCP或ATM協(xié)議上工作。RTP本身只保證實時數(shù)據(jù)的傳輸，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。實時傳輸控制協(xié)議RTCP(Realtime Transport Control Protocol)：負責(zé)管理傳輸質(zhì)量在當前應(yīng)用進程之間交換控制信息。在RTP會話期間，各參與者周期性地傳送RTCP包，包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，服務(wù)器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網(wǎng)上的實時數(shù)據(jù)。

　　RTSP則是當前流媒體傳輸?shù)闹髁鳂藴剩B微軟都拋棄了MMS而轉(zhuǎn)而支持RTSP， RTSP可以支持客戶端暫?；胤磐Ｖ沟炔僮?，基本不用考慮音視頻同步問題(因為音頻視頻分別從不同RTP PORT讀入緩沖)。值得說明的是，RTSP成功后，就開始RTP傳輸，分為RTP OVER TCP和RTP OVER UDP，前者保證每個數(shù)據(jù)包都能收到，如果沒收到就重傳，而且不用考慮防火墻NAT;后者只保證盡最大努力的傳輸，不會重傳丟幀，實時性好，要解決防火墻和NAT問題,因為世界上60%的GSM運營商是這樣做的,使流媒體服務(wù)器根本不能連接到手機。如果對幀率要求比較高的手機電視，推薦采用UDP傳輸，因為延遲較大的重傳數(shù)據(jù)對用戶是沒有意義的，寧可丟棄。如果你決定使用RTP/PTSP,網(wǎng)絡(luò)部分可以采用強大的開源庫live555來實現(xiàn)RTSP /RTP協(xié)議，其性能穩(wěn)定而且支持大多數(shù)音視頻格式的傳輸。(當然ffmpeg也實現(xiàn)了網(wǎng)絡(luò)傳輸部分,經(jīng)過改動后也能用)對live555經(jīng)過裁剪后可移植到symbian和windows mobile上.

　　現(xiàn)在手機上網(wǎng),其網(wǎng)絡(luò)傳輸速率一般不成問題,2.75G EDGE網(wǎng)絡(luò)有高速度(最多236 kbps，對QCIF視頻畫面質(zhì)量傳輸來說足夠了)和低能耗，據(jù)我了解與GPRS相近。當前的3G模塊比較耗電.未來隨著3G的推廣,以及有消息稱中國移動TD-LTE(4G)2010年會進入商用,下載一部164兆的電影，僅花了不到2分鐘，而通常300兆的電影，則只要3到5分鐘就能下載完畢。對此，業(yè)內(nèi)人士介紹，4G可以達到百兆以上的速率，對于3G來說又是一個質(zhì)的飛躍。如果說3G是國道，4G就是高速公路。而對于4G與2G、3G之間最大的不同，技術(shù)人員介紹，除了速度比他們快之外，視頻監(jiān)控、視頻通話效果也將更加流暢、高清。在網(wǎng)上看高清視頻，不用擔(dān)心畫面卡或聲像不同步……與3G相比，4G帶寬可達到170M以上，其下載速度比3G快80倍。

　　UI

　　用戶對手機軟件的界面是很在意的，做的好看了他會覺得有技術(shù)含量，做的好用了他會更加喜歡我們的產(chǎn)品。所以一套好的UI是必不可少的。手機軟件開發(fā)的大部分工程是在做UI系統(tǒng)。一套好的自主的手機軟件UI系統(tǒng)是產(chǎn)品核心競爭力的一部分。在Windows Mobile的界面開發(fā),使用C + SDK做漂亮的界面不容易,一旦在界面上控件比較多，控件的布局更是頭痛。 橫豎屏切換的時候也得考慮，不同手機屏幕尺寸可能也不一樣;不同的字體下,界面差異也非常大……

　　其實要做出好的界面最后還是要回歸RECT，也就是自己繪制貼圖。 如果要做的很漂亮，那還是自己封裝一套界面控件，這樣控制起來方便。 橫豎屏問題，你繪制的時候不應(yīng)該寫死的位置坐標，應(yīng)該取相對坐標。 在橫豎屏切換的時候會觸發(fā)WM_SIZE等一些消息，里面改變相對坐標的橫豎屏大小就OK啦. 做界面推薦一個MFC的擴展，Xtreme ToolkitPro，里面有大量的類，可以參考他們的類來寫寫自己的控件.這就是現(xiàn)狀，沒辦法，剛開始的時候會比較艱難。 積累以后有自己的一套控件庫，開發(fā)速度會提高.

　　開發(fā)應(yīng)用每種方式都各有其優(yōu)勢, 沒有最好，只有更適合。看具體應(yīng)用, 選擇最適合自己的技術(shù)，自己熟悉的技術(shù)。

　　Win32 開發(fā)的效率相對較低，但是靈活性較高。 　　WTL 對它不了解，不加評論，但似乎它的資料相對較少。

　　MFC 開發(fā)效率不錯，但編譯后的程序體積較大。對了，它的資料也非常豐富。