手機(jī)遠(yuǎn)程監(jiān)控系統(tǒng)主要涉及5大方面，分別為zui核心的視頻編解碼、網(wǎng)絡(luò)傳輸、UI設(shè)計(jì)、服務(wù)端(手機(jī)流媒體)以及與其它系統(tǒng)的結(jié)合。
在手機(jī)上瀏覽實(shí)時(shí)視頻圖像畫面一般過程是手機(jī)客戶端發(fā)起一個(gè)視頻預(yù)覽請求到手機(jī)流媒體，告知流媒體當(dāng)前客戶端想瀏覽那一路視頻，流媒體服務(wù)器去連接前端遠(yuǎn)程的DVR/DVS取其子碼流數(shù)據(jù)，轉(zhuǎn)發(fā)傳輸QCIF畫面質(zhì)量的視頻數(shù)據(jù)到手機(jī)上，客戶端軟件調(diào)用解碼庫對接收到視頻數(shù)據(jù)解碼，zui終通過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的效果，對于一般的流媒體應(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 上可以用sdl.音頻解碼主要包括AAC,AMRNB,AMRWB。AAC和AMRNB是gprs和edge帶寬支持的音頻(aac效果比 amrnb好),AMRWB是3G后的音頻格式。在ffmpeg 0.5 release中已經(jīng)支持amrnb/wb的fixed point解碼，很強(qiáng)大。或者從TCPMP播放器里面提取相應(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é)議，也是流媒體傳輸使用zui廣泛的協(xié)議。實(shí)時(shí)傳輸協(xié)議RTP(Realtime Transport Protocol)在一對一或一對多的傳輸情況下工作，其目的是提供時(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會話期間，各參與者周期性地傳送RTCP包，包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，因此，服務(wù)器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和zui小的開銷使傳輸效率*化，故特別適合傳送網(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；后者只保證盡zui大努力的傳輸，不會重傳丟幀，實(shí)時(shí)性好，要解決防火墻和NAT問題,因?yàn)槭澜缟?0%的GSM運(yùn)營商是這樣做的,使流媒體服務(wù)器根本不能連接到手機(jī)。如果對幀率要求比較高的手機(jī)電視，推薦采用UDP傳輸，因?yàn)檠舆t較大的重傳數(shù)據(jù)對用戶是沒有意義的，寧可丟棄。如果你決定使用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)過改動后也能用)對live555經(jīng)過裁剪后可移植到symbian和windows 上。
現(xiàn)在手機(jī)上網(wǎng),其網(wǎng)絡(luò)傳輸速率一般不成問題,2.75G EDGE網(wǎng)絡(luò)有高速度(zui多236 kbps，對QCIF視頻畫面質(zhì)量傳輸來說足夠了)和低能耗，據(jù)了解與GPRS相近。當(dāng)前的3G模塊比較耗電。未來隨著3G的推廣，以及有消息稱中國移動TD-LTE(4G)2010年會進(jìn)入商用，下載一部164兆的電影，僅花了不到2分鐘，而通常300兆的電影，則只要3到5分鐘就能下載完畢。對此，業(yè)內(nèi)人士介紹，4G可以達(dá)到百兆以上的速率，對于3G來說又是一個(gè)質(zhì)的飛躍。如果說3G是國道，4G就是高速公路。而對于4G與2G、3G之間zui大的不同，技術(shù)人員介紹，除了速度比他們快之外，視頻監(jiān)控、視頻通話效果也將更加流暢、高清。在網(wǎng)上看高清視頻，不用擔(dān)心畫面卡或聲像不同步……與3G相比，4G帶寬可達(dá)到170M以上，其下載速度比3G快80倍。
UI
用戶對手機(jī)軟件的界面是很在意的，做的好看了他會覺得有技術(shù)含量，做的好用了他會更加喜歡我們的產(chǎn)品。所以一套好的UI是*的。手機(jī)軟件開發(fā)的大部分工程是在做UI系統(tǒng)。一套好的自主的手機(jī)軟件UI系統(tǒng)是產(chǎn)品核心競爭力的一部分。在Windows 的界面開發(fā),使用C + SDK做漂亮的界面不容易,一旦在界面上控件比較多，控件的布局更是頭痛。 橫豎屏切換的時(shí)候也得考慮，不同手機(jī)屏幕尺寸可能也不一樣；不同的字體下，界面差異也非常大……
其實(shí)要做出好的界面zui后還是要回歸RECT，也就是自己繪制貼圖。 如果要做的很漂亮，那還是自己封裝一套界面控件，這樣控制起來方便。 橫豎屏問題，你繪制的時(shí)候不應(yīng)該寫死的位置坐標(biāo)，應(yīng)該取相對坐標(biāo)。 在橫豎屏切換的時(shí)候會觸發(fā)WM_SIZE等一些消息，里面改變相對坐標(biāo)的橫豎屏大小就OK啦. 做界面推薦一個(gè)MFC的擴(kuò)展，Xtreme ToolkitPro，里面有大量的類，可以參考他們的類來寫寫自己的控件.這就是現(xiàn)狀，沒辦法，剛開始的時(shí)候會比較艱難。 積累以后有自己的一套控件庫，開發(fā)速度會提高。
開發(fā)應(yīng)用每種方式都各有其優(yōu)勢, 沒有，只有更適合。看具體應(yīng)用, 選擇自己的技術(shù)，自己熟悉的技術(shù)。
服務(wù)端
作為服務(wù)端的手機(jī)流媒體要從安全性,穩(wěn)定性，并發(fā)性等各性能指標(biāo)綜合考量，為客戶端提供良好的視頻服務(wù)訪問；它主要具有以下幾個(gè)功能:其中一個(gè)基本功能就是鑒權(quán)，驗(yàn)證登錄請求過來的客戶端具有那些權(quán)限，可以瀏覽那路視頻，可不可以進(jìn)行云臺控制，點(diǎn)播回放那些文件等核心功能是對資源進(jìn)行有效地管理，如視頻源，當(dāng)前登錄用戶等；與中心其它應(yīng)用進(jìn)行通信交互，傳遞數(shù)據(jù)；如傳遞報(bào)警事件到客戶端。
