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

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

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

1 總體方案設(shè)計

1.1 硬件系統(tǒng)結(jié)構(gòu)

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

1.2 系統(tǒng)軟件結(jié)構(gòu)

　　系統(tǒng)硬件配置完成后,就需要定制平臺和編寫代碼實現(xiàn)各個功能模塊,最終實現(xiàn)整個系統(tǒng)。系統(tǒng)的軟件結(jié)構(gòu)如圖2所示。

(1)用戶層:用戶的使用層,實現(xiàn)用戶用鍵盤撥號、接聽和掛斷電話等操作。

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

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

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

2.1 系統(tǒng)平臺設(shè)計

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

2.2 音頻編碼模塊的實現(xiàn)

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

2.3 視頻采集編碼模塊的實現(xiàn)

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

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

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

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

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

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

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

2.4.1 xvid解碼對零系數(shù)塊的處理分析

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

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

If(cbp)

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

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

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

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,每個bit都代表了一個宏塊中的一個8×8小塊,因此當相應(yīng)的8×8塊為零時,就直接跳過對該8×8塊的反向量化和IDCT過程。

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

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

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

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

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

2.5 用戶代理的實現(xiàn)

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

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

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

Osip_t*osip;

if(!osip_global_init())

Return -1;

If(!osip_init())

Return -1;

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

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

(3)建立事務(wù):在注冊完回調(diào)函數(shù)后,應(yīng)用可以建立用來調(diào)用OSIP的解析器。

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

2.6 音視頻數(shù)據(jù)傳輸?shù)膶崿F(xiàn)

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

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

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