基于SIP的嵌入式無(wú)線(xiàn)可視電話(huà)終端設計與實(shí)現

目前,許多國家都采用H.323作為IP電話(huà)網(wǎng)關(guān)之間的協(xié)議,把IP電話(huà)網(wǎng)關(guān)作為電路交換網(wǎng)和IP網(wǎng)絡(luò )的接口。但是,在下一代網(wǎng)絡(luò )中,由于大量IP產(chǎn)品的應用,使得端到端必須基于純IP網(wǎng)絡(luò )。3GPP已經(jīng)確定將SIP協(xié)議作為第三代移動(dòng)通信全IP網(wǎng)絡(luò )的控制協(xié)議。SIP(Session Initiation Protocol)協(xié)議是IETF于1999年提出的一種新的網(wǎng)絡(luò )多媒體通信交互信令,它相對于市場(chǎng)主體的H.323協(xié)議具有簡(jiǎn)單、擴展性好、便于實(shí)現等優(yōu)點(diǎn)。憑借這些優(yōu)點(diǎn),其得到業(yè)界的青睞,逐步成為NGN和3G多媒體子系統域中的重要協(xié)議。市場(chǎng)上出現越來(lái)越多支持SIP的智能多媒體終端及相關(guān)軟件和軟交換設備,SIP將成為IP視頻電話(huà)業(yè)務(wù)的主流協(xié)議之一。

　　本文以S3C2410為核心,通過(guò)幾個(gè)功能模塊的擴展,開(kāi)發(fā)出一個(gè)基于SIP的嵌入式無(wú)線(xiàn)視頻電話(huà)終端。該終端除了具備數字化和網(wǎng)絡(luò )化特點(diǎn)外,還采用了開(kāi)放的SIP同其他電話(huà)設備進(jìn)行通信,從而將網(wǎng)絡(luò )中任何一臺主機變成終端。同時(shí),基于WIFI的無(wú)線(xiàn)網(wǎng)絡(luò )技術(shù)使得多媒體終端具備隨時(shí)部署的特點(diǎn),并且逐步得到企業(yè)的認可。

1 總體方案設計

1.1 硬件系統結構

　　本電話(huà)終端系統的硬件方案為:使用三星公司的通用ARM芯片S3C2410配合嵌入式操作系統WINCE5.0.NET實(shí)現各種外圍接口,視音頻編解碼處理和傳輸控制協(xié)議等。這樣既不存在芯片成本高的問(wèn)題,又能保持很高的性能,可通過(guò)簡(jiǎn)單的程序下載實(shí)現軟件升級或增加新的編解碼標準。系統的硬件結構框圖如圖1所示。實(shí)現該系統的要點(diǎn)是:在WINCE下添加USB攝像頭和USB無(wú)線(xiàn)網(wǎng)卡驅動(dòng)模塊。

1.2 系統軟件結構

　　系統硬件配置完成后,就需要定制平臺和編寫(xiě)代碼實(shí)現各個(gè)功能模塊,最終實(shí)現整個(gè)系統。系統的軟件結構如圖2所示。

(1)用戶(hù)層:用戶(hù)的使用層,實(shí)現用戶(hù)用鍵盤(pán)撥號、接聽(tīng)和掛斷電話(huà)等操作。

　　(2)接口層:完成兩個(gè)功能,一是作為應用層和傳輸層的接口―建立套接字(SOCKET);二是擁有調用模塊層各個(gè)模塊的接口函數。

　　(3)模塊層:系統核心層包括:SIP模塊、數據傳輸模塊、語(yǔ)音和視頻模塊。SIP模塊實(shí)現OSIP協(xié)議棧的3個(gè)模塊:解析器、有限狀態(tài)機和工具模塊。數據傳輸模塊中傳輸層使用UDP協(xié)議,用RTP/RTCP進(jìn)行實(shí)時(shí)傳輸和控制。語(yǔ)音模塊和視頻模塊分別完成語(yǔ)音和視頻的采集與編解碼。

2 無(wú)線(xiàn)視頻電話(huà)終端的設計與實(shí)現

2.1 系統平臺設計

在WinCE產(chǎn)品開(kāi)發(fā)中,內核定制和應用程序開(kāi)發(fā)是非常重要的工作。

2.2 音頻編碼模塊的實(shí)現

系統初始化以后,音頻采集編碼模塊對應的子線(xiàn)程就被創(chuàng )建并掛起,當用戶(hù)需要采集音頻數據時(shí)再分別被喚醒。音頻采集編碼模塊主要完成語(yǔ)音的錄制和編碼。首先打開(kāi)波形音頻輸入設備,準備好緩沖區,然后利用聲卡把語(yǔ)音錄入到準備好的緩沖區。一個(gè)緩沖區錄滿(mǎn)后,就可以對緩沖區中的數據進(jìn)行編碼。其中音頻采集通過(guò)調用Windows低級音頻API函數族WaveIn和WaveOut來(lái)實(shí)現。編碼通過(guò)調用G.7XX音頻接口提供的編解碼器接口實(shí)現。

