【正文】 中各個數(shù)據(jù)域的描述如下：(1)協(xié)議版本號(V)：2 bit這個域指定了RTP協(xié)議的版本號。如果使用RFC3550，則該域被指定為2。(2)填充標記(P)：l bit如果這個域被置為l，則這個RTP數(shù)據(jù)包的尾部包含了一個或多個額外的填充字節(jié)，這些字節(jié)并不是載荷的一部分。填充字節(jié)的最后一個字節(jié)指定了填充字節(jié)的個數(shù)，包括它自身在內(nèi)。填充字節(jié)可應(yīng)用于一些需要固定塊大小的加密算法，或者是用于滿足它的更低層協(xié)議數(shù)據(jù)單元的需要。(3)擴展標記(X)：l bit如果這個域被置為l，則這個RTP數(shù)據(jù)包頭的后面必須跟一個頭擴展。頭擴展的具體格式請參見相關(guān)文檔，一般不推薦使用頭擴展。(4)CSRC計數(shù)器(CC)：4 bits這個域指定了RTP包頭中的CSRC標識的個數(shù)。(5)標志位(M)：1 bit標志位的功能依賴于載荷類型PT。比如說它可以用于標識視頻數(shù)據(jù)傳輸中每幀的開始。(6)載荷類型(PT)：7 bits這個域用于標識RTP數(shù)據(jù)包內(nèi)載荷的類型，例如H．263視頻、MPEG．2音頻、JPEG等。默認的載荷類型映射由RFC3551規(guī)定。除了在RTP會話建立時指定載荷類型，發(fā)送端還可以中途決定改變視音頻的編碼方法。發(fā)送端只需要改變這個域就可以通知接收端。(7)序列號(Sequence Number)：16 bits一個RTP傳輸會話中的所有RTP數(shù)據(jù)包依次編號，這個編號就是序列號。從安全的角度考慮，序列號應(yīng)該從一個隨機數(shù)開始。每發(fā)送一個RTP數(shù)據(jù)包序列號就加l，接收端可以用它來檢查數(shù)據(jù)包是否有丟失并按順序號處理數(shù)據(jù)包。(8)時間戳(TimeStamp)：32 bits這個域用于標識RTP數(shù)據(jù)包載荷的時間信息。它反映RTP數(shù)據(jù)包中第一個字節(jié)的采樣時刻(時間)。接收端可以利用這個時問戳去除由網(wǎng)絡(luò)引起的信息包的抖動，并且在接收端為播放提供同步功能。時間單位和精度由具體應(yīng)用決定，例如，對于MPEG．2而言，時間戳的時鐘頻率為90kHz。(9)同步源標識SSRC(Synchronization SouRce Identifier)：32 bits這個域標識數(shù)據(jù)源。它用來標識RTP數(shù)據(jù)包流的起源，在RTP會話或者期間建立的每個數(shù)據(jù)包流都有一個清楚的SSRC。SSRC不是發(fā)送端的IP地址，而是在新的數(shù)據(jù)包流開始時源端隨機分配的一個號碼。在VoD系統(tǒng)中，SSRC可用于標識不同的視頻服務(wù)器。(10)貢獻源標識CSRC列表(Contributing SouRee Identifiers)：32 bits這是一個可選項，一個RTP包頭可以包含肚15個CSRC，其數(shù)目由包頭的CC域指定。這個域指定了包里載荷的貢獻源，貢獻源其實是某個SSRC。在應(yīng)用中，貢獻源標識是由混合器(Mixer)插入的。舉個例子，有來自于4個數(shù)據(jù)源的視頻數(shù)據(jù)，混合器可以把這4個視頻流的幀縮小比例，混合在一起，使其顯示在同一幀中，形成一個新的視頻數(shù)據(jù)流。新的視頻數(shù)據(jù)流的IP包中就擁有4個貢獻源標識CSRC，分別就是原來的4個視頻流的SSRC。 RTSP實時流協(xié)議RTSP(Real Time Streaming Protocol)是由Realnetworks和Netscape共同提出的，該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或RTP完成數(shù)據(jù)傳輸。HTTP與RTSP相比，HTTP傳送html超鏈接文檔，而RTP傳送的是多媒體數(shù)據(jù)。HTTP請求由客戶機發(fā)出，服務(wù)器作出響應(yīng)；使用RTSP時，客戶機和服務(wù)器都可以發(fā)出請求，即RTSP可以是雙向的。 RSVP資源預(yù)留協(xié)議(RSVP，Resource reSerVation Protocol)是正在開發(fā)中的Internet協(xié)議。針對Internet原有傳輸層協(xié)議不能保障QoS質(zhì)量和不支持多點傳輸?shù)奶攸c，RSVP在業(yè)務(wù)流傳送之前，預(yù)約一定的網(wǎng)絡(luò)資源，建立靜態(tài)或者動態(tài)的傳輸邏輯通路，保障了每一業(yè)務(wù)流都有足夠的“獨享”的帶寬，克服了由于網(wǎng)絡(luò)信包過多引起的擁塞、丟失和重傳。某些實驗性系統(tǒng)，如視頻會議工具VIC就集成了RSVP。 ,。如圖32所示，,（VCL)以及網(wǎng)絡(luò)提取層(NAL)，以便能夠適應(yīng)不同的網(wǎng)絡(luò)結(jié)構(gòu)。VCL中包括VCL編碼器與VCL解碼器，主要功能是視頻數(shù)據(jù)壓縮編碼和解碼；NAL則用于為VCL提供一個與網(wǎng)絡(luò)無關(guān)的統(tǒng)一接口,它負責對視頻數(shù)據(jù)進行封裝，經(jīng)過封裝的數(shù)據(jù)包在傳送過程中具有更好的健壯性。、UDP包頭和IP包頭，然后,IP數(shù)據(jù)包通過有線、無線傳輸網(wǎng)絡(luò)傳輸給接收端。接收端收到IP包后按相反的順序?qū)TP包頭和視頻數(shù)據(jù)提取出來，根據(jù)RTP包頭中的序列號進行排序后將視頻數(shù)據(jù)通過解碼器接口傳入解碼器，解碼器對數(shù)據(jù)進行解碼后進行播放，在解碼的過程中可能還需要進行容錯處理(如果有數(shù)據(jù)丟失）[59]。Figure32 RTP for transmission model NAL 視頻流格式NAL層產(chǎn)生的一個編碼視頻序列，由一串連續(xù)的存儲單元組成，使用同一序列參數(shù)集，見圖33。每個視頻序列可獨立解碼。編碼序列的開始是即時刷新存儲單元 （IDR）。IDR是一個I幀圖像，表示后面的圖像不用參考以前的圖像。一個NAL單元流可包含一個或更多的編碼視頻序列。圖33 NAL視頻流序列Figure33 NAL video stream sequence，規(guī)定了視頻序列的格式，NAL單元(NALU）是NAL層的基本處理單元，一個NALU是一個包含一定語法元素的可變長字節(jié)字符串，它可以攜帶一個編碼片，或者一個序列或圖像參數(shù)集。每個NALU由一個字節(jié)的頭和一個包含可變長編碼符號的字節(jié)組成。頭部含三個定長比特區(qū)：NALU類型（T），重要性指示（R）和禁止位（F）。NALU類型用5bit來代表NALU的32種不同類型。R比特用于標志在重構(gòu)過程中的重要性，值為0表示沒有用于預(yù)測參考，值越大，用于預(yù)測參考的次數(shù)越多。F比特默認為0，當網(wǎng)絡(luò)檢測到NALU 中存在比特錯誤(在無線網(wǎng)絡(luò)環(huán)境易出現(xiàn)）時，可將其置為1，主要適用于異質(zhì)網(wǎng)絡(luò)環(huán)境（如有線無線相結(jié)合的環(huán)境），見圖34。圖34 NALU結(jié)構(gòu)Figure34 NALU structure 需要對其進行打包，加入時間戳、序列號等信息。：單一模式，即把一個NALU 打入一個RTP包，主要適用于對話應(yīng)用系統(tǒng)；非交錯模式，按照編碼出來的視頻流的順序進行組包，主要適用于低延遲的實時系統(tǒng)；交錯模式，打亂編碼出來的視頻流的順序進行組包， 主要適用于對延遲要求較低的系統(tǒng)。這里采用非交錯模式和交錯模式結(jié)合的方法，對視頻流采用解碼的順序組包，可以達到實時采集、傳輸?shù)哪康?。如圖35圖35 Figure35 video streaming packet mode算法描述若當前幀組（Group Of Picture,GOP）能放入單個RTP包，就把此GOP單獨放入一個RTP包中；若放不下，則把GOP分成多個幀(Picture)，放入多個RTP包，此時須把GOP的序列參數(shù)集（Sequence Parameter Set）復(fù)制到每個RTP包，以去除包間的相關(guān)性，達到丟包的魯棒性；為減小包數(shù)，降低開銷，一包中能放入多少Picture,就盡可能多地放入多少Picture，但即使最后一個包中仍有剩余空間，也不能把另一個GOP中的Picture放入此包中；若當前RTP包放不下一個Picture，則把Picture分成多個切片（slice），放入多個RTP包，此時需把GOP的Sequence Parameter Set和Picture的圖像參數(shù)集（Sequence Parameter Set）復(fù)制到每個RTP包，以去除包間的相關(guān)性，達到丟包的魯棒性。為減小包數(shù)，降低開銷，一包中能放入多少Slice,就盡可能多地放入多少Slice， 但即使最后一個包中仍有剩余空間，也不能把另一Frame中的Slice放入此包中。Begin：設(shè)PS為去除頭部字段長度的MTU值；While（！ 遇到NAL視頻流 End of Stream 標記）{If （發(fā)現(xiàn)當前GOP的End of Sequence 標記）{If （當前分段長度=PS）{采用 Noninterleaved Mode；把此段數(shù)據(jù)打入一個RTP包；}else {回到當前GOP開始處；While（！ 當前GOP的End of Sequence 標記）{If （發(fā)現(xiàn)下一個Picture 的起始碼）{If（當前分段長度=PS）{發(fā)現(xiàn)當前Picture 的 Picture delimiter；當前分段長度+=當前Picture長度；搜索下一個Picture 起始碼；}If （此段包含Picture 數(shù)目 ==1）{采用 Noninterleaved Mode；把此段數(shù)據(jù)打入一個RTP包；}}Else {回到當前Picture開始出；While（！當前Picture的Picture delimiter標記）{當前分段長度=0；While（當前分段長度=PS amp。amp。！Picture delimiter）{發(fā)現(xiàn)當前Slice的結(jié)束符；當前分段長度 +=當前Slice長度；搜索下一個Slice起始碼；}采用Noninterleaved Mode；把此段數(shù)據(jù)打入一個RTP包；}}}}}}}End，并在此基礎(chǔ)上提出了混合模式組包算法。證明，本文提出的混合算法具有傳輸?shù)母咝院蛠G包的魯棒性，在丟包率較大的網(wǎng)絡(luò)狀況下仍獲得良好視覺質(zhì)量。 本章小結(jié)本章先是介紹了基于網(wǎng)絡(luò)的幾種傳輸協(xié)議。第4章 嵌入式視頻監(jiān)控服務(wù)器的硬件設(shè)計第4章 嵌入式視頻監(jiān)控服務(wù)器的硬件設(shè)計目前，實現(xiàn)嵌入式視頻監(jiān)控系統(tǒng)有兩種方式。一種是ARM+ASIC雙芯片的方式，由硬件ASIC處理器作為編／解碼芯片，實現(xiàn)音／視頻的硬件壓縮，如WIS公司的WIS700VWEB的V2005等。此種方法的缺點是受硬件編解碼器的制約，應(yīng)用不靈活，擴展性差；同時雙芯片之間的通信效率不高。另一種是ARM+DSP單芯片雙核處理器架構(gòu)的方式。由DSP實現(xiàn)音／視頻的壓縮，并通過開發(fā)的c64x+DSP驅(qū)動程序與ARM進行高效通信，將壓縮的音／視頻數(shù)據(jù)經(jīng)過ARM的控制發(fā)送到IP網(wǎng)絡(luò)。由于采用了ARM+DSP單芯片雙核處理器的架構(gòu)，故具有音／視頻壓縮算法編程靈活，系統(tǒng)擴展性強的特點；同時在嵌入式Linux操作系統(tǒng)的控制下，使得ARM和DSP的通信效率較高，進而提高了系統(tǒng)的運行效率以及音／視頻實時傳輸?shù)男省?嵌入式監(jiān)控服務(wù)器系統(tǒng)結(jié)構(gòu)系統(tǒng)框圖如圖41：視頻采集子系統(tǒng)系統(tǒng)控制、視頻壓縮編碼（DM6446平臺）3G傳輸系統(tǒng)圖41 系統(tǒng)框圖Figure41 System Block Diagram視頻采集子系統(tǒng)將CCD采集到的視頻圖像經(jīng)過A／D芯片轉(zhuǎn)換之后，以10位ITU—R BT．656標準的YCbCr信號輸入到TMS320DM6446(以下簡稱“DM6446”)平臺的CCD控制器；這些信號通過DM6446內(nèi)部中心交換資源(SCR)的調(diào)度存儲在ARM與DSP共享的DDR2存儲器中，經(jīng)過ARM和C64x+DSP的通信，調(diào)用C64x+DSP上H．264壓縮算法的API函數(shù)，將捕獲的原始視頻數(shù)據(jù)進行壓縮；經(jīng)過壓縮編碼的視頻流經(jīng)過RTP封包處理后，通過3G傳輸系統(tǒng)發(fā)送至3G網(wǎng)絡(luò)。 系統(tǒng)硬件設(shè)計系統(tǒng)采用TI公司的TMS320DM6446處理器作為主控制器。 DM6446處理器簡介TMS320DM6446芯片是達芬奇(Davinci)技術(shù)的杰出代表，TMS320DM6446由ARM926EJS內(nèi)核、C64x+DSP內(nèi)核、系統(tǒng)控制、視頻處理子系統(tǒng)（vpss）、電源管理、外部存儲器接口、外圍控制模塊等功能性模塊組成。ARM926EJS內(nèi)核是采用管道化流水線的32位RISC處理器，同時配備Thumb擴展，它能夠處理32位或16位的指令和8位、16位、32位的數(shù)據(jù)，它通過使用協(xié)處理器CP15和保護模塊使體系結(jié)構(gòu)得到增強，并提供數(shù)據(jù)和程序內(nèi)存管理單元(MMU）。MMU具有兩個64項的轉(zhuǎn)換旁路緩存器(TLB)用于指令和數(shù)據(jù)流，每項均可映射存儲器的段、大頁和小頁。為了保證內(nèi)核周期的存取指令和數(shù)據(jù)，提供了獨立的16K字節(jié)指令cache和8K字節(jié)數(shù)據(jù)cache，指令和數(shù)據(jù)cache都是通過VIVT四路連接,另外,還提供一個寫緩沖用于提升內(nèi)核性能，其緩沖數(shù)據(jù)容量高達17字節(jié)。C64x+,以其C64x+內(nèi)核的先進超長指令字(VLIM)結(jié)構(gòu)，獲得當前應(yīng)用設(shè)備所需要的極高性能[56]。DM6446有著豐富的資源和強大的特性，主要具有以下結(jié)構(gòu)特點：高性能。采用低功耗、高性能的32位C64x+內(nèi)核和ARM926EJS內(nèi)核，工作頻率分別高達594MHz和297MHz，具有很強的運算處理能力。低功耗。多電源管理模式，雙內(nèi)核電壓供給為1．6V；ARM926EJS內(nèi)核具有16KB指令和8KB數(shù)據(jù)Cache，TMS320C64x+DSP內(nèi)核具有32KB程序RAM／Cache、80KB數(shù)據(jù)RAM／Cache及64KB未定義RAM／Cache；支持3．3V或1．8V的I／o接口和存儲器接口。專用的視頻圖像處理器和視頻處理子系統(tǒng)。專用的視頻圖像處理器用于對視頻數(shù)據(jù)處理；視頻處理子系統(tǒng)包括1個視頻前端輸入接口和1個視頻末端輸出接口，視頻前端輸入接口用于接收外部傳感器或視頻譯碼器等圖像，視頻末端輸出接口輸出圖像到SDTV、LCD、HDTV等顯示屏上。大存儲容量。有256MB的32位DDR2 SDRAM存儲空間，128MB的16位FLASH存儲空間。眾多的外設(shè)。64通道增強型DMA控制器：串行端口(3個UARTS、SPI、音頻串口)；3個64位通用定時器；10／l ooM以太網(wǎng)；USB2．O端口；3個PWM端口；多達71個通用I／0口；支持MMC／sD／CF卡等。采用時鐘控制。時鐘源：27MHz系統(tǒng)振