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