嵌入式gprs遠程無線視頻監(jiān)控系統(tǒng)論文-資料下載頁

　　

【正文】 決定，當(dāng)它設(shè)置成一1時，XviD系統(tǒng)自動選擇當(dāng)前編碼是否為I幀或P幀。當(dāng)網(wǎng)絡(luò)狀況比較良好時(丟包數(shù)較少)，可以適當(dāng)減少I幀數(shù)量，這樣可以提高服務(wù)質(zhì)量。當(dāng)網(wǎng)絡(luò)丟包率上升時，就要考慮增加I幀數(shù)量，這樣可以更快更好地修正、掩蓋錯誤。本章首先介紹了嵌入式Linux下利用USB攝像頭實現(xiàn)視頻采集的方法，然后介紹了圖像識別報警子系統(tǒng)的設(shè)計與實現(xiàn)，提出了基于邊緣的背景去除的圖像識別算法并給出了報警郵件發(fā)送的原理與實現(xiàn)，音頻采集驅(qū)動的設(shè)計與實現(xiàn)，給出了圖像JPEG和MPEG4的視頻壓縮的設(shè)計步驟，并通過Linux下多線程程序的設(shè)計方法完成多個模塊設(shè)計。 第五章網(wǎng)絡(luò)視頻傳輸模塊軟件設(shè)計數(shù)據(jù)在網(wǎng)絡(luò)上傳輸需要遵守一定的網(wǎng)絡(luò)協(xié)議，數(shù)據(jù)的類型決定了網(wǎng)絡(luò)協(xié)議的選取。針對網(wǎng)絡(luò)上傳輸視頻等實時數(shù)據(jù)的需要，電信業(yè)和計算機業(yè)許多國際組織進行許多標(biāo)準(zhǔn)化的工作，現(xiàn)在較為關(guān)鍵的協(xié)議有RTP/RTCP, RTSP等。在TCP/IP參考模型中，傳輸層通信協(xié)議TCP和UDP都不能滿足流媒體傳輸?shù)腝oS要求。TCP協(xié)議采用滑動窗口控制機制，數(shù)據(jù)傳輸隨著流控窗口動態(tài)的啟動和關(guān)閉，加上TCP重傳造成的時延，使其難以滿足流媒體實時的傳送要求。UDP協(xié)議的無連接特點能夠提高傳輸速率，雖然可以在某種程度上滿足流媒體的實時性要求，但是由于其沒有提供擁塞控制和質(zhì)量保證機制，也無法滿足流媒體傳輸?shù)男枰榱藢崿F(xiàn)流媒體在IP上的實時傳送播放，需要在傳輸層協(xié)議((TCP/UDP)和應(yīng)用層之間增加一個通信控制層。在增加的通信控制層，采用相應(yīng)的實時傳輸協(xié)議，主要有:數(shù)據(jù)流部分的實時傳輸協(xié)議RTP(Realtime Transport Protocol)，用于控制部分的實時傳輸控制協(xié)議RTCP(Realtime Transport Control Protocol)，實時流協(xié)議RTSP(RealtimeStreaming Protocol)。下圖是整個監(jiān)控系統(tǒng)所涉及到的協(xié)議以及相互關(guān)系。圖5. 1流媒體傳輸控制協(xié)議棧(1)RTP/RTCP協(xié)議簇實時傳輸協(xié)議RTP(Realtime Transport Protocol)是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。通常RTP算法并不作為一個獨立的網(wǎng)絡(luò)層來實現(xiàn)，而是作為應(yīng)用程序代碼的一部分。實時傳輸控制協(xié)議RTCP(RealtimeTransport Control Protocol)和RTP一起提供流量控制和擁塞控制服務(wù)。在RTP會話期間，各參與者周期性地傳送RTCP包[f2}10(2)實時流協(xié)議RTSP實時流協(xié)議RTSP(Realtime Streaming Protocol)是應(yīng)用級協(xié)議，用于控制具有實時特性的數(shù)據(jù)傳輸，它提供一個可擴展的框架，以使諸如音頻和視頻之類的實時媒體的點播傳輸成為可能[28]。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TC39。,P或RTP完成數(shù)據(jù)傳輸。圖5. 2流媒體傳輸功能框圖監(jiān)控系統(tǒng)是在傳輸層協(xié)議((TCP,UDP)上解釋RTP, RTCP, RTSP協(xié)議的，所有的客戶連接請求都是以TCP的端口獲得的，流媒體數(shù)據(jù)也都是打成RTP包，通過UDP端口發(fā)出去的。當(dāng)監(jiān)控系統(tǒng)面對一個單一的客戶，完成的過程如下:(1)在客戶端發(fā)出RTSP連接請求后，服務(wù)器通過對TCP端口的監(jiān)聽，讀入請求。(2)解析請求內(nèi)容，調(diào)入相應(yīng)的流媒體文件。(3)形成RTP包，分發(fā)數(shù)據(jù)流包，獲得RTCP包。(4)數(shù)據(jù)包發(fā)送完畢，關(guān)閉連接。 RTP/RTCP協(xié)議分析與實現(xiàn)5. 2. 1 R丁P協(xié)議分析一個RTP數(shù)據(jù)包包括一個12個字節(jié)的固定RTP數(shù)據(jù)頭，參與源表示符和擴展頭是可選的。:圖5. 3 RTP包格式版本((v, 2bit):這個域標(biāo)識RTP的版本。RFC3550定義的版本是20填充位((p, lbit):表明有一個或多個不是載荷數(shù)據(jù)的填充字節(jié)在包尾，最后一個填充字節(jié)包含了填充字節(jié)的個數(shù)。擴展位((x, 1 bit):在固定頭后面接著一個擴展頭。擴展機制能夠應(yīng)用于傳遞控制信息，而不需要中間節(jié)點的解釋。RTP擴展報頭是兩個字節(jié)，包含一個右對齊的16比特長度的域，指示擴展的長度。它必須在標(biāo)準(zhǔn)RTP報頭(后面會看到，要么是SSRC項，要么是CSRS項)的最后一個有效域之后插入。CSRC源記數(shù)(CC, 4bit): CSRC是在固定報頭后CSRC標(biāo)識符的數(shù)目。這個數(shù)值用于來支持混合器的“混合”功能。混合器從多個信源收集多媒體流，把它們合并成為一個包，然后轉(zhuǎn)發(fā)到目的地。標(biāo)記位(M, 1 bit):標(biāo)一記的解釋是由配置來定義的。它可以用來在包流中標(biāo)記重要事件，比如幀邊界。配置可以定義另外的標(biāo)記位，或者通過改變有效載荷類型域中的比特數(shù)來代替使用標(biāo)記位。M比特位意味著談話的突然開始或者圖像幀的結(jié)束。有效載荷類型((PT, 7bit):這個域標(biāo)志RTP有效載荷類型的格式，并且決定應(yīng)用程序?qū)λ慕忉尅Ｐ蛄芯幪?sequence number, 16bit):序列編號起始為一個隨機數(shù)，每發(fā)送一個RTP包，序列編號加一。它可被接收者用于檢測包丟失和恢復(fù)包順序。時間戳(timestamp, 32bit):時間戳是在RTP數(shù)據(jù)包的第一個字節(jié)采樣時刻。采樣時刻必須隨時間單調(diào)線形增加，以允許同步和抖動計算。時鐘分辨率必須滿足要求的同步精確度，以及對包到達抖動的測量，并且可以分接成端到端延遲的分辨率。時鐘頻率與作為載荷攜帶的數(shù)據(jù)格式無關(guān)。對于周期性發(fā)送RTP包而言，采樣時刻是由采樣時鐘確定的。如果一個應(yīng)用每讀入一個數(shù)據(jù)塊要占據(jù)n個采樣周期，則無論數(shù)據(jù)塊被發(fā)送或丟棄，每個時間戳標(biāo)記都增加no同步源SSRC(32bit): SSRC標(biāo)志同步信源，數(shù)值是隨機選取的，且在同一個RTP會話中沒有兩個發(fā)送者的SSRC標(biāo)識相同。參與源CSRC列表((0} 15項，每項32bit): CSRC列表標(biāo)識提供這個包中包含的所有有效載荷的信源。標(biāo)識符的數(shù)量是由CC域確定的。CSRC標(biāo)識符僅在通過混合器時插入。當(dāng)端點發(fā)出有效載荷時，CSRC域用來對信源標(biāo)識進行更正。5. 2. 2 RTCP協(xié)議分析在RFC3550中說明的和RTP相配的控制協(xié)議是RTCPoRTCP包把關(guān)于會話質(zhì)量的端到端信息傳送給每個參與者。像包延遲、抖動、收到和包丟失等數(shù)值對網(wǎng)絡(luò)而言非常有價值，可以用來實時估計網(wǎng)絡(luò)自身的狀態(tài)。有5種類型的RTCP包:SR: Sender Report，發(fā)送者報告RR: Receiver Report，接收者報告SDES : Source DEScription，信源說明BYE: Hang up from a session，掛斷會話APP: ApplicationSpecific acket，特定應(yīng)用的包系統(tǒng)中，并不是5種RTCP報文都必須實現(xiàn)，其中SDES報文主要功能是作為媒體會話成員標(biāo)識信息的載體，此報文的功能在本視頻傳輸方案中是多余的，另外，APP報文目的是測試新開發(fā)的應(yīng)用和特征，這里也不實現(xiàn)。本系統(tǒng)實現(xiàn)三個報文:發(fā)送者報文SR、接收者報文RR和結(jié)束會話BYE報文。RTCP報文由公共報頭部分和結(jié)構(gòu)化的內(nèi)容組成，報文內(nèi)容根據(jù)報文類型的不同而具有不同的長度，一般以犯位為邊界。這里先對SR報文加以說明。SR報文一般由三部分組成:RTCP公共報頭、發(fā)送者信息和接收者報告塊。，未采用RTCP標(biāo)準(zhǔn)包中的P, SC等域，也未采用標(biāo)準(zhǔn)SR報文格式中的第三部分接收者信息部分。 sR報文格式(1) RTCP公共報頭部分.V:版本號，2bit，當(dāng)前版本為2。.P:填充標(biāo)志，lbit，如果填充標(biāo)志為1，則在單一報文中尾部填充八位組。.RC:接收報告計數(shù)，Sbit，指出接收報告的塊的個數(shù)。.PT:報文類型，8bit,SR類型為200。.報文長度:16bit,RTCP報文長度減1，包括報頭和填充，以32位為單位。.SSRC標(biāo)識符:32bit，發(fā)送該SR報文的同步信源標(biāo)識符。(2)發(fā)送者信息部分.NTP時戳:64bit，指出該SR報文發(fā)送時的全局網(wǎng)絡(luò)時間。.RTP時戳:32bit，和NTP時戮一致的時間，但必須和RTP報文中的時戳保持相同的時間單位。.發(fā)送者報文計數(shù):32bit，發(fā)送者從開始傳送RTP報文到該SR報文產(chǎn)生的時間間隔內(nèi)共發(fā)送的RTP報文總數(shù)。.發(fā)送者有效載荷字節(jié)計數(shù):32bit，發(fā)送者從開始傳送RTP報文到該SR報文產(chǎn)生的時間間隔內(nèi)共發(fā)送的有效載荷總數(shù)，字節(jié)為單位。RR報文和SR報文格式基本相同，只是RR報文不包括SR報文格式中的第二部分，即發(fā)送者信息部分，報文類型PT=201 o BYE報文格式更簡單，它是RTCP公共報頭部分，即SR中的第一部分，加上一個32位數(shù)據(jù)，在程序中填充的是IP地址，通知對方此IP要退出會話，BYE報文的類型值PT =203。5. RTP/RTCP協(xié)議的軟件設(shè)計與實現(xiàn)根據(jù)前面介紹的RTP/RTCP協(xié)議的報頭結(jié)構(gòu)，這里給出它的程序?qū)崿F(xiàn)。RTP協(xié)議的代碼可以分為四類:與協(xié)議相關(guān)的數(shù)據(jù)結(jié)構(gòu)、處理傳入和發(fā)送RTP數(shù)據(jù)分組的代碼、處理接收和傳輸RTCP報文的代碼以及常用工具函數(shù)。具體的代碼及其說明如下:首先給出RTP報頭結(jié)構(gòu)和接收發(fā)送端的數(shù)據(jù)結(jié)構(gòu)。struct RTP一ead刊RTP報頭結(jié)構(gòu)。 unsigned int rtpwe ver。//協(xié)議版本字段，2bit。 unsigned int rtp}ad。//填充標(biāo)志，lbit。 unsigned int rtp_ ext。//擴展標(biāo)志lbit。 unsigned int rtp_cc。//CSRC計數(shù)器，Obit。 unsigned int rtp_mark。//標(biāo)記，lbit。 unsigned int rtp payload。//有效載荷類型，7bit。 unsigned short rtp_ seq。//序列號，16bit。 unsigned int rtpes timestamp。//時間戳，32bit。 unsigned int rtp_ssrc。//同步信源標(biāo)識符，32bit。 unsigned int rtp_csrc。//特約信源標(biāo)識符，32bit。}。struct RTPes RECV {//接收端數(shù)據(jù)包數(shù)據(jù)結(jié)構(gòu)。 unsigned int rtpes rec len。//數(shù)據(jù)包總長度，按字節(jié)計數(shù)。 unsigned int rtpee rec seq。//擴展序列號，防止序列號溢出。 struct RTPee RECV *next。//指向下一個序列號低于本數(shù)據(jù)包序列號的報文。 struct RTP_RECV *prev。//指向下一個序列號高于本數(shù)據(jù)包序列號的報文。 struct RTP一 HEAD rtpes rec。//RTP數(shù)據(jù)包。}。struct RTP_SEND{//發(fā)送方的數(shù)據(jù)包數(shù)據(jù)結(jié)構(gòu)和接收端數(shù)據(jù)結(jié)構(gòu)必須具有相同的結(jié)構(gòu)類型，即其內(nèi)的變量類型和順序要一致 unsigned int rtp_sendto len。 unsigned int send seq。 struct RTP_ SEND *next。 struct RTP_ SEND *prev。 struct RTPes HEAD rtpes send。}。下面給出RTCP公共報文格式數(shù)據(jù)結(jié)構(gòu)、SR數(shù)據(jù)結(jié)構(gòu)和RR數(shù)據(jù)結(jié)構(gòu)。在SR和RR數(shù)據(jù)結(jié)構(gòu)中不再定義公共字段，組成完整的符合協(xié)議要求的RTCP報文。對于BYE報文，則不單獨實現(xiàn)它的數(shù)據(jù)結(jié)構(gòu)，而是用一個RTCP公共報文加上一個要求結(jié)束會話端的IP地址的方式，在專門的函數(shù)中實現(xiàn)。/*RTCP協(xié)議公共報頭*/struct RTCP Head{ unsigned int RTCPwe Ver。 unsigned int RTCP_Pad。 unsigned int RTCP_Count。 unsigned char RTCP Type。 unsigned short RTCP一 Length。 unsigned int RTCP_SSRC。}。/*發(fā)送者報文SR*/struct RTCP SR Head{ long double RTCP一TP。 unsigned int RTCPes RTP_ Stamp。 unsigned int RTCP_ Sendes Pack Count。 unsigned int RTCP_ Sendes Data一 Count。 unsigned int RTCP SSRC l。 unsigned int RTCP工ostes Rate。 unsigned int RTCP_ Lost Total。 unsigned int RTCP~ Max_ Seq。 unsigned int RTCP_ Timees Delay。 unsigned int RTCP LSR。 unsigned int RTCP DLSR。 unsigned int RTCP_ SSRC_2。}。數(shù)據(jù)結(jié)構(gòu)設(shè)計完后，就可以根據(jù)協(xié)議編寫相關(guān)函數(shù)了，核心函數(shù)有:(1)void RTP Init (unsigned int,int)。 RTPes Init C)先把保存會話信息的數(shù)據(jù)結(jié)構(gòu)清零，接著便創(chuàng)建一個分組緩沖池以及線程所使用的必要的條件變量和互斥量，并啟動兩個線程，一個用于處理傳入的RTP分組，另一個用于處理傳入的RTCP分組。(2)void RTP Packet HEAD(struct RTP_HEAD*)。該函數(shù)初始化一個RTP包，填充包信息。(3)void RTP一acket MPEG4(struct