【正文】 。一些較常見的例子有網(wǎng)絡(luò)電話，視頻會議，視頻點播。4）安裝JBuilder2006（集成開發(fā)環(huán)境）。2）安裝JMF:選擇將JMF的開發(fā)和運行環(huán)境安裝在JDK的路徑d:\Program Files\Java\ jdk1_5__0_17中,使JMF與JDK融為一體,這樣可以免去操作系統(tǒng)中設(shè)置Java環(huán)境變量。用同樣的辦法設(shè)置CLASSPATH=%JAVA_HOME%\lib\。 軟件環(huán)境1）:JDK默認(rèn)安裝目錄為d:\Program Files\Java\jdk1_5_0_17。 建立Java多媒體開發(fā)環(huán)境所需的硬件和軟件 硬件環(huán)境 至少兩臺能運行Windows操作系統(tǒng)的PC,運行該實例時,其中一臺用來當(dāng)發(fā)送端,另一臺當(dāng)接收端。SessionManager可跟蹤會話參與方以及所傳送的流,還用于處理RTCP控制通道,為發(fā)送方和接收方提供支持。JMF RTP API能與JMF的捕獲設(shè)備、播放器、處理器和處理能力無縫結(jié)合。把Processor、Plugin和Data Sink整合到一塊,就可以完成捕獲、存儲、處理、播放和壓縮媒體內(nèi)容的任務(wù)。前者提供了處理器(Processor)、插件(Plugin)、Data Sink。Java提供了豐富的類庫,由SunMicrosystem公司單獨提供(指不包含在標(biāo)準(zhǔn)JDK中)的Java Media Framework(JMF)提供了對多媒體編程的比較完善的支持。 JMF體系結(jié)構(gòu)Java作為一種優(yōu)秀的面向?qū)ο蟮木幊陶Z言,具有簡單、可移植、分布式、多線程、安全等諸多特點。每隔一段時間，發(fā)送RTCP包報告RTP包的接收情況。每隔一段時間，接收RTCP包并加以分析。 流媒體壓縮模塊：該模塊從緩沖區(qū)獲取數(shù)據(jù)，然后將數(shù)據(jù)傳給下一個模塊。 流媒體發(fā)送端的系統(tǒng)流程圖。系統(tǒng)結(jié)構(gòu)分為兩大部分：流媒體發(fā)送端和流媒體接收端。在實時傳輸協(xié)議—RTP的基礎(chǔ)上，實現(xiàn)流媒體實時傳輸。它直接關(guān)系到系統(tǒng)的運行效果，關(guān)系到系統(tǒng)能否被客戶接收?；赗TP協(xié)議的網(wǎng)絡(luò)多媒體應(yīng)用程序 ，主要分為兩個部分，一部分是負(fù)責(zé)通過網(wǎng)絡(luò)發(fā)送數(shù)據(jù)的主機端（RTP Servers）程序 ，另一部分是接收數(shù)據(jù)的客戶端（RTP Clients）程序。例如：手機網(wǎng)絡(luò)平臺的開發(fā)一般是基于Java的，憑著Java跨平臺的優(yōu)點，基于Java開發(fā)的流媒體實時傳輸系統(tǒng)有望移植到手機平臺。第二種方案是在嵌入式平臺下實現(xiàn)服務(wù)器子系統(tǒng)和在PC機上實現(xiàn)客戶子系統(tǒng)。用戶可以將采集和保存的媒體數(shù)據(jù)以媒體流的形式在網(wǎng)絡(luò)中傳輸。JMF RTP API 可以無縫地與JMF的獲取，回放及處理功能一起工作。JMF RTP API是JMF中支持RTP應(yīng)用開發(fā)的應(yīng)用程序接口，可以在網(wǎng)絡(luò)中實時傳輸和接收媒體流[10,11]。 方案三. 采用JAVA媒體框架（JMF）實現(xiàn)流媒體實時傳輸 JMF是一種采用Java語言開發(fā)流式媒體應(yīng)用的API，它采用統(tǒng)一的結(jié)構(gòu)和消息傳遞協(xié)議，可以提供數(shù)據(jù)的回放，控制，處理及傳輸?shù)裙δ?。本地服?wù)子系統(tǒng)包括兩個基本的工作模塊：編碼模塊以及Linux操作系統(tǒng)下編寫硬件的驅(qū)動程序和網(wǎng)絡(luò)服務(wù)模塊(利用嵌入式平臺的TCP/IP網(wǎng)絡(luò)功能，實現(xiàn)專用的RTP/RTCP協(xié)議)。相應(yīng)的交叉開發(fā)環(huán)境選用:宿主機(CP機)采用FedoraCore3，采用CMO口和目標(biāo)體通信。選擇商業(yè)化的嵌入式Linux操作系統(tǒng)可以減小很多的工作并且提高了系統(tǒng)的性能，另外，使用商業(yè)化的嵌入式Linux操作系統(tǒng)是不需要版權(quán)費，只需付給商家一定的服務(wù)費。只有嵌入式Linux內(nèi)核，是無法進(jìn)行嵌入式系統(tǒng)開發(fā)的，還需要很多的GNU項目支持，包括GNU工具鏈、文件系統(tǒng)等。Linux操作系統(tǒng)具有UNIX操作系統(tǒng)幾乎一致的編程接口，這給習(xí)慣了UNIX操作系統(tǒng)的軟件開發(fā)者轉(zhuǎn)向Linux操作系統(tǒng)提供了很大的便利。嵌入式Linux操作系統(tǒng)兼容UNIX操作系統(tǒng)。Linux內(nèi)核得到了GNU組織的支持，提供了一系列的嵌入式系統(tǒng)開發(fā)工具。雖然Linux在實時性方面不如一些商業(yè)的嵌入式操作系統(tǒng)，但是在一些對實時性要求不是很高的嵌入式系統(tǒng)中得到了廣泛地應(yīng)用。Linux內(nèi)核支持眾多的處理器，并且針對特定的處理器做了許多性能優(yōu)化工作。Linux是完全符合GNU/GPL許可的操作系統(tǒng)內(nèi)核。但是都需要較高的成本，這是在嵌入式系統(tǒng)設(shè)計中必須考慮的一個問題。DirectShow提供有支持基于WDM驅(qū)動程序的捕捉和調(diào)諧設(shè)備的過濾器，也有支持早期的VFW視頻捕捉卡的過濾器以及為ACM（Audio Compression Manager）和VCM（Video Compression Manager）接口編寫的編解碼器。DirectShow將媒體數(shù)據(jù)封裝到帶有時間戳的樣本中，以實現(xiàn)同步回放。為了達(dá)到視頻流和聲音流需要的吞吐量，只要可能，DirectShow會調(diào)用DirectDraw和DirectSound。DirectShow的設(shè)計正是針對以上問題。，包括：ASF，AVI，MPEG和DV。兩者應(yīng)同時開始，同時結(jié)束，協(xié)調(diào)工作。在處理多媒體信息時，可能會碰到以下問題：，必須得到快速的處理。另外，DirectShow還集成了DirectX其它部分（比如DirectDraw、DirectSound）的技術(shù)，直接支持DVD的播放，視頻的非線性編輯，以及與數(shù)字?jǐn)z像機的數(shù)據(jù)交換。運用DirectShow，可以很方便地從支持WDM驅(qū)動模型的采集卡上捕獲數(shù)據(jù)，并且進(jìn)行相應(yīng)的后期處理乃至存儲到文件中。第二章 總體方案設(shè)計 方案論證DirectShow是微軟公司提供的一套在Windows平臺上進(jìn)行流媒體處理的開發(fā)包，與DirectX開發(fā)包一起發(fā)布[6,7]。統(tǒng)計項包括： ①SSRC_n（源標(biāo)識符）：32位，SSRC源標(biāo)識符； ②丟失率：3位，自上一次發(fā)送SR或RR后，源SSRC_n的RTP數(shù)據(jù)包丟失率； ③累計丟失包數(shù)：24位，接收開始后丟失包數(shù)的累計； ④擴(kuò)展的最大順序號：32位，低16位包含來自源SSRC_n的RTP數(shù)據(jù)包的最大順序號，高16位使用相應(yīng)的順序號循環(huán)計數(shù)時順序號的擴(kuò)展； ⑤間隔到達(dá)抖動：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包基本相同。 RTCP發(fā)送方數(shù)據(jù)包0 16 31VPPt=sr=200長度SSRC同步源NTP時間戳高位NTP時間戳低位RTP時間戳發(fā)送者包計數(shù)發(fā)送者字節(jié)數(shù)SSRC_1（第一個發(fā)送源）丟失率累計丟包數(shù)擴(kuò)展的最大順序號間隔到達(dá)抖動最近發(fā)送方報告的時間戳自最近發(fā)送方報告之后的延遲SSRC_2（第二個發(fā)送源）... ...文本擴(kuò)展部分（3）包含0個或多個接收報告塊，它取決于發(fā)送方從上次報告起知道的其它源數(shù)，每個接收報告塊要表示從一個同步源RTP包的接收統(tǒng)計。發(fā)送RTP包計數(shù)：32位，發(fā)送方從開始發(fā)送到發(fā)送本報通告為止共發(fā)送的負(fù)載字節(jié)數(shù)，如果SSRC定義符被改變，本字段被重置。 NTP時間戳：64位，定義本包發(fā)送時間，可以與接收方報告包中的時間戳比較，估計往返時間。同步源（SSRC）：此包的同步源標(biāo)識符。包類型（PT）：8位，發(fā)送方報告的RTCP包定義為200。補充位（P）：1位，若此位被設(shè)置，RTCP的尾部包含一些附加的補充位。 （1）頭部，共8字節(jié)。 RTCP發(fā)送方報告數(shù)據(jù)包格式RTCP發(fā)送方報告（SR）數(shù)據(jù)包格式如圖34所示。參與會話的每個成員周期性地發(fā)送RTCP包，各站點可據(jù)此估計或計算出參與通信的人數(shù)，以便及時調(diào)節(jié)實時控制的信息量，使得控制信息量和媒體業(yè)務(wù)量達(dá)到平衡（在多媒體會議中，控制信息量一般為媒體業(yè)務(wù)量的5%左右）。方便實時數(shù)據(jù)傳輸?shù)慕邮辗将@得發(fā)送信源的有關(guān)信息。RTP數(shù)據(jù)包只能通過隨機產(chǎn)生的32位的識別符來標(biāo)識源，不能滿足諸如會議這樣的復(fù)雜應(yīng)用的需求。RTCP的SR報文包含與RTP時間戳相對應(yīng)的實時信息，可以像視頻幀同步一樣實現(xiàn)媒體同步。發(fā)送方可根據(jù)RTCP RR報文調(diào)整數(shù)據(jù)實時傳輸方式，保證端系統(tǒng)正常接收；接收方可確定網(wǎng)絡(luò)擁塞的范圍是在本地、本區(qū)域還是全局，有的放矢地采取對策；網(wǎng)絡(luò)管理員及時監(jiān)視網(wǎng)絡(luò)實時傳輸?shù)男阅?。這是RTCP的一個重要功能。 5．APP：應(yīng)用程序特殊功能。提供信源的描述信息，包括CNAME（信源端系統(tǒng)標(biāo)識）、NAME（用戶名）、EMAIL（電子郵件地址）、PHONE（電話號碼）、LOC（地理位置）、TOOL（應(yīng)用程序或工具名）、NOTE（通知/狀態(tài)）、PRIV（用戶定義項）等SDES報文項。由實時數(shù)據(jù)接收方發(fā)送，RR報文針對每個信源都提供報文丟失數(shù)、已收報文的最大序列號、到達(dá)時間抖動、接收最后一個SR的時間、接收最后一個SR的延遲等信息。由處于活躍狀態(tài)的信源發(fā)送方發(fā)送，SR報文不僅提供該端系統(tǒng)作為接收方的數(shù)據(jù)接收質(zhì)量反饋信息（與RTCP RR報文相同），而且還提供SSRC（同步源）標(biāo)識符、NTP時間戳、RTP時間戳、發(fā)送包數(shù)以及發(fā)送字節(jié)數(shù)等與發(fā)送有關(guān)的信息。在RFC1889中定義了許多RTCP分組，分別承擔(dān)不同的控制功能。多個RTCP包不需要任何分隔符就可以組合成一個混合RTCP包，然后用下層協(xié)議的一個包發(fā)送出去，例如UDP包。每個RTCP包的前一部分是固定的，類似于RTP的數(shù)據(jù)包，后面的結(jié)構(gòu)根據(jù)包的類型不同長度也不同，但總是32位的整數(shù)倍。 RTCP的控制功能 RTCP是RTP的控制協(xié)議，它用于監(jiān)視網(wǎng)絡(luò)的服務(wù)質(zhì)量和數(shù)據(jù)接發(fā)雙方傳遞信息。 UDP/IP封裝的RTP數(shù)據(jù)首先用RTP協(xié)議標(biāo)準(zhǔn)把數(shù)據(jù)封裝，再用UDP協(xié)議對RTP數(shù)據(jù)包進(jìn)行封裝，最后由IP網(wǎng)絡(luò)層封裝為IP數(shù)據(jù)包進(jìn)行傳輸。這表明RTP的數(shù)據(jù)傳輸是面向無連接、無差錯控制的報文傳輸，兩個協(xié)議共同完成了傳輸層協(xié)議的功能。RTP是一個輕型協(xié)議，它本身不提供數(shù)據(jù)傳輸?shù)墓δ?，而是由底層的傳輸協(xié)議完成數(shù)據(jù)傳輸，一般情況下利用UDP進(jìn)行。 RTP數(shù)據(jù)包沒有包含長度域或其它邊界，因此RTP依賴下層網(wǎng)絡(luò)提供一個長度的表示，RTP包的長度僅受下層網(wǎng)絡(luò)的限制。CSRC列表：僅出現(xiàn)在有混合器的情況下。提供了對實時傳輸交互性的支持，使接收方能夠獲得有關(guān)發(fā)送方的信息?？梢允褂眯蛄刑柣謴?fù)數(shù)據(jù)包的順序。初始值也是隨機數(shù)。該時鐘的分辨率應(yīng)對于同步和計算包到達(dá)時間的同步是足夠的。 時間戳：記錄了RTP數(shù)據(jù)包中首字節(jié)的采樣時間。初始值為隨機數(shù)。 序列號：每發(fā)送一個RTP數(shù)據(jù)包序列號加1。 負(fù)載類型：指定了RTP數(shù)據(jù)包的負(fù)載格式及編碼壓縮方法。CSRC數(shù)(參與者計數(shù))：表示固定頭部后CSRC標(biāo)識的個數(shù)。在使用某些加密算法時或為了在低層協(xié)議中攜帶多個RTP包時可能會用到補充位。 RTP數(shù)據(jù)包頭格式版本號(2位)補充位（1位）擴(kuò)展位（1位）CSRC數(shù)（4位）標(biāo)記（1位）負(fù)載類型（7位）序列號（16位）時間戳（32位）SSRC標(biāo)識符（32位）CSRC標(biāo)識符0（32位）版本號：表示RTP的版本，一般設(shè)為2。四、可擴(kuò)展性RTP協(xié)議通常為一個具體的應(yīng)用提供服務(wù)，通過一個具體的應(yīng)用進(jìn)程實現(xiàn)，而不作為OSI體系結(jié)構(gòu)中單獨的一層來實現(xiàn)，RTP只提供協(xié)議框架，開發(fā)者可以根據(jù)應(yīng)用的具體要求對協(xié)議進(jìn)行充分的擴(kuò)展。 二、靈活性 RTP協(xié)議的數(shù)據(jù)報文和控制報文使用相鄰的不同端口，數(shù)據(jù)流和控制流分離，這樣大大地提高了協(xié)議的靈活性，處理也簡單。RTP報文甚至不包括長度和報文邊界的描述，而是依靠下層協(xié)議提供長度標(biāo)識和長度限制?？偟膩碚f，RTP協(xié)議具有以下特點： 一、簡單性RTP協(xié)議不具備傳輸層的完整功能，其本身也不提供任何機制來保證實時地傳輸數(shù)據(jù)，不保證服務(wù)質(zhì)量，而是依賴下層協(xié)議提供的服務(wù)來完成這些任務(wù)。ilp（applicationlevel framing and integrated layer processing）原則，即：集成共性，個性擴(kuò)展。RTP數(shù)據(jù)（）通常采用UDP/IP封裝，它利用UDP的多路復(fù)用及校驗和服務(wù)，共同完成實時數(shù)據(jù)傳輸功能。 2．RTP控制協(xié)議RTCP（RTP Control Protocol），用來控制服務(wù)質(zhì)量，并在正在進(jìn)行的會話里傳送參加方的信息。 RTP的特點為了支持網(wǎng)絡(luò)實時傳輸服務(wù)，提供數(shù)據(jù)實時傳輸?shù)臉?biāo)準(zhǔn)，1996年IETF（Internet Engineering Task Force）的視頻/音頻工作組制訂了RTP實時傳輸協(xié)議?？傊瑝嚎s比越大圖像質(zhì)量損失越大。所以壓縮比越大，壓縮后的數(shù)據(jù)量就越小；但是壓縮后的圖像損失就越大，以后解壓重構(gòu)圖像的質(zhì)量就越差。也就是說，當(dāng)視頻圖像出現(xiàn)劇烈變化或者圖像中活動部分占整個圖像的比例較大時，數(shù)據(jù)量將大大增加，（減少量化等級系數(shù)，即增大量化間隔）來減少數(shù)字化的數(shù)據(jù)量，以便保持?jǐn)?shù)字視頻的時間分辨率不下降（也即圖像的幀率優(yōu)先）的情況下使總數(shù)據(jù)量不超過傳輸信道的最高數(shù)據(jù)傳輸率，當(dāng)然增大量化間隔必然會增大量化誤差，降低了圖像質(zhì)量。而當(dāng)視頻圖像緩慢變化或者圖像中活動部分占整個圖像的比例很小時，數(shù)據(jù)量將明顯減小，這時在維持原來數(shù)字視頻的空間分辨率不變的條件下，從而提高一些幀率。當(dāng)視頻圖像出現(xiàn)劇烈變化或者圖像中活動部分占整個圖像的比例較大時，數(shù)據(jù)量將大大增加，即丟掉一些幀，來減少數(shù)據(jù)量。，