這是我本科的畢業(yè)設(shè)計(jì)。時(shí)隔5個(gè)月，再次回顧一下。
本課題研究嵌入式系統(tǒng)在數(shù)據(jù)采集，3G無線通信方面的應(yīng)用，開發(fā)集視頻采集、地理信息采集、無線傳輸、客戶機(jī)/服務(wù)器模式于一體的車載終端，實(shí)現(xiàn)終端采集視頻與GPS信息的傳輸，支持服務(wù)器端顯示視頻與GPS信息的功能。
這里我著重介紹本項(xiàng)目中的視頻傳輸。由于知識(shí)水平的缺乏和實(shí)驗(yàn)條件的限制，本人并沒有采取視頻壓縮算法。但針對(duì)數(shù)據(jù)量大而且3G網(wǎng)絡(luò)相對(duì)有線網(wǎng)絡(luò)帶寬限制的情況采取了措施。
硬件環(huán)境：友善之臂mini2440實(shí)驗(yàn)板（ARM9）。
操作系統(tǒng)：linux（終端）、windows7（服務(wù)器）。
網(wǎng)絡(luò)環(huán)境：WCDMA（聯(lián)通3G上網(wǎng)卡）。
Mini2440實(shí)驗(yàn)板上有CMOS攝像頭接口。同時(shí)廠家提供的linux源代碼中有攝像頭驅(qū)動(dòng)，編譯進(jìn)內(nèi)核即可使用攝像頭。攝像頭采用的是OV9650，30萬像素，在linux下作為字符串設(shè)備驅(qū)動(dòng)，可通過讀取設(shè)備文件，獲得圖像信息。
讀取攝像頭數(shù)據(jù)的代碼如下：


從攝像頭中讀取的數(shù)據(jù)格式是RGB565的，如圖所示。即紅色分量占6位，綠色分量占6位，藍(lán)色分量占5位，總共是16位。
 
為了作為bmp文件顯示，需要將RGB565轉(zhuǎn)換為RGB888（即24位真彩色）。再在文件開頭加上bmp文件頭，就成為一個(gè)完整的bmp文件了。用UDP協(xié)議傳輸這些圖像數(shù)據(jù)。在服務(wù)器端，用.NET的庫(kù)可以將接收到的BMP數(shù)據(jù)在圖形界面的指定組件上顯示。
.NET顯示圖像的代碼如下：


流程圖如下：
 
以上方案在有線網(wǎng)絡(luò)傳輸?shù)那闆r下能順利運(yùn)行，但是在3G網(wǎng)絡(luò)下圖像幾乎不能顯示。這是因?yàn)?G網(wǎng)絡(luò)的帶寬限制和UDP協(xié)議不可靠的缺點(diǎn)，數(shù)據(jù)在傳輸過程中會(huì)產(chǎn)生丟包現(xiàn)象，影響圖片質(zhì)量。對(duì)此需要改善程序代碼，增加一些措施來避免丟包：
(1) 將數(shù)據(jù)轉(zhuǎn)化的工作交給服務(wù)器。
BMP文件基本不經(jīng)過任何壓縮，每個(gè)像素點(diǎn)占用3個(gè)字節(jié)（R、G、B分量分別占用一個(gè)字節(jié)），而從CMOS攝像頭讀取的數(shù)據(jù)是RGB565的，即一個(gè)像素點(diǎn)只占用2個(gè)字節(jié)。如果說從CMOS讀取的圖像信息不經(jīng)真彩化處理，直接傳輸給服務(wù)器，這樣，需要傳輸?shù)臄?shù)據(jù)量減少了大約1/3。
(2) 減少圖像的尺寸。
從CMOS攝像頭讀取的圖像尺寸是640*512的。如果打包成BMP數(shù)據(jù)的話，總共大小是640*512*3+54(B)，大約960KB。如果說不經(jīng)真彩化處理，一幀數(shù)據(jù)總共大小是640*512*2(B)，大約640KB。正常情況下，一秒可以采集6-7幀圖像。聯(lián)通WCDMA理論的上行速率是5.76Mbps，約為720KB/s，實(shí)際情況一定低于此值。在此情況下，一秒基本上只能傳輸一幀圖像。所以減小圖片尺寸很必要?？梢钥紤]將圖片的長(zhǎng)寬都減小為原來的1/6，再在服務(wù)器端進(jìn)行真彩化處理和打包，放大為320*256的尺寸顯示。這樣，一幀RGB565的圖像的大小約為107*86*2(B)，約為18KB。這樣就足夠傳輸相應(yīng)的數(shù)據(jù)了。
(3) 分包傳輸。
UDP協(xié)議僅負(fù)責(zé)傳輸，不保證對(duì)方可靠接收，沒有擁塞控制。因此，在WCDMA這種相對(duì)來說較差的網(wǎng)絡(luò)環(huán)境下，會(huì)造成大量數(shù)據(jù)包的丟失。實(shí)驗(yàn)證明，當(dāng)一次傳輸數(shù)據(jù)量達(dá)到18KB（一幀的數(shù)據(jù)大?。r(shí)，丟包率在95%以上，這會(huì)嚴(yán)重影響圖片質(zhì)量。當(dāng)一次傳輸數(shù)據(jù)量在1-2KB時(shí)，丟包率可以降低到一定值，并保證一定的傳輸效率。
(4) 每次數(shù)據(jù)傳輸之間給與一定延時(shí)。
如果將一幀圖片分為每個(gè)1-2KB數(shù)據(jù)包來傳輸，大約要傳輸15-18次。在每次傳輸之間，如果不引入一定量的延時(shí)，同樣會(huì)造成很大量的數(shù)據(jù)包丟失。而延時(shí)的時(shí)間也是需要把握好的，一般延時(shí)500-1000ns比較合適。在傳輸每幀圖片之間，也需要給與一定的延時(shí)，此時(shí)延時(shí)時(shí)間過大的話，會(huì)造成每秒傳輸幀數(shù)過少，圖片流暢率下降，一般傳輸每幀圖片之間給予50ms的延時(shí)。
修改后的程序代碼：


