這是我本科的畢業(yè)設(shè)計。時隔5個月，再次回顧一下。
本課題研究嵌入式系統(tǒng)在數(shù)據(jù)采集，3G無線通信方面的應(yīng)用，開發(fā)集視頻采集、地理信息采集、無線傳輸、客戶機/服務(wù)器模式于一體的車載終端，實現(xiàn)終端采集視頻與GPS信息的傳輸，支持服務(wù)器端顯示視頻與GPS信息的功能。
這里我著重介紹本項目中的視頻傳輸。由于知識水平的缺乏和實驗條件的限制，本人并沒有采取視頻壓縮算法。但針對數(shù)據(jù)量大而且3G網(wǎng)絡(luò)相對有線網(wǎng)絡(luò)帶寬限制的情況采取了措施。
硬件環(huán)境：友善之臂mini2440實驗板（ARM9）。
操作系統(tǒng)：linux（終端）、windows7（服務(wù)器）。
網(wǎng)絡(luò)環(huán)境：WCDMA（聯(lián)通3G上網(wǎng)卡）。
Mini2440實驗板上有CMOS攝像頭接口。同時廠家提供的linux源代碼中有攝像頭驅(qū)動，編譯進內(nèi)核即可使用攝像頭。攝像頭采用的是OV9650，30萬像素，在linux下作為字符串設(shè)備驅(qū)動，可通過讀取設(shè)備文件，獲得圖像信息。
讀取攝像頭數(shù)據(jù)的代碼如下：
int camdata_count;
int cam_fd=open("/dev/camera",O_RDONLY);
printf("Camera init!\n");
while(1){
camdata_count=read(cam_fd,cam_data,640*512*2);
if(camdata_count==640*512*2){
/*視頻數(shù)據(jù)處理與傳輸?shù)拇a*/
}
else{
printf("CAMERA Error!\n");
}
}
close(cam_fd);
從攝像頭中讀取的數(shù)據(jù)格式是RGB565的，如圖所示。即紅色分量占6位，綠色分量占6位，藍色分量占5位，總共是16位。
為了作為bmp文件顯示，需要將RGB565轉(zhuǎn)換為RGB888（即24位真彩色）。再在文件開頭加上bmp文件頭，就成為一個完整的bmp文件了。用UDP協(xié)議傳輸這些圖像數(shù)據(jù)。在服務(wù)器端，用.NET的庫可以將接收到的BMP數(shù)據(jù)在圖形界面的指定組件上顯示。
.NET顯示圖像的代碼如下：
// st是一個已經(jīng)建立的MemoryStream對象，bmp_data是bmp數(shù)據(jù)（byte數(shù)組）,bmpSize是BMP圖像大小（單位是B）。
st.Write(bmp_data, 0, bmpSize);
try
{
picBox.Image = Image.FromStream(st);//picBox是已經(jīng)建立的PictureBox對象，呈現(xiàn)在圖形界面上
}
catch (Exception e)
{
richTextBox2.Text += "error\n";//如果BMP數(shù)據(jù)錯誤，則輸出如下錯誤
}
//st對象清空
st.SetLength(0);
st.Position = 0;
st.Flush();
流程圖如下：
以上方案在有線網(wǎng)絡(luò)傳輸?shù)那闆r下能順利運行，但是在3G網(wǎng)絡(luò)下圖像幾乎不能顯示。這是因為3G網(wǎng)絡(luò)的帶寬限制和UDP協(xié)議不可靠的缺點，數(shù)據(jù)在傳輸過程中會產(chǎn)生丟包現(xiàn)象，影響圖片質(zhì)量。對此需要改善程序代碼，增加一些措施來避免丟包：
(1) 將數(shù)據(jù)轉(zhuǎn)化的工作交給服務(wù)器。
BMP文件基本不經(jīng)過任何壓縮，每個像素點占用3個字節(jié)（R、G、B分量分別占用一個字節(jié)），而從CMOS攝像頭讀取的數(shù)據(jù)是RGB565的，即一個像素點只占用2個字節(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，實際情況一定低于此值。在此情況下，一秒基本上只能傳輸一幀圖像。所以減小圖片尺寸很必要?？梢钥紤]將圖片的長寬都減小為原來的1/6，再在服務(wù)器端進行真彩化處理和打包，放大為320*256的尺寸顯示。這樣，一幀RGB565的圖像的大小約為107*86*2(B)，約為18KB。這樣就足夠傳輸相應(yīng)的數(shù)據(jù)了。
(3) 分包傳輸。
UDP協(xié)議僅負責傳輸，不保證對方可靠接收，沒有擁塞控制。因此，在WCDMA這種相對來說較差的網(wǎng)絡(luò)環(huán)境下，會造成大量數(shù)據(jù)包的丟失。實驗證明，當一次傳輸數(shù)據(jù)量達到18KB（一幀的數(shù)據(jù)大?。r，丟包率在95%以上，這會嚴重影響圖片質(zhì)量。當一次傳輸數(shù)據(jù)量在1-2KB時，丟包率可以降低到一定值，并保證一定的傳輸效率。
(4) 每次數(shù)據(jù)傳輸之間給與一定延時。
如果將一幀圖片分為每個1-2KB數(shù)據(jù)包來傳輸，大約要傳輸15-18次。在每次傳輸之間，如果不引入一定量的延時，同樣會造成很大量的數(shù)據(jù)包丟失。而延時的時間也是需要把握好的，一般延時500-1000ns比較合適。在傳輸每幀圖片之間，也需要給與一定的延時，此時延時時間過大的話，會造成每秒傳輸幀數(shù)過少，圖片流暢率下降，一般傳輸每幀圖片之間給予50ms的延時。
修改后的程序代碼：
count=read(fd,cam_data,WIDTH*HEIGHT*2);//縮小圖片大小，data_buf為原圖像數(shù)據(jù)，cam_data為縮小后的圖像數(shù)據(jù)，兩者都為字符數(shù)組類型
if(count==WIDTH*HEIGHT*2){
shrink(data_buf,cam_data,WIDTH,HEIGHT);
for(i=0;i30;i++){
//用UDP分包傳輸圖像數(shù)據(jù)
sendto(sockfd,data_buf+(i*32768),32768,0,(struct sockaddr *)addr,len);
usleep(2000);//給與一定的延時
}
printf("One picture sended!\n");//一幀傳輸完畢
usleep(100000);
}
else{
printf("Error\n");
}
以上措施可以減少UDP傳輸視頻數(shù)據(jù)的丟包率，但是，不管怎樣，UDP傳輸數(shù)據(jù)的丟包現(xiàn)象普遍存在，或多或少會有一些。在3G網(wǎng)速較差的地區(qū)，丟包率甚至還是會達到50%。視頻數(shù)據(jù)從攝像頭讀取后存放在一個無符號字符串數(shù)組里，本來是按順序分割數(shù)據(jù)進行傳輸，由于讀取的圖像數(shù)據(jù)對應(yīng)的像素點分布是從左到右、從上到下排布的，如果丟包，會造成接收到的圖像的部分圖像條無法及時更新，影響肉眼觀察圖像的質(zhì)量。下面兩張圖對比了網(wǎng)絡(luò)狀況較好和較差情況下的顯示效果。
上圖是網(wǎng)絡(luò)狀況良好情況下的顯示效果，可以看出，顯示比較流暢，圖像質(zhì)量較好。下圖是網(wǎng)絡(luò)狀況較差情況下的顯示效果，可以看出，動態(tài)圖像的某些圖像條未及時更新，這是由于決定該圖像條的顯示的數(shù)據(jù)包在傳輸過程中丟包。
為了降低丟包帶來的這種損失，可以考慮將每幀圖像分成多個位平面并按一定順序傳輸，每個位平面代表所有像素的同一位組成的二值圖像。如下圖所示，是每個位平面?zhèn)鬏數(shù)捻樞颍◤?開始計數(shù)）。
實驗證明，每一幀分包傳輸后，靠前面的數(shù)據(jù)包丟包率比較小，而每個顏色分量的最高位對圖片色彩質(zhì)量的影響最大，位數(shù)越低，對圖像色彩質(zhì)量的影響越小。所以即便后面的位平面數(shù)據(jù)沒有接收到，對圖片色彩質(zhì)量的影響也不會很大。將RGB每種顏色分量的位數(shù)按照從最高到最低的順序進行傳輸，每種顏色分量對應(yīng)的位平面穿插進行傳輸，于是就采用了上圖所示的順序。由于RGB565格式的數(shù)據(jù)每個像素共16位，一幀圖片總共需要分16個位平面數(shù)據(jù)包傳輸。為了服務(wù)器能夠正確進行圖片數(shù)據(jù)的組裝，在傳輸之前，將每個位平面數(shù)據(jù)包的最前面加上該包傳輸順序的值，如下圖所示。
終端部分代碼如下：
shrink(data_buf,cam_data,WIDTH,HEIGHT);//縮小圖片大小，data_buf為原圖像數(shù)據(jù)，cam_data為縮小后的圖像數(shù)據(jù)，兩者都為字符數(shù)組類型
for(i=0;i16;i++)
{
bzero(cut_buf,1152);
cut_buf[0]=(uchar)i;//將要傳輸?shù)臄?shù)據(jù)首個字節(jié)設(shè)為順序號
for(j=0;j9202;j++)
{
//每個像素按位分位平面數(shù)據(jù)包
cut_buf[j/8+1]|=(uchar)(((uchar)(data_buf[j]>>bit_index(i))0x01)(j%8));
}
sendto(sockfd,cut_buf,1152,0,(struct sockaddr *)cam_addr,sockaddr_len);//發(fā)送數(shù)據(jù)
usleep(1000);//傳輸每個數(shù)據(jù)包之間的延時
}
printf("One picture sended!\n");//傳輸每幀圖像之間的延時
usleep(100000);
在服務(wù)器端，用如下函數(shù)進行數(shù)據(jù)的重組，同時進行真彩化處理（C#.NET語言）：
private void picDataCopy(byte[] bBuf,byte[] bData) //bBuf為接收到的數(shù)據(jù)，bData是重組后的數(shù)據(jù)存放的數(shù)組
{
int index=bBuf[0];
for (int i = 0; i 9202;i++ )//循環(huán)9202次，逐位進行數(shù)據(jù)的重組
{
if(index15){
bData[3*i + 2 - (index%3)] |=
(byte)(((bBuf[i/8 + 1] >> (i%8)) 0x01) (7 - index/3));
}
else if(index==15){
bData[3*i+1]|=
(byte)(((bBuf[i/8 + 1] >> (i%8)) 0x01) 2);
}
}
}
如上圖所示，是在改變傳輸方案后，即采用按位平面?zhèn)鬏數(shù)姆椒▊鬏敽蟮娘@示效果圖，在網(wǎng)絡(luò)良好的情況下，可以正常顯示。在網(wǎng)絡(luò)狀況較差的情況下，圖像顏色質(zhì)量會下降，而且會不穩(wěn)定地變化。但是部分圖像條不顯示的情況就不再出現(xiàn)。
總結(jié)：此方案重在聯(lián)系，實際工程中肯定不會采取此方案，還是有必要學習視頻壓縮算法及其在linux上的移植。
