【正文】 接收到的最好質量數(shù)據(jù)流量。編程時首先要識別設備，設定所采圖像的幀大小、幀頻率、編碼類型等參數(shù)。 調(diào)用 CaptureDeviceManager 的 getDevice方法，可以獲取一個特定的設備，每一個特定的設備都由 CaptureDeviceInfo 對象代表。 是國際電聯(lián) ITUT 的一個標準草案，是為低碼流通信而設計的，支持用于視頻會議和視頻電話應用程序的視頻壓縮 (解碼 [7]）。軟件壓縮一般使用已有的壓縮處理程序實現(xiàn)，將壓縮算法在程序中作為單獨的處理模塊調(diào)用，使用時需明確指定輸入數(shù)據(jù)的位置、數(shù)據(jù)格式等輸入?yún)?shù)和輸出數(shù)據(jù)類型。 首先在 CaptureDeviceManager 中獲取設備的信息， CaptureDeviceManager 是可在JMF 中使用的全部捕獲設備的注冊中心。整個程序流程圖描述了，從界面接收 IP 地址和端口號，自動定位媒體源，產(chǎn)生 RTP 會話以 及發(fā)送 RTP 數(shù)據(jù)流。 ) 客戶端加入會話以后 ,首先加入端口號最小的層中接收流媒體數(shù)據(jù) ,這時客 戶端得到主觀質量最差的視頻流。 本文提出的控制 方法 基于 分層的擁塞控制是指客戶端如何選擇加入和退出各層從而得到一個合適的網(wǎng)絡流量。在這樣的機制中，可以在傳輸?shù)拇a流中加入用于糾錯的冗余信息，在遇到包丟失的情況時，利用冗余信息恢復丟失的信息。 差錯控制 差錯控制機制力圖 減少目的端包丟失對視覺效果造成的損害。這樣可以同時使網(wǎng)絡擁塞最 小和分組丟失率最小。由于資源預留的代價較大，所以通常對較重要的數(shù)據(jù)采用預留的方式通信，而對于其余數(shù)據(jù)采用自適應的方法處理。這需要在網(wǎng)絡中實現(xiàn)具體的資源分配和預留機制，許可控制機制及特殊的調(diào)度機制。而一小段多媒體數(shù)據(jù) 的丟失往往不會造成嚴重的后果，再加上為保證數(shù)據(jù)的實時特征，一般不要求數(shù)據(jù)重發(fā)，所以對差錯控制的要求很低。一些較常見的例子有網(wǎng)絡電話，視頻會議，視頻點播。 軟件環(huán)境 1）安 裝 : JDK 默認安裝目錄為 d:\Program Files\Java\jdk1_5_0_17。把 Processor、 Plugin 和 Data Sink 整合到一塊 ,就可以完成捕獲、存儲、處理、播放和壓縮媒體內(nèi)容的任務。每隔一段時間，發(fā)送 RTCP 包報告 RTP 包的接收情況。系統(tǒng)結構分為兩大部分： 流媒體發(fā)送端和流媒體 接收端。例如：手機網(wǎng)絡平臺的開發(fā)一般是基于 Java 的，憑著 Java 跨平臺的優(yōu)點，基于 Java開發(fā)的流媒體實時傳輸系統(tǒng)有望移植到手機平臺。 JMF RTP API 是 JMF 中支持 RTP 應用開發(fā)的應用程序接口，可 以在網(wǎng)絡中實時傳輸和接收媒體流 [10,11]。相應的交叉開發(fā)環(huán) 境選用 :宿主機 (CP 機 )采用 FedoraCore3，采用 CMO 口和目標體通信 。 嵌入式 Linux 操作系統(tǒng)兼容 UNIX 操作系統(tǒng)。 Linux 是完全符合 GNU/GPL 許可的操作系統(tǒng)內(nèi)核。為了達到視頻流和聲音流需要的吞吐量，只要可能， DirectShow 會調(diào)用 Direc tDraw 和 DirectSound。 在處理多媒體信息時，可能會碰到以下問題： ，必須得到快速的處理。統(tǒng)計項包括： ① SSRC_n（源標識符）： 32 位， SSRC 源標識符； ②丟失率： 3 位，自上一次發(fā)送 SR 或 RR 后，源 SSRC_n 的 RTP 數(shù)據(jù)包丟失率； ③累計丟失包數(shù)： 24 位，接收開始后丟失包數(shù)的累計； XXXX汽車工業(yè)學院畢業(yè)設計（論文） 13 ④擴展的最大順序號： 32 位，低 16 位包含來自源 SSRC_n 的 RTP 數(shù)據(jù)包的最大順序號，高 16 位使用相應的順序號循環(huán)計數(shù)時順序號的擴展； ⑤間隔到達抖動： 32 位，使用無符號整數(shù)； ⑥最近發(fā)送方報告的時間戳（ LSR）： 32 位，最近接收的 RTCP 發(fā)送方報告包中 NTP 時間戳的中間 32 位，如無 SR 被接收，此字段為 0； ⑦自 最近發(fā)送方報告之后的延遲（ DLSR）： 32 位，從源 SSRC_n 接收的最后的 SR包到發(fā)送此接收報告塊之間的延遲，如無 SR 包從源 SSRC_n 被接收，則 DLSR 字段置0； 接收方報告包（ RR）的格式同 SR 包基本相同。同步源（ SSRC）：此包的同步源標識符。 RTCP 發(fā)送方報告數(shù)據(jù)包格式 RTCP 發(fā)送方報告（ SR）數(shù)據(jù)包格式如圖 34 所示。 RTCP 的 SR 報文包含與 RTP 時間戳相對應的實時信息，可以像視頻幀同步一樣實現(xiàn)媒體 同步。提供信源的描述信息，包括 CNAME（信源端系統(tǒng)標識）、 NAME（用戶名）、 EMAIL（電子郵件地址）、 PHONE（電話號碼）、LOC（地理位置）、 TOOL（應用程序或工具名）、 NOTE（通知 /狀態(tài)）、 PRIV（用戶定義項）等 SDES 報文項。多個 RTCP 包不需要任何分隔符就可以組合成一個混合 RTCP 包，然后用下層協(xié)議的一個包發(fā)送出去，例如 UDP 包。這表明 RTP 的數(shù)據(jù)傳輸是面向無連接、無差錯控制的報文傳輸，兩個協(xié)議共同完成了傳輸層協(xié)議的功能。提供了對實時傳輸交互性的支持，使接 收方能夠獲得有關發(fā)送方的信息。 時間戳：記錄了 RTP 數(shù)據(jù)包中首字節(jié)的采樣時間。 CSRC 數(shù) (參與者計數(shù) )：表示固定頭部后 CSRC 標識的個數(shù)。 三、支持多播 如果下層網(wǎng)絡支持， RTP 可支持采用多播的傳送方式將實時數(shù)據(jù)傳送到多個目的地，滿足多媒體會話的需要。 表 數(shù)據(jù)格式 MAC Header IP Header UDP Header RTP Message 在協(xié)議設計時， RTP 遵循 Clark 和 Tennenhouse 提出的 alfamp。通常，對靜態(tài)圖像采用有損壓縮技術時，為保證圖像的質量，壓縮率一般限制在 7： 1 到 25： 1 之間；對活動視頻采用有損壓縮技術，為保證圖像質量，壓縮率常限制在 150： 1 以下。 圖像質量優(yōu)先的 實時視頻壓縮編碼方案是把圖像質量（圖像清晰度）要求放在首位，而對圖像的連續(xù)性（即幀率）要求并不特別注重的視頻壓縮算法。 的視頻編碼過程首先是判斷圖像信號是屬于 I 幀還是 P 幀，如果是 I 幀則只做 DCT 和可變長編碼。優(yōu)點：圖像質量可以調(diào)節(jié)，壓縮率高，數(shù)據(jù)量從 小到大可變，軟硬件產(chǎn)品成熟。缺點：目前成熟的軟硬件產(chǎn)品不多。 3．低比特率音頻與視頻對象壓縮編碼標準 MPEG4。 MPEG2 是由 ISO 的活動專家組和 ITUT 的 15 研究組于 1995 年共同制定的，在ITUT 的標準中，被稱為 。 1．數(shù)字聲像存儲壓縮編碼標準 MPEG1。 多媒體數(shù)據(jù)壓縮技術 多媒體信息的編碼技術是多媒體信息處理技術中的一個關鍵問題，多媒體數(shù)據(jù)的壓縮標準為多媒體技術的廣泛應用提供了前提。為了提高視頻數(shù)據(jù)的傳輸效率，針對不同的視頻信號產(chǎn)生了不同的視頻數(shù)據(jù)壓縮標準，如： MPEG1， MPEG2， MPEG4， +。 流技術正是為了繞過互連網(wǎng)的這個局限而設計的。 眾所周知，在 Inter 上傳輸音 /視頻（ A/V）等多媒體信息，目前主要有下載和流式傳輸兩種方式。 本課題 所做的工作 本文的研究目標是：研究一種基于 RTP 協(xié)議的流媒體實時傳輸?；诜纸M交換的 IP 網(wǎng)具有良好的擴展性，也不需要專門鋪設 流媒體 電纜和控制電纜，成本低，可充分利用現(xiàn)有的網(wǎng)絡資源。伴隨著流媒體技術的出現(xiàn)，諸如視頻會議、視頻點播之類的網(wǎng)絡多媒體應用 開始進入人們的生活。（ 2）本文深入分析了RTP/RTCP 的特點、內(nèi)容，認為該協(xié)議非常適合多 媒體信息的網(wǎng)上傳輸。本人完全意識到本聲明的法律后果由本人承擔 。 本學位論文屬于 保密 □，在 _________年解密后適用本授權書。 關鍵詞： RTP；流媒體 傳輸； JMF； Inter XXXX汽車工業(yè)學院畢業(yè)設計（論文） Abstract The besteffort service based on IP provided by Inter isn’t suitable for the transmission of Streaming Media from a Streaming Media transmission need in worked multimedia application,the research project the thesis discusses is to research an RTPbased Streaming Media transmission which can adapt to the changes of work thesis includes the following three parts: Firstly,this thesis analyzes stream media technology and video pression coding technology in worked multimedia application. Secondly,this thesis lucubrates the contents and characters of RTP/RTCP and thinks that RTP is well suitable for the Streaming Media information ,in order to realize RTP and transmission control policy,this thesis makes use of the platform of SUN .Using the wide variety of formats supported by JAVA and the characters based on JMF ponent object model,this thesis researches the architecture of JMF,its basic theory and construction of its basic ponent. With the help of existing capture and encode ponents,making use of JMF architecture,this thesis realizes an integrated Streaming Media transmission experiment model. Keywords: RTP。采用模擬信號傳輸帶來的問題就是系統(tǒng)的造價高，建設周期長，適應性不強。而且，網(wǎng)絡還不夠強大，帶寬資源有限，不能很好的保證服務質量。 （ 4）研究了基于任何平臺的 流媒體 處理技術 —— JMF 的體系結構，基本原理。那么就算是一個廣告短片最少也需要 1 個小時的下載，這還是在網(wǎng)絡狀況極其良好的情況下。但并不是說文件整體就變小了，原始文件依然很大。早期的 INTERNET 帶寬窄、路由瓶頸、接入速率低、延遲大而不確定，使得實時性強的視音頻流質量不能得到保證，限 制了 IP 多媒體的廣泛應用。即使硬件技術發(fā)展得再快，如果 不對信息進行壓縮，多媒體技術也很難有大的發(fā)展，多媒體技術的應用也會受到很大的限制。 視頻分辨率為 352X240（ NTSC）和 352X288（ PAL），視頻幀速率為 30 幀 /秒，壓縮后的視頻數(shù)據(jù)量為 ；音頻按 采樣， 16bit 量化精度，雙聲道，壓縮后的音頻數(shù)據(jù)量為 ；控制視頻及聲音復用的系統(tǒng)流數(shù)據(jù)量為 。與 MPEG1 相比，它增加了以下功能：處理隔行掃描視頻信號的能力；更高的色信號取樣模式；可伸縮的視頻編碼方式。編碼系統(tǒng)是開放的，可以隨時加入新的有效的算法模塊。 以其靈活性及節(jié)省帶寬和存儲空間的特性，具有低總擁有成本并提供了迅速的投資回報。 的視頻編碼、解碼算法是基于 算法的，是 算法的改進。自適應量化器能根據(jù)預測的比特數(shù)自適 應修改量化器的量化系數(shù)，即自動調(diào)整量化間隔大小，以此方式控制碼率。而當視頻圖像緩慢變化或者圖像中活動部分占整個圖像的比例很小時，數(shù)據(jù)量將明顯減小，這時在維持原來數(shù)字視頻的空間分辨率不變的條件下， 實時視頻壓縮算法會自動減少丟失幀數(shù)，從而提高一些幀率。 實時傳輸協(xié)議 RTP/RTCP RTP 的特點 為了支持網(wǎng)絡實時傳輸服務，提供數(shù)據(jù)實時傳輸?shù)臉藴剩?1996 年 IETF（ Inter Engineering Task Force）的視頻 /音頻工作組制訂了 RTP 實時傳輸協(xié)議。 總的來說， RTP 協(xié)議具有以下特點： 一、簡單性 XXXX汽車工業(yè)學院畢業(yè)設計（論文） 8 RTP 協(xié)議不具備傳輸層的完整功能，其本身也不提供任何機制來保證實時地傳輸數(shù)據(jù)，不保證服務質量，而是依賴下層協(xié)議提供的服務來完成這些任務。 RTP 數(shù)據(jù)包頭格式如 表 所示。常見的負載類型有：PCM， MPEG1/MPEG2， H261 視頻流， JPEG 視頻等，用戶可以根據(jù)需要定義負載類型。接收方利用時間戳實現(xiàn)媒體的同步，控制數(shù)據(jù)的回放速率?？梢杂?015 項。所以可以說， RTP 是面向應用的 一個協(xié)議。 RTCP 的數(shù)據(jù)包分如