主頁 > 知識(shí)庫 > 基于嵌入式linux 3G下的無壓縮視頻傳輸

基于嵌入式linux 3G下的無壓縮視頻傳輸

熱門標(biāo)簽:聯(lián)客智能語音外呼系統(tǒng)賬號(hào)格式 長(zhǎng)沙智能外呼系統(tǒng)中心 南寧智能外呼系統(tǒng)線路商 成都移動(dòng)外呼系統(tǒng) 美圖手機(jī) 佛山外呼系統(tǒng)平臺(tái) 電銷機(jī)器人的效果 長(zhǎng)春外呼系統(tǒng)價(jià)格 南昌語音外呼系統(tǒng)代理
這是我本科的畢業(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ù)的代碼如下

復(fù)制代碼
代碼如下:

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位,藍(lán)色分量占5位,總共是16位。
 
為了作為bmp文件顯示,需要將RGB565轉(zhuǎn)換為RGB888(即24位真彩色)。再在文件開頭加上bmp文件頭,就成為一個(gè)完整的bmp文件了。用UDP協(xié)議傳輸這些圖像數(shù)據(jù)。在服務(wù)器端,用.NET的庫可以將接收到的BMP數(shù)據(jù)在圖形界面的指定組件上顯示。
.NET顯示圖像的代碼如下

復(fù)制代碼
代碼如下:

// st是一個(gè)已經(jīng)建立的MemoryStream對(duì)象,bmp_data是bmp數(shù)據(jù)(byte數(shù)組),bmpSize是BMP圖像大?。▎挝皇荁)。
st.Write(bmp_data, 0, bmpSize);
try
{
picBox.Image = Image.FromStream(st);//picBox是已經(jīng)建立的PictureBox對(duì)象,呈現(xiàn)在圖形界面上
}
catch (Exception e)
{
richTextBox2.Text += "error\n";//如果BMP數(shù)據(jù)錯(cuò)誤,則輸出如下錯(cuò)誤
}
//st對(duì)象清空
st.SetLength(0);
st.Position = 0;
st.Flush();

流程圖如下
 
以上方案在有線網(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í)。
修改后的程序代碼

復(fù)制代碼
代碼如下:

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);//給與一定的延時(shí)
}
printf("One picture sended!\n");//一幀傳輸完畢
usleep(100000);
}
else{
printf("Error\n");
}

以上措施可以減少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ù)包的最前面加上該包傳輸順序的值,如下圖所示。
 
終端部分代碼如下

復(fù)制代碼
代碼如下:

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ù)首個(gè)字節(jié)設(shè)為順序號(hào)
for(j=0;j9202;j++)
{
//每個(gè)像素按位分位平面數(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);//傳輸每個(gè)數(shù)據(jù)包之間的延時(shí)
}
printf("One picture sended!\n");//傳輸每幀圖像之間的延時(shí)
usleep(100000);

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

復(fù)制代碼
代碼如下:

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次,逐位進(jìn)行數(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ì)量會(huì)下降,而且會(huì)不穩(wěn)定地變化。但是部分圖像條不顯示的情況就不再出現(xiàn)。
總結(jié):此方案重在聯(lián)系,實(shí)際工程中肯定不會(huì)采取此方案,還是有必要學(xué)習(xí)視頻壓縮算法及其在linux上的移植。

標(biāo)簽:南陽 綿陽 南京 武漢 陽泉 開封 黔南 莆田

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《基于嵌入式linux 3G下的無壓縮視頻傳輸》,本文關(guān)鍵詞  基于,嵌入式,linux,下,的,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《基于嵌入式linux 3G下的無壓縮視頻傳輸》相關(guān)的同類信息!
  • 本頁收集關(guān)于基于嵌入式linux 3G下的無壓縮視頻傳輸?shù)南嚓P(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章