基于arm的嵌入式_網絡視頻監控系統設計與實現畢業設計(編輯修改稿)

　

【文章內容簡介】 式操 作系統和嵌入式應用軟件。系統結構如圖 21所示。 可靠性，有著較高的要求。 5)嵌入式系統本身并不具備在 其上進行開發的能力，都是通過交叉編譯開發完成的，即采用宿 主機和目標機的開發模式，在 PC上開發完，編譯成功后下載到目標機運行的模式。 一般而言，一個完整的嵌入式系統由四部分組成 :嵌入式微處理器、嵌入式外圍設備、嵌入式操 作系統和嵌入式應用軟件。系統結構如圖 21所示。 嵌人式應用軟件 嵌入式中間件 嵌入式操作系統7 三、視頻編解碼和網絡協議的選擇 盡管 IP網絡技術近年來在網絡帶寬和網絡速度方面有許多發展和改善，但相對于傳輸 數據量龐大的視頻信息而言，網絡速度依然是視頻傳輸中的瓶頸所在。因此，在有效利用現 有網絡資源基礎上，為了能提供較好的視頻傳輸質量，采用何種網絡傳輸協議是解決該問題 的關鍵所在；數字視頻的海量信息，如果不經過壓縮，將會浪費大量的資源，甚至造成系統 毫無意義。 因此，網絡傳輸協議和視頻壓縮編碼的選擇成為網絡數字視頻應用中的關鍵問題，將直 接影響到數字視頻傳輸的實時性能和視頻監控的質量。 一個基本的網絡視頻監控系統模型如圖 31所示。在網絡各層次中，物理層和數據鏈路 層是不能通過應用程序編程實現的，編程設計時不考慮這兩層。網絡層是將數據打包，選擇 適當的路由將數據傳送，使用 IP協議，傳輸層的任務是根據子網的特性最佳地利用網絡資 源，并以可靠和經濟的方式為兩端主機建立傳輸連接，以透明的方式傳送報文，使用 TCP/UDP協議 。應用層確定進程之間通信，是我們的編程任務，但無需選擇協議。所以為了 保證基于網絡的數字視頻傳輸的實時性和圖像的質量，傳輸層協議的選擇是整個設計和實現 的關鍵關鍵之一。 在目前的 IS0網絡模型中，在 IP之上使用了兩種傳 輸協議：一種是傳輸控制協議 TCP 協議；另一種是用戶數據報協議 UDP協議。 TCP 協議 （ 傳輸控制協議 /Transport Control Protocol) 圖 31基本視頻網絡傳輸系統 8 TCP/IP協議最初是為非實時數據業務而設計的。 IP協議負責主機之間的數據傳輸，不 進行檢錯和糾錯，因此，經常發生數據丟失或失序現象。為保證數據的可靠傳輸，人們將 TCP用于 IP數據的傳輸，以提高接收端的檢錯和糾錯能力。 TCP是面向連接的可靠的網絡 協議，面向連接服務是電話系統服務模式的抽象，即每一次完整的數據傳輸都要經過建立連 接、使用連接、終 止連接的三次握手過程；并且當檢測到數據包丟失或者錯誤時，就會要求 發送端重新發送，這樣以來就不可避免引發了傳輸延時和網絡帶寬的問題。由此看來，由于 TCP的重傳機制和擁塞控制機制， TCP更適用于對傳輸可靠性高于實時性要求的信息傳輸。 UDP協議（用戶數據報協議 /User Datagram Protocol) UDP協議是建立在 IP協議的基礎之上的，它是無連接的不可靠的網絡協議，提供無連 接的數據報服務。無連接服務是郵政系統服務的抽象。無連接服務不能保證數據報的先后順 序，不進行分組出錯的恢復和重傳、流 控制，不保證傳輸的可靠性，但它能提供開銷最小的、 快速的端到端通信服務。相對于 TCP來說， UDP有如下優點： 1) 時延小 ： UDP傳送數據前并不與對方建立連接，數據的傳輸不需要經過 “三次握手 ” ， 發送完畢后也不需要釋放鏈接，因此減少了開銷和發送數據之前的時延。 2) 消耗小： UDP不使用擁塞控制，不保證可靠的交付，因此主機不需要維持具有許多 參數的、復雜的連接狀態表。 3) 網絡流量小、速度快： UDP對接收到的數據報不發送確認信號，發送端不知道數據 是否被正確接收，也不會重發數據，這樣減少了網絡流量并且傳輸速度也比 TCP更快。 從以上分析可知， UDP的傳輸延時低于 TCP， 能與視頻流很好的匹配， UDP相對于 TCP 來說更適合視頻的數據傳輸。由于 UDP是無連接的不可靠的協議，無法保證實時視頻傳輸 業務的服務質量，為了支持網絡實時傳輸服務、 QOS保證等問題， 1996年 IETF(Inte Engineering Task Force)的視頻音頻工作組制訂了 RTP實時傳輸協議。在協議設計時 ， RTP 被設計成緊密相關的兩個部分： 1) RTP協議 (實時傳輸協議 )，用來傳輸具有實時特點的數據。 2) RTCP協議 (實時傳輸控制協議 )，用來控 制服務質量。 RTP 協議 （ Realtime Transport Protocol) RTP協議它只是一種應用型的傳輸層協議，它基于組播或是單播網絡服務，提供端到端 的實時數據傳輸服務，本身并不提供任何傳輸的可靠性保證和流量的擁塞控制機制。 RTP協議位于 UDP之上，在功能上獨立于下面的傳輸層 (UDP)和網絡層，但不能單獨作 為一個層次存在。它在 150網絡模型中的位置如圖 32所示。 網絡層 (IP) 圖 32 RTP在 TCP/IP模型中的位置 應用層 傳輸層 RTP/RTCP UDP 9 它通常是采用 UDP/IP封裝數據包，將應用程序生成的音、視頻數據被封裝在 RTP信息 包中，每個 RTP信息包被封裝在 UDP消息段中，然后再封裝在 IP數據包中，完成音、視頻 數據的實時傳輸，因此 RTP有著 UDP傳輸的優點。 1) RTP的數據包格式 RTP數據報的包頭格式如圖 33所示： 圖 33 RTP包頭格式 RTP數據協議負責對流媒體數據進行封包并實現媒體流的實時傳輸，每一個 RTP數據 報都由頭部 (Header)和負載 (Payload)兩個部分組成，其中頭部前 12個字節的含義是固定的， 而負載則可以是不定長連續音頻或視頻數據。 RTP包頭的時間戳和順序號是該協議的精華之處，其詳細解釋如下： 序列號 （ SequeneeNumber):16位長度，每發送一個 RTP數據包序列號加 1，接收方根 據此可以發現是否有數據包丟失。例如，接收端的應用程序接收到的 RTP包流中在順序號 86和 89之間有一個間隔，接收端就知道信息包 87和 88已經丟失，并且采取措施來處理 相應的措施處理丟失的數據。 時間戳 (Timestamp):犯位長度，是實時數據傳輸的重要信息，它記錄了數據塊第一字節 的 采樣時間，采樣時間是線性單調增長的，其時鐘頻率取決于 RTP幀的載荷類型。接收方 利用時間戳可以實現數據流的同步，包括同一數據流的流內同步和不同數據流的流間同步， 完成對數據包的重組，并按照正常的速率回放數據。對于一些大的數據塊，一個數據塊被分 成多個 RTP包，它們的時間戳相同。僅靠時間戳，不足以恢復數據包的順序， RTP利用提 供的序列號以恢復數據包的順序，實現包丟失檢測，為網絡的實時傳輸提供網絡擁塞等信息。 RTCP 協議 （ Realtime Control Transport Protocol) RTCP是和 RTP — 起使用的進行流量控制和擁塞控制的服務控制協議，它是 RTP的控制 協議，用于監視網絡的服務質量和數據接發雙方傳遞信息，負責管理傳輸質量在當前應用進 程之間交換控制信息。在 RTP會話期間，各參與者周期性地傳送 RTCP包，包中含有己發送 的數據包的數量、丟失的數據包的數量等統計資料，因此，服務器可以利用這些信息動態地 改變傳輸速率，甚至改變有效載荷類型。 1) RTCP協議數據包格式 RTP提供一個控制協議 (即 RTCP)， 用來支持其協議功能，圖 34和 35是 RTCP協議的 相關示意圖，直觀地描述了 RTcP包的打包結構、包格式等。 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 567 版本 補 齊 擴展 位 CSRC 數 標 釵荷類馭 PT) 序列兮 （ Sequence Number) 時間戲 （ Timestamp) 32位 同步源標識 (SSRC) 32位 CSRC標識符 (32位 ______________________ 我荷數據 （ Payload) 32位 _________________ 10 0 丨 2 3 0 1 2 3 4 5 6 7 0 1』 3 4 5 6了 0 1 2 3 4 5 6 7 0 1 23 4 567 V=2 P RR count 錢荷類型 (PT) Message length _________ __________________________SSRC OF report sender __________________________ ___ NRP timestamp(two 32bit words) RTP timestamp Send’s cumulative packet count Send39。s cumulative byte count 圖 34 RTCP發送報告包頭格式 0 12 3 ~ 0 i 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 f Y 3 4—567 V=2 P RR count 錢荷類型 (PT Message length _____________________SSRC of report sender ___________________________ SSRC of first source head from — __ RTP timestamp fraction lost Cumulative number of lost packets Extended highest sequence mumber received estimate RTP packet inter arrival time first Timestamp of last SR report received elapsed time since last SR report received Reception Report 圖 35 RTCP接收報告包頭格式 類似于 RTP數據包，每個 RTCP報文以固定的包頭部分開始，緊接著的是可變長結構元 素，類型不同長度也不同，但 總是 32位的整數倍，長度在固定部分的長度域中標明。結構 元素的意義由 RTCP報文的類型決定，因為通常 RTCP包非常小，一般把多個 RTCP包合并 為一個 RTCP包，然后利用一個底層協議所定義的報文格式 (例如 UDP格式 )進行發送。 RTCP報文頭部參數首先要區別攜帶不同控制信息的 RTCP報文的類型， RTCP報文的類 型主要有以下幾種： （ 1)SR:發送報告，當前活動發送者發送、接收統計。 （ 2)RR:接收報 告，非活動發送者接收統計。 （ 3)SDES:源描述項，包括 CNAME。（ 4)BYB:表示結束。 （ 5)APP: 應用特定函數。 其中最主要的 RTCP報文是 SR和 RR: (1) SR(SenderReport)： 發送方報告。由處于活躍狀態的信源發送方發送， SR報文不 僅提供該端系統作為接收方的數據接收質量反饋信息，而且還提供 SSRC(同步源 )標識符、 RTP時間戮、發送包數以及發送字節數等與發送有關的信息。 (2) RR(ReeeiverReport)： 接收方報告。由實時數據接收方發送， RR報文針對每個信 源都提供報文丟失數、已收報文的最大序列號、到達時間抖動、接收最后一個 SR的時間、 接收最后一個 SR的延遲等信息。 RTCP協議 功能 根據上面的 RTCP報文， RTCP可以完成以下功能： (1) 擁塞控制和 QOS監測。提供數據發布的質量反饋，這是 RTCP最主要的功能。用 反饋信息的方法來提供分配數據的傳送質量，這種反饋可以用來進行流量的擁塞控制，也可 以用來監視網絡和用來診斷網絡中的問題。 (2) 標識 (Identification)RTP數據分組只用一個隨機產生的 32比特標識符來標識其數 據源。 RTeP11 消息包含一個 SDES(信息源描述， SoureeDescription)， 用于保存一些文本形 式的信息，例如，會議參與者的全局惟一標識符、用戶名稱、 Email地址、電話號碼等。 (3) 根據與會者的數量來調整 RTCP包的發送率。前兩種功能要求所有參加者發送 RTCP 包，因此，為了 RTP擴展到大規模數量，速率必須受到控制。 RTCP控制報文的發送周期是 變化的，與報文長度 L、用戶數 N和控制報文帶寬 B相關：周期 P=LxN/B。 原因是 RTP設 計成允許應用自動擴展的模式，連接數可從幾個到上千個，如果每個參加者以固定速率發送 接收報告，控制流量將隨參加者數量線性增長，因此，速率必須按比例下降。 (4) 控制傳送會話控制信息量。參與會話的每個成員周期性地發送 RTCP包，各站點 可據此估計或計算出參與通信的人數，以便及時調節實時控制的信息量，使得控制信息量和 媒體業務量達到平衡。 RTP/RTCP協議工作流程 在具體實現時，可把 RTP執行程序看成是應用程序的一部分，把 RTP集成到應用程序 中。在發送端，必須把執行 RTP