以上措施可以減少UDP傳輸視頻數(shù)據(jù)的丟包率，但是，不管怎樣，UDP傳輸數(shù)據(jù)的丟包現(xiàn)象普遍存在，或多或少會(huì)有一些。在3G網(wǎng)速較差的地區(qū)，丟包率甚至還是會(huì)達(dá)到50%。視頻數(shù)據(jù)從攝像頭讀取后存放在一個(gè)無符號(hào)字符串?dāng)?shù)組里，本來是按順序分割數(shù)據(jù)進(jìn)行傳輸，由于讀取的圖像數(shù)據(jù)對(duì)應(yīng)的像素點(diǎn)分布是從左到右、從上到下排布的，如果丟包，會(huì)造成接收到的圖像的部分圖像條無法及時(shí)更新，影響肉眼觀察圖像的質(zhì)量。下面兩張圖對(duì)比了網(wǎng)絡(luò)狀況較好和較差情況下的顯示效果。
 

上圖是網(wǎng)絡(luò)狀況良好情況下的顯示效果，可以看出，顯示比較流暢，圖像質(zhì)量較好。下圖是網(wǎng)絡(luò)狀況較差情況下的顯示效果，可以看出，動(dòng)態(tài)圖像的某些圖像條未及時(shí)更新，這是由于決定該圖像條的顯示的數(shù)據(jù)包在傳輸過程中丟包。
為了降低丟包帶來的這種損失，可以考慮將每幀圖像分成多個(gè)位平面并按一定順序傳輸，每個(gè)位平面代表所有像素的同一位組成的二值圖像。如下圖所示，是每個(gè)位平面?zhèn)鬏數(shù)捻樞颍◤?開始計(jì)數(shù)）。
 
實(shí)驗(yàn)證明，每一幀分包傳輸后，靠前面的數(shù)據(jù)包丟包率比較小，而每個(gè)顏色分量的最高位對(duì)圖片色彩質(zhì)量的影響最大，位數(shù)越低，對(duì)圖像色彩質(zhì)量的影響越小。所以即便后面的位平面數(shù)據(jù)沒有接收到，對(duì)圖片色彩質(zhì)量的影響也不會(huì)很大。將RGB每種顏色分量的位數(shù)按照從最高到最低的順序進(jìn)行傳輸，每種顏色分量對(duì)應(yīng)的位平面穿插進(jìn)行傳輸，于是就采用了上圖所示的順序。由于RGB565格式的數(shù)據(jù)每個(gè)像素共16位，一幀圖片總共需要分16個(gè)位平面數(shù)據(jù)包傳輸。為了服務(wù)器能夠正確進(jìn)行圖片數(shù)據(jù)的組裝，在傳輸之前，將每個(gè)位平面數(shù)據(jù)包的最前面加上該包傳輸順序的值，如下圖所示。
 
終端部分代碼如下：


在服務(wù)器端，用如下函數(shù)進(jìn)行數(shù)據(jù)的重組，同時(shí)進(jìn)行真彩化處理（C#.NET語言）：



如上圖所示，是在改變傳輸方案后，即采用按位平面?zhèn)鬏數(shù)姆椒▊鬏敽蟮娘@示效果圖，在網(wǎng)絡(luò)良好的情況下，可以正常顯示。在網(wǎng)絡(luò)狀況較差的情況下，圖像顏色質(zhì)量會(huì)下降，而且會(huì)不穩(wěn)定地變化。但是部分圖像條不顯示的情況就不再出現(xiàn)。
總結(jié)：此方案重在聯(lián)系，實(shí)際工程中肯定不會(huì)采取此方案，還是有必要學(xué)習(xí)視頻壓縮算法及其在linux上的移植。

最新評(píng)論