2.3 視頻采集編碼模塊的實(shí)現

筆者采用了OmniVision公司的OV7650 CMOS VGA 芯片。該芯片是一款高性能圖像壓縮芯片,輸出MJPEG視頻流數據。它的誤差穩定性非常好,可以獲取清晰度很高的視頻圖像,還可以靈活設置各路視頻清晰度,壓縮幀數。本系統直接從攝像頭驅動(dòng)中獲取MJPEG視頻流數據,圖像采集流程如圖3所示。圖像采集模塊用到的主要函數有:

capInitCamera():用來(lái)初始化視頻設備,并獲取當前可用的視頻設備數目。

capSetVideoFormat():設置視頻格式和分辨率。本系統使用的視頻格式為RGB24,分辨率為320×240像素。

capGrabFrame():從驅動(dòng)中抓取1幀圖像,并存儲在緩存FrameBuffer中。

capGetLastJpeg():將抓取的MJPEG格式的圖像轉換成JPEG格式,送到無(wú)線(xiàn)發(fā)送模塊。

視頻采集部分還有查詢(xún)視頻采集格式、設置明暗度、設置對比度等相關(guān)函數,這里不再詳述。在完成視頻采集后,再對視頻流進(jìn)行MPEG-4的視頻壓縮。視頻編碼通過(guò)調用xvid視頻解碼器接口提供的編解碼器接口實(shí)現。音頻解碼回放模塊和視頻解碼回放模塊將接收到的音頻和視頻數據解碼后播放。視頻播放則將視頻數據格式轉化為RGB,再用函數DrawDibDraw將其顯示。

2.4 xvid解碼算法在實(shí)時(shí)傳輸部分的優(yōu)化

2.4.1 xvid解碼對零系數塊的處理分析

在解碼過(guò)程中,如果知道圖像宏塊/塊為零系數塊,則可以直接跳過(guò)該塊的解碼過(guò)程(包括IQ和IDCT過(guò)程),從而大大節省解碼的計算量。在MPEG-4編碼器模型Xvid的程序中看到,在IDCT部分,參數CBP(編碼塊模式)是專(zhuān)門(mén)用來(lái)指示正在進(jìn)行編碼和不再進(jìn)行編碼的宏塊的信息。它是一個(gè)6bit的稽核,每個(gè)都代表了一個(gè)宏塊的一小塊。bit的狀態(tài)表示了該塊是否被編碼。如果塊的所有系數都為零,則塊就沒(méi)有被編碼。這個(gè)參數在進(jìn)行IQ、IDCT、反向掃描和重建之前被檢驗,這些過(guò)程并不對CBP為零的塊進(jìn)行。通過(guò)CBP解碼過(guò)程,在塊的基礎上的所有冗余計算都被減少了。

在Xvid解碼程序decoder.c的decoder_mbinter()函數中,最后有如下判斷:

If(cbp)

Decoder_mb_decode(dec,cbp,bs,py_cur,pu_cur,pv_cur,reduced_resolution,pMB);

由此說(shuō)明在參數CBP為零的情況下是不做宏塊解碼工作的。

但是這里可以看出,CBP參數為零代表的是整個(gè)宏塊量化后的DCT系數都為零,這里執行的是對整個(gè)宏塊后續解碼的跳出工作。而對于整個(gè)宏塊量化后的DCT系數不全為零,只有幾個(gè)8×8的塊量化后的DCT系數為零的情況下,在decode.c的decoder_mb_decode()函數中有如下過(guò)程:

For(i=0;i6;i++){

If(cbp(1(5-i)))){

Memset(block,0,64*sizeof(int16_t));

Start_timer();

Get_inter_block(bs,block,direction);

Stop_coding_timer();

…

Stop_iquant_timer();

Stop_idct_timer();

}

}

從以上程序看出:由于CBP有6bit,每個(gè)bit都代表了一個(gè)宏塊中的一個(gè)8×8小塊,因此當相應的8×8塊為零時(shí),就直接跳過(guò)對該8×8塊的反向量化和IDCT過(guò)程。

2.4.2 xvid解碼中IDCT和IQ的優(yōu)化

在IDCT程序中加入判斷語(yǔ)句,把全系數IDCT根據判斷前6個(gè)(精確度低一些)或者10個(gè)DCT系數的值分別進(jìn)行0系數IDCT變化(直接賦零)、3系數IDCT變換、64系數IDCT變換,這樣得到的程序計算量比原程序減少很多。

