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

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

　　視頻編解碼

　　要考慮到采用什么類型編碼的視頻流是H.264或MPEG4,還是其它格式的視頻數(shù)據(jù),一般視頻監(jiān)控設(shè)備傳輸?shù)氖遣捎镁哂懈邏嚎s比的H.264數(shù)據(jù).確定了視頻數(shù)據(jù)編碼類型就好辦了,那就去找其相應(yīng)的編解碼庫,一般移植開源的ffmpeg到WM上進(jìn)行優(yōu)化(已經(jīng)有人做了,大家可以直接Google一下找到相應(yīng)的源代碼),移植其mpeg4 sp/h.264解碼器，在沒有任何優(yōu)化的情況下可支持32K,CIF,5-10fps的效果，對(duì)于一般的流媒體應(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解碼，很強(qiáng)大?；蛘邚腡CPMP播放器里面提取相應(yīng)代碼,TCPMP有N多種可用的編解碼，其中就有H.264的,解碼效率聽說不錯(cuò),可借鑒。

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

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

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

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

　　UI

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

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

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

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

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