【正文】 遲大而不確定，使得實(shí)時(shí)性強(qiáng)的視音頻流質(zhì)量不能得到保證，限制了IP多媒體的廣泛應(yīng)用。第四代基于IP網(wǎng)絡(luò)的多媒體通信技術(shù)是當(dāng)前尖端的通信技術(shù)，此前基于電視廣播技術(shù)交換的通信技術(shù)、基于電路交換的通信技術(shù)、基于分組交換的通信技術(shù)，被稱為第一代、第二代和第三代。數(shù)據(jù)壓縮標(biāo)準(zhǔn)的不斷完善，多媒體視頻技術(shù)和IP技術(shù)的發(fā)展和成熟，都為網(wǎng)絡(luò)多媒體的應(yīng)用發(fā)展提供了基礎(chǔ)，帶來了新的發(fā)展機(jī)遇。數(shù)字化的視音頻信息，其數(shù)據(jù)量非常大。即使硬件技術(shù)發(fā)展得再快，如果不對(duì)信息進(jìn)行壓縮，多媒體技術(shù)也很難有大的發(fā)展，多媒體技術(shù)的應(yīng)用也會(huì)受到很大的限制。在一個(gè)視頻幀中，像素與像素之間無論是在橫向還是豎向上都有很大的相關(guān)性，而且，幀和幀之間的相關(guān)性很大，如對(duì)前一個(gè)幀的數(shù)據(jù)作微小的變化，可能就能夠得到當(dāng)前的信息。下面介紹其中幾種視頻壓縮標(biāo)準(zhǔn)[2,3]。 。 視頻分辨率為352X240（NTSC）和352X288（PAL），視頻幀速率為30幀/秒，；，16bit量化精度，雙聲道，；。優(yōu)點(diǎn)：圖像質(zhì)量較好，同時(shí)還有伴音。2．?dāng)?shù)字聲像存儲(chǔ)壓縮編碼標(biāo)準(zhǔn)MPEG2。設(shè)計(jì)目標(biāo)是高級(jí)工業(yè)標(biāo)準(zhǔn)的圖像質(zhì)量和更高的傳輸率。與MPEG1相比，它增加了以下功能：處理隔行掃描視頻信號(hào)的能力；更高的色信號(hào)取樣模式；可伸縮的視頻編碼方式。它主要用于數(shù)字視頻廣播（DVB）、高清晰度電視（HDTV）和數(shù)字視頻光盤（DVD）等高質(zhì)量的視頻存儲(chǔ)，傳輸?shù)木幋a表示和解碼規(guī)定。缺點(diǎn)：數(shù)據(jù)量非常大。 MPEG4由ISO的MPEG4工作組制定。編碼系統(tǒng)是開放的，可以隨時(shí)加入新的有效的算法模塊。視頻分辨率為352X288（CIF）和176X144（QCIF）等。優(yōu)點(diǎn)：圖像質(zhì)量可以調(diào)節(jié)，有伴音，數(shù)據(jù)量從小到大可變，具有基于內(nèi)容檢索功能。4．。具有低總擁有成本并提供了迅速的投資回報(bào)。視頻分辨率為352X288（CIF）和176X144（QCIF）等。優(yōu)點(diǎn)：圖像質(zhì)量可以調(diào)節(jié)，壓縮率高，數(shù)據(jù)量從小到大可變，軟硬件產(chǎn)品成熟。 （DCT—Discrete CosineTransformation）和運(yùn)動(dòng)補(bǔ)償（Motion Compensation）算法，根據(jù)運(yùn)動(dòng)補(bǔ)償獲得的運(yùn)動(dòng)矢量找出預(yù)測(cè)值，接著求出當(dāng)前值和預(yù)測(cè)值的差，再將這個(gè)差值做DCT變換，最后做可變長(zhǎng)編碼。算法采用幀間與幀內(nèi)編碼相結(jié)合的混合編碼技術(shù)，若前后兩幀很相似，其幀間差值小于某閥值，則采用幀間預(yù)測(cè)（Interframe Predicting），然后對(duì)幀間預(yù)測(cè)差進(jìn)行CT；若前后兩幀的幀間預(yù)測(cè)誤差較大，則采用幀內(nèi)編碼，即將當(dāng)前幀圖像直接進(jìn)行DCT編碼。I幀是利用圖像自身的相關(guān)性壓縮，對(duì)I幀圖像編碼時(shí)無須參考其它幀，I幀提供了壓縮數(shù)據(jù)流中的隨機(jī)存取點(diǎn)，它包括全部圖像的信息，數(shù)據(jù)量最大。 ，如果是I幀則只做DCT和可變長(zhǎng)編碼。 由于受到傳輸信道帶寬的限制，在編碼器端采用自適應(yīng)量化器來控制碼率，也就是說。根據(jù)量化定義：如果設(shè)量化電平數(shù)（量化系數(shù)或量化分級(jí)數(shù)）為J，量化精度為R，則有R＝Log2J?？梢妼?duì)于均勻量化，量化系數(shù)越大（即量化分級(jí)越多或者說量化間隔越?。炕染驮礁?，量化誤差就越小，編碼誤差也就越小，重構(gòu)圖像質(zhì)量就越好，但是其數(shù)字化編碼所用的二進(jìn)制碼位數(shù)就越多，數(shù)字化的數(shù)據(jù)量就越大。（圖像清晰度）要求放在首位，而對(duì)圖像的連續(xù)性（即幀率）要求并不特別注重的視頻壓縮算法。這樣便可以在保持?jǐn)?shù)字視頻的空間分辨率不下降（即圖像的清晰度優(yōu)先）的情況下使總數(shù)據(jù)量不超過傳輸信道的最高數(shù)據(jù)傳輸率。（圖像幀率）要求放在首位的視頻壓縮算法。，它的算法中既包括了如Huffman編碼、游程編碼（RLE—Run Length Encoding）等無損壓縮算法（通常壓縮比不大），又包括了如DCT變換、運(yùn)動(dòng)補(bǔ)償預(yù)測(cè)技術(shù)、運(yùn)動(dòng)補(bǔ)償插值技術(shù)等有損壓縮算法（通常壓縮比可以很大）。通常，對(duì)靜態(tài)圖像采用有損壓縮技術(shù)時(shí)，為保證圖像的質(zhì)量，壓縮率一般限制在7：1到25：1之間；對(duì)活動(dòng)視頻采用有損壓縮技術(shù)，為保證圖像質(zhì)量，壓縮率常限制在150：1以下。因此圖像壓縮比與圖像質(zhì)量顯然也是相互矛盾的兩個(gè)對(duì)立面。 在RFC1889中，RTP被定義為緊密相關(guān)的兩個(gè)部分： 1．實(shí)時(shí)傳輸協(xié)議RTP（Realtime Transport Protocol），用來傳輸具有實(shí)時(shí)特點(diǎn)的數(shù)據(jù)。RTP提供端到端的實(shí)時(shí)數(shù)據(jù)傳輸服務(wù)，包括載荷標(biāo)識(shí)，數(shù)據(jù)序號(hào)，時(shí)戳和傳輸控制。 數(shù)據(jù)格式MAC HeaderIP HeaderUDP HeaderRTP Message在協(xié)議設(shè)計(jì)時(shí)，RTP遵循Clark和Tennenhouse提出的alfamp。在實(shí)現(xiàn)時(shí)RTP與應(yīng)用程序緊密結(jié)合，根據(jù)應(yīng)用的特點(diǎn)和要求構(gòu)造與剪裁控制策略，提高會(huì)話質(zhì)量和網(wǎng)絡(luò)服務(wù)的公平性。它不保證提交或防止亂序提交，也不假設(shè)下層網(wǎng)絡(luò)是可靠的并且提交的分組是有序的。另外，RTP協(xié)議將部分傳輸層協(xié)議功能（比如流量控制）上移到應(yīng)用層完成，簡(jiǎn)化了傳輸層處理，提高了該層的執(zhí)行效率。三、支持多播如果下層網(wǎng)絡(luò)支持，RTP可支持采用多播的傳送方式將實(shí)時(shí)數(shù)據(jù)傳送到多個(gè)目的地，滿足多媒體會(huì)話的需要。 RTP的數(shù)據(jù)包格式 RTP數(shù)據(jù)包由RTP頭和不定長(zhǎng)連續(xù)媒體數(shù)據(jù)組成，其中前12字節(jié)為固定的RTP頭，媒體數(shù)據(jù)可以是編碼數(shù)據(jù)。 補(bǔ)充位：如果為1，表示數(shù)據(jù)包的末尾包含有一個(gè)或多個(gè)附加的補(bǔ)充字節(jié)，它們不是有效載荷的一部分。擴(kuò)展位：如果為1，表示固定頭部后將跟隨一個(gè)頭部擴(kuò)展。標(biāo)記：可用于標(biāo)識(shí)流中的重要事件。常見的負(fù)載類型有：PCM，MPEG1/MPEG2，H261視頻流，JPEG視頻等，用戶可以根據(jù)需要定義負(fù)載類型。接收方可以發(fā)現(xiàn)是否有數(shù)據(jù)包丟失并重新排序。雖然源本身沒有被加密，但數(shù)據(jù)包經(jīng)過解釋器（translator）后就被加密，隨即產(chǎn)生的序列號(hào)使對(duì)加密的攻擊變得更加困難。采樣時(shí)間可以取自一個(gè)單調(diào)遞增非線性的，允許同步和抖動(dòng)計(jì)算的時(shí)鐘。接收方利用時(shí)間戳實(shí)現(xiàn)媒體的同步，控制數(shù)據(jù)的回放速率。某些較大的數(shù)據(jù)塊，如視頻幀，被分成許多小塊放在連續(xù)的RTP包中，它們的時(shí)間戳是一樣的。 SSRC標(biāo)識(shí)符（同步源標(biāo)識(shí)符）：標(biāo)識(shí)出同步源。為了使同一個(gè)RTP會(huì)話中的兩個(gè)同步源標(biāo)識(shí)符不相同，采用隨機(jī)選擇產(chǎn)生SSRC標(biāo)識(shí)符。可以有015項(xiàng)。 RTP在協(xié)議層中的位置從實(shí)時(shí)傳輸協(xié)議RTP名字來看，實(shí)時(shí)傳輸協(xié)議RTP應(yīng)該是傳輸層上的一層協(xié)議，但實(shí)際上并不是這樣。這樣可以利用UDP的多路技術(shù)和數(shù)據(jù)校驗(yàn)服務(wù)，而多路技術(shù)對(duì)于控制報(bào)文的傳輸是非常必要的。很好的說明了RTP在協(xié)議層中所處的位置。所以可以說，RTP是面向應(yīng)用的一個(gè)協(xié)議。RTCP的做法是周期性地進(jìn)行通信，采用和數(shù)據(jù)包分配傳遞的相同機(jī)制來發(fā)送控制。長(zhǎng)度在固定部分的長(zhǎng)度域中標(biāo)明。RTCP包周期性地在會(huì)話成員之間組播，起著會(huì)員活動(dòng)指示器的作用。RTCP的數(shù)據(jù)包分如下5類： 1．SR（Sender report）：發(fā)送方報(bào)告。 2．RR（Receiver report）：接收方報(bào)告。 3．SDES（Source description items）：源描述項(xiàng)。 4．BYE：將某參與者退出信息通知會(huì)話，并可提供退出原因。 借助于上述控制包，RTCP可完成下列控制功能： 1．QOS監(jiān)測(cè)和擁塞控制。無論對(duì)發(fā)送方、接收方還是網(wǎng)絡(luò)管理員，RTCP提供的數(shù)據(jù)傳輸反饋信息都是非常有用的。 2．媒體同步。 3．信源標(biāo)識(shí)。而RTCP的SEDS包中有足夠的文本信息，如CNAME項(xiàng)可標(biāo)識(shí)信源端系統(tǒng)，NAME項(xiàng)可標(biāo)識(shí)用戶名，Email項(xiàng)可標(biāo)識(shí)電子郵件地址，PHONE項(xiàng)可標(biāo)識(shí)電話號(hào)碼，LOC項(xiàng)可標(biāo)識(shí)信源的地理位置，可以滿足復(fù)雜應(yīng)用的需要。4．會(huì)議大小估計(jì)和控制信息量的調(diào)節(jié)。RTP在IP多播環(huán)境中使用時(shí)，功能13是必須的，也是在所有環(huán)境中推薦的。該數(shù)據(jù)包分三部分，如果需要還可以根據(jù)具體應(yīng)用加上擴(kuò)展部分。分別是： 版本號(hào)（V）：2位，表示RTP版本。接收?qǐng)?bào)告計(jì)數(shù)（RC）：5位，此包中的接收?qǐng)?bào)告塊數(shù)，0是允許的。長(zhǎng)度：16位，RTCP以32位計(jì)的長(zhǎng)度。 （2）包體，共20字節(jié)，它描述發(fā)送方的數(shù)據(jù)傳送。RTP時(shí)間戳：32位，與NTP時(shí)間戳對(duì)應(yīng)，而且與數(shù)據(jù)包中的RTP時(shí)間戳有相同的單位和相同的偏移值。發(fā)送字節(jié)計(jì)數(shù)：32位，發(fā)送方從開始發(fā)送到發(fā)送本報(bào)告為止發(fā)送的負(fù)載字節(jié)數(shù)，如果SSRC定義符被改變，本字段被重置。當(dāng)源由于沖突改變它的SSRC標(biāo)識(shí)符時(shí)，接收方不發(fā)送統(tǒng)計(jì)。不同點(diǎn)在于RR的包類型為201，并且5個(gè)發(fā)送者信息被省略（NTP和RTP時(shí)間戳，發(fā)送者的包和字節(jié)計(jì)數(shù)）其它字段均相同。 DirectShow為多媒體流的捕捉和回放提供了強(qiáng)有力的支持。它廣泛地支持各種媒體格式，包括Asf、Mpeg、Avi、Dv、MpWave等等，使得多媒體數(shù)據(jù)的回放變得輕而易舉。更值得一提的是，DirectShow提供的是一種開放式的開發(fā)環(huán)境，我們可以根據(jù)自己的需要定制自己的組件。，包括：本地磁盤文件，計(jì)算機(jī)網(wǎng)絡(luò)，電視廣播和攝像機(jī)。它的主要設(shè)計(jì)目標(biāo)是把數(shù)字媒體應(yīng)用程序與復(fù)雜的數(shù)據(jù)傳輸，多樣的硬件設(shè)備和同步隔離開，從而簡(jiǎn)化在Windows平臺(tái)上創(chuàng)建程序的工作。這些技術(shù)將多媒體數(shù)據(jù)通過用戶的顯卡和聲卡有效的表現(xiàn)出來。為了適應(yīng)數(shù)據(jù)來源、格式和硬件設(shè)備的多變，DirectShow采用模塊化的系統(tǒng)結(jié)構(gòu)，其中由應(yīng)用程序?qū)⒉煌能浖M件——過濾器組合并匹配起來。 方案二. 在嵌入式平臺(tái)下實(shí)現(xiàn)流媒體實(shí)時(shí)傳輸在幾種嵌入式操作系統(tǒng)中，幾款商業(yè)操作系統(tǒng)像WindowCE和VxW6kr，不僅具有較高的性能和良好的移植性，而且也提供了良好的開發(fā)環(huán)境和技術(shù)服務(wù)。另外，商業(yè)操作系統(tǒng)一般都不提供源碼，這使對(duì)嵌入式操作系統(tǒng)的研究無法深入。它的源碼是完全公開的和免費(fèi)的。目前在很多的嵌入式處理器上都己經(jīng)成功的移植了嵌入式Linux操作系統(tǒng)。對(duì)實(shí)時(shí)性的支持有了很大的提高。GNU工具鏈支持嵌入式開發(fā)的整個(gè)過程。許多UNIX應(yīng)用程序無需任何改動(dòng)，就可以直接在Linux系統(tǒng)中編譯運(yùn)行。按照是否經(jīng)過了廠商的優(yōu)化，可以將嵌入式Linux操作系統(tǒng)分成兩類:商業(yè)化的嵌入式Linux操作系統(tǒng)以及非商業(yè)化的嵌入式Linux內(nèi)核。而商業(yè)化的嵌入式Linux操作系統(tǒng)，除了完成上述的工作以外，還對(duì)嵌入式Linux操作系統(tǒng)做了一些改進(jìn)，包括實(shí)時(shí)性擴(kuò)展以及技術(shù)支持培訓(xùn)服務(wù)等。本設(shè)計(jì)中，選擇商業(yè)化的MiziLinux操作系統(tǒng)在嵌入式平臺(tái)運(yùn)行。所以在基于ARMS3C2440的嵌入式平臺(tái)下的linux操作系統(tǒng)下系統(tǒng)設(shè)計(jì)如下： 網(wǎng)絡(luò)媒體流實(shí)時(shí)傳輸系統(tǒng)設(shè)計(jì) [8,9]。然后編寫客戶端子系統(tǒng)。它支持大多數(shù)標(biāo)準(zhǔn)的媒體類型，如AIFF,AU,AVI,GSM,MIDI,MPEG,QuickTime,RMF以及WAV。在JMF的高層結(jié)構(gòu)中RTP API位于JMF API和插件結(jié)構(gòu)Plugin API之間。同處理其他媒體內(nèi)容一樣，Player和Processor對(duì)象用來回放RTP媒體流。第一種方案是Windows平臺(tái)上進(jìn)行流媒體處理，沒有可移植性。難度太大，所以選擇了第三種方案，這種方案是基于Java的，能夠?qū)崿F(xiàn)基于RTP協(xié)議的流媒體實(shí)時(shí)傳輸，而且Java具有跨平臺(tái)的優(yōu)點(diǎn)，基于Java開發(fā)的流媒體實(shí)時(shí)傳輸系統(tǒng)有望移植到嵌入式平臺(tái)上。所以我先擇了第三種方案。 在流媒體實(shí)時(shí)傳輸應(yīng)用中，視頻傳輸是很重要的一部分。為了保證流媒體傳輸?shù)男Ч?，人們提出了多種流媒體傳輸控制的方法，希望改進(jìn)服務(wù)質(zhì)量。 連接示意圖 系統(tǒng)處理流程圖 系統(tǒng)采用客戶/服務(wù)器結(jié)構(gòu)，流媒體信息發(fā)送端為服務(wù)器端，流媒體信息接收端為客戶端。流媒體發(fā)送端的系統(tǒng)。 流媒體接收端的系統(tǒng)流程圖 系統(tǒng)模塊的劃分及功能描述 基于以上系統(tǒng)流程的分析，可以分為以下幾個(gè)模塊： 流媒體捕獲模塊：該模塊從攝像頭采集流媒體數(shù)據(jù)，經(jīng)其內(nèi)部的硬件初步壓縮后輸入計(jì)算機(jī)，等待下一步的處理。 RTP傳輸模塊：該模塊得到流媒體數(shù)據(jù)后，將其用RTP協(xié)議打包。 RTP分析模塊：該模塊從網(wǎng)絡(luò)上接收RTP包，重組后分析出媒體數(shù)據(jù)供下面的模塊解壓縮。 流媒體播放模塊：該模塊將解壓縮的流媒體數(shù)據(jù)顯示在屏幕上。Java最顯而易見的優(yōu)點(diǎn)是其平臺(tái)無關(guān)性,可以“編譯一次,到處運(yùn)行”,而且Java幾乎從一開始就和網(wǎng)絡(luò)聯(lián)系在一起,是一種比較理想的網(wǎng)絡(luò)編程語言。JMF可以分為兩部分:JMF API和JMF RTP API。Processor和Plugin用于處理媒體數(shù)字信號(hào),Data Sink可用于存儲(chǔ)和顯示媒體內(nèi)容。后者JMF RTP API是JMF提供的實(shí)時(shí)傳輸多媒體數(shù)據(jù)流的API,即RTP(包含RTCP)包。除了上面提到的四個(gè)管理器之外, SessionManager用于與RTP會(huì)話一同工作。JMF提供的模型可大致分為七類：數(shù)據(jù)（data source）,截取設(shè)備（Capture Device,包括視頻和音頻截取設(shè)備），播放器（Player），處理器（Processor）,數(shù)據(jù)池（DataSink）,數(shù)據(jù)格式（Format）,管理器（Manager）。攝像頭，麥克風(fēng)等。右鍵點(diǎn)擊Windows桌面我的電腦屬性,在彈出系統(tǒng)特性對(duì)話框中選擇高級(jí)選項(xiàng)卡,點(diǎn)擊環(huán)境變量按鈕,彈出環(huán)境變量對(duì)話框,單擊新建(W)…按鈕,彈出新建系統(tǒng)變量對(duì)話框,在該對(duì)話框中輸入變量名為JAVA_HOME和變量值為d:\Program Files\Java\jdk1_5_0_17。%JAVA_HOME%\lib\=%JAVA_HOME%\bin。3）安裝J3D：。目前，網(wǎng)絡(luò)多媒體技術(shù)的應(yīng)用和發(fā)展正在迅速的增長(zhǎng)。流媒體信息的傳輸控制作為其中一個(gè)重要的組成部分，有其不同于普通數(shù)據(jù)傳輸控制的特點(diǎn)。此外，大多數(shù)網(wǎng)絡(luò)多媒體應(yīng)用為了提供有效的服務(wù)，滿足基本的視/音頻效果，還需要有最小的吞吐量保證。二、為支持交互性的對(duì)話，確保屬于不同媒體流或在同一媒體流的數(shù)據(jù)同步，端到端的延遲和延遲的最大變化量應(yīng)該有上界的限制。四、普