這是我本科的畢業設計。時隔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上的移植。
