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

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){ 
/*視頻數據處理與傳輸的代碼*/ 
} 
else{ 
printf("CAMERA Error!\n"); 
} 
} 
close(cam_fd); 

從攝像頭中讀取的數據格式是RGB565的，如圖所示。即紅色分量占6位，綠色分量占6位，藍色分量占5位，總共是16位。 

 
為了作為bmp文件顯示，需要將RGB565轉換為RGB888（即24位真彩色）。再在文件開頭加上bmp文件頭，就成為一個完整的bmp文件了。用UDP協議傳輸這些圖像數據。在服務器端，用.NET的庫可以將接收到的BMP數據在圖形界面的指定組件上顯示。 
.NET顯示圖像的代碼如下： 

// st是一個已經建立的MemoryStream對象，bmp_data是bmp數據（byte數組）,bmpSize是BMP圖像大小（單位是B）。 
st.Write(bmp_data, 0, bmpSize); 
try 
{ 
picBox.Image = Image.FromStream(st);//picBox是已經建立的PictureBox對象，呈現在圖形界面上 
} 
catch (Exception e) 
{ 
richTextBox2.Text += "error\n";//如果BMP數據錯誤，則輸出如下錯誤 
} 
//st對象清空 
st.SetLength(0); 
st.Position = 0; 
st.Flush(); 

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

count=read(fd,cam_data,WIDTH*HEIGHT*2);//縮小圖片大小，data_buf為原圖像數據，cam_data為縮小后的圖像數據，兩者都為字符數組類型 
if(count==WIDTH*HEIGHT*2){ 
shrink(data_buf,cam_data,WIDTH,HEIGHT); 
for(i=0;i<30;i++){ 
//用UDP分包傳輸圖像數據 
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傳輸視頻數據的丟包率，但是，不管怎樣，UDP傳輸數據的丟包現象普遍存在，或多或少會有一些。在3G網速較差的地區，丟包率甚至還是會達到50%。視頻數據從攝像頭讀取后存放在一個無符號字符串數組里，本來是按順序分割數據進行傳輸，由于讀取的圖像數據對應的像素點分布是從左到右、從上到下排布的，如果丟包，會造成接收到的圖像的部分圖像條無法及時更新，影響肉眼觀察圖像的質量。下面兩張圖對比了網絡狀況較好和較差情況下的顯示效果。 
 

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

shrink(data_buf,cam_data,WIDTH,HEIGHT);//縮小圖片大小，data_buf為原圖像數據，cam_data為縮小后的圖像數據，兩者都為字符數組類型 
for(i=0;i<16;i++) 
{ 
bzero(cut_buf,1152); 
cut_buf[0]=(uchar)i;//將要傳輸的數據首個字節設為順序號 
for(j=0;j<9202;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);//發送數據 
usleep(1000);//傳輸每個數據包之間的延時 
} 
printf("One picture sended!\n");//傳輸每幀圖像之間的延時 
usleep(100000); 

在服務器端，用如下函數進行數據的重組，同時進行真彩化處理（C#.NET語言）： 

private void picDataCopy(byte[] bBuf,byte[] bData) //bBuf為接收到的數據，bData是重組后的數據存放的數組 
{ 
int index=bBuf[0]; 
for (int i = 0; i < 9202;i++ )//循環9202次，逐位進行數據的重組 
{ 
if(index<15){ 
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); 
} 
} 
} 

如上圖所示，是在改變傳輸方案后，即采用按位平面傳輸的方法傳輸后的顯示效果圖，在網絡良好的情況下，可以正常顯示。在網絡狀況較差的情況下，圖像顏色質量會下降，而且會不穩定地變化。但是部分圖像條不顯示的情況就不再出現。 
總結：此方案重在聯系，實際工程中肯定不會采取此方案，還是有必要學習視頻壓縮算法及其在linux上的移植。