在這里用If判斷,如果這10個(gè)DCT系數都為零,則認為此塊是全0DCT系數,直接令此塊的所有IDCT后的系數為零。如果前3個(gè)系數block[0]、block[1]、block[8]不全為零,后7個(gè)系數block[2]、block[3]、block[9]、block[10]、block[16]、block[17]、block[24]全為零,則認為此子塊系數是3DCT系數的,直接對其進(jìn)行3系數的IDCT(程序已編好)。如果上述兩種都不滿(mǎn)足,就對其進(jìn)行全系數的IDCT。

判斷工作在XVID程序的idct.c中進(jìn)行,在原始的函數idct_int32(short*const block)中加入判斷程序。

IQ部分的優(yōu)化思路和IDCT優(yōu)化類(lèi)似,不再詳述。

2.5 用戶(hù)代理的實(shí)現

SIP UA模塊用于會(huì )話(huà)的建立、修改、終止,起著(zhù)信令控制作用。此模塊使用的SIP協(xié)議棧是OSIP2和EXOSIP。

OSIP2協(xié)議棧的開(kāi)發(fā)步驟為:

(1)初始化:主要調用函數osip_global_init()和osip_init(),操作代碼如下:

Osip_t*osip;

if(!osip_global_init())

Return -1;

If(!osip_init())

Return -1;

Osip棧需要在運行前初始化。在使用Osip棧之前,osip_global_init()函數是第一個(gè)被調用的,并且只能調用一次。調用這個(gè)函數將初始化語(yǔ)法分析。

(2)注冊回調函數:包括發(fā)送消息、結束事務(wù)、發(fā)送失敗和4個(gè)狀態(tài)機相關(guān)的函數。

(3)建立事務(wù):在注冊完回調函數后,應用可以建立用來(lái)調用OSIP的解析器。

EXOSIP有二種工作模式:事件模式和回調模式。本軟件采用的是事件模式。使用一個(gè)定時(shí)器,定時(shí)到時(shí)就通過(guò)函數eXosip_wait_event()去獲取SIP事件,SIP事件主要有EXOSIP_CALL_NEW、EXOSIP_CALL_ANSWERED等。事件獲取后,調用相應的事件處理函數,如SipCallNew、SipCallRinging、SipCallAnswered等。要建立、修改、終止呼叫還需要調用EXOSIP的osip_build_initial_invite、eXosip_initiate_call等函數。

2.6 音視頻數據傳輸的實(shí)現

利用RTP/RTCP實(shí)現語(yǔ)音視頻流的實(shí)時(shí)傳輸。RTP負責數據發(fā)送和接收,RTCP負責網(wǎng)絡(luò )丟包、誤碼情況的反饋等。通過(guò)調用JRTPLIB提供的庫函數就可以開(kāi)發(fā)出高質(zhì)量的音/視頻傳輸程序。

發(fā)送端調用JRTPLIB提供的庫函數實(shí)現語(yǔ)音視頻等的實(shí)時(shí)發(fā)送過(guò)程為:(1)通過(guò)調用RTPSession類(lèi)的構造函數創(chuàng )建一個(gè)RTP會(huì )話(huà)實(shí)例,然后調用RTPSession類(lèi)的方法對其初始化,設置負載類(lèi)型、標識和時(shí)戳增量,以及指定流媒體的目標地址;(2)設置RTP會(huì )話(huà)參數,通過(guò)調用RTPSessionParams類(lèi)的SetOwnTimeStampUnit()方法設置時(shí)間戳和RTP傳輸參數;(3)通過(guò)調用SendPacket()方法向目標地址發(fā)送采集編碼后的音視頻數據。接收端的創(chuàng )建RTP會(huì )話(huà)實(shí)例和RTP會(huì )話(huà)參數設置與發(fā)送端的設置相同。

本文設計和實(shí)現了一個(gè)基于SIP的嵌入式網(wǎng)絡(luò )無(wú)線(xiàn)可視電話(huà)終端模型。該終端支持音頻和視頻的實(shí)時(shí)通信。終端之間采用開(kāi)放的SIP進(jìn)行通信,SIP的應用避免了采用私有協(xié)議所帶來(lái)的封閉性,提高了同其他設備的互通性;同時(shí)利用WiFi技術(shù)提高了視頻電話(huà)終端的便攜性。SIP協(xié)議具有簡(jiǎn)單、可擴展的特性,將會(huì )在下一代網(wǎng)絡(luò )中占有重要地位。目前對SIP在視頻電話(huà)系統中的應用還處于試驗階段,能與之通信的SIP設備還不多,但隨著(zhù)NGN平臺的建立和SIP設備的不斷增多,其靈活性和互通性的優(yōu)點(diǎn)會(huì )逐漸體現出來(lái)。支持多人的可視電話(huà)終端將是進(jìn)一步要研究的課題,前景一片光明。