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