【正文】 if ((h263Fm。 是國際電聯(lián) ITUT 的一個(gè)標(biāo)準(zhǔn)草案，是為低碼流通信而設(shè)計(jì)的，支持用于視頻會議和視頻電話應(yīng)用程序的視頻壓縮 (解碼 [7]）。軟件壓縮一般使用已有的壓縮處理程序?qū)崿F(xiàn)，將壓縮算法在程序中作為單獨(dú)的處理模塊調(diào)用，使用時(shí)需明確指定輸入數(shù)據(jù)的位置、數(shù)據(jù)格式等輸入?yún)?shù)和輸出數(shù)據(jù)類型。數(shù)據(jù)壓縮可以采用硬件或軟件方法實(shí)現(xiàn)。 媒體流可以直接播放出來或者是傳輸出去。 調(diào)用 CaptureDeviceManager 的 getDevice方法，可以獲取一個(gè)特定的設(shè)備，每一個(gè)特定的設(shè)備都由 CaptureDeviceInfo 對象代表。 首先在 CaptureDeviceManager 中獲取設(shè)備的信息， CaptureDeviceManager 是可在JMF 中使用的全部捕獲設(shè)備的注冊中心。 //設(shè)備管理器 locator = ()。 String str2 = vfw:Microsoft WDM Image Capture (Win32):0。編程時(shí)首先要識別設(shè)備，設(shè)定所采圖像的幀大小、幀頻率、編碼類型等參數(shù)。整個(gè)程序流程圖描述了，從界面接收 IP 地址和端口號，自動定位媒體源，產(chǎn)生 RTP 會話以 及發(fā)送 RTP 數(shù)據(jù)流。 圖 服務(wù)器子系統(tǒng)界面 上面 是發(fā)送端界面的實(shí)際效果圖。在順利接收流媒體數(shù)據(jù)一段時(shí)間之后 ,客戶端嘗試使用流量更高的組合接收數(shù)據(jù) ,并在得到一個(gè)合適的流量后為止?？蛻舳耸褂蒙鲜鰯?shù)組中的組合進(jìn)行嘗試接收數(shù)據(jù) ,直到得到一個(gè)合適的流量為止 ,這里所謂合適的流量是指 ,此流量是該客戶端可以接收到的最好質(zhì)量數(shù)據(jù)流量。 ) 客戶端加入會話以后 ,首先加入端口號最小的層中接收流媒體數(shù)據(jù) ,這時(shí)客 戶端得到主觀質(zhì)量最差的視頻流。Port1Portn:16 位，表示各層的 RTP端口號 。 ,編碼后的碼流流量有可能有所變化 ,所以流媒體服務(wù)器需要及時(shí)通過 RTCP APP 數(shù)據(jù)包通知各客戶端系統(tǒng)中各層的數(shù)據(jù)流量。 端口號從小到大 ,幀率依次增加。 本文提出的控制 方法 基于 分層的擁塞控制是指客戶端如何選擇加入和退出各層從而得到一個(gè)合適的網(wǎng)絡(luò)流量。在這樣的機(jī)制中，可以在傳輸?shù)拇a流中加入用于糾錯的冗余信息，在遇到包丟失的情況時(shí)，利用冗余信息恢復(fù)丟失的信息?？沼虻幕謴?fù)使用同一幀的鄰近區(qū)域來重新組建丟失的碎片；時(shí)域的恢復(fù)使用前一幀的相應(yīng)區(qū)域來替代丟失的區(qū)域信息。 以上方法是通過調(diào)整幀內(nèi)編碼和幀間編碼 的幀的混合程度來使包丟失對視頻效果的影響最小化。在這樣的機(jī)制中，可以在傳輸?shù)拇a流中加入用于糾錯的冗余信息，在遇到包丟失的情況時(shí)，利用冗余信息恢復(fù)丟失的信息。空域的恢復(fù)使用同一幀的鄰近區(qū)域來重新組建丟失的碎片；時(shí)域的恢復(fù)使用前一幀的相應(yīng)區(qū)域來替代丟失的區(qū)域信息。于是，人們提出了三種方法來解決這一問題： ①通過調(diào)整幀內(nèi)編碼和幀間編 碼的幀的混合程度來使分組丟失對視頻效果的影響最小化。如對于 MPEG， 或 中的編碼方法，一個(gè)包的丟失可能會造成大量幀的質(zhì)量下降，直到下一個(gè)幀內(nèi)編碼的幀被正確接收為止。 差錯控制 差錯控制機(jī)制力圖 減少目的端包丟失對視覺效果造成的損害。這種機(jī)制使用較少。然而，這種基于源端的機(jī)制在異構(gòu)網(wǎng)絡(luò)中的運(yùn)行情況并不是很好。 在基于源端的控制機(jī)制中，流媒體 源端收集反饋信息，進(jìn)行控制計(jì)算并采取相應(yīng)的控制動作。這樣可以同時(shí)使網(wǎng)絡(luò)擁塞最 小和分組丟失率最小。對于可用帶寬和包丟失的處理，現(xiàn)在主要有速率控制和差錯控制機(jī)制。同時(shí)，基于流的 IP 交換機(jī)制也是解決這一問題的重要方法之一。對于流媒體 傳輸來說，重要的信道特性是端到端時(shí)延、可用帶寬和分組丟失率。由于資源預(yù)留的代價(jià)較大，所以通常對較重要的數(shù)據(jù)采用預(yù)留的方式通信，而對于其余數(shù)據(jù)采用自適應(yīng)的方法處理。例如，自適應(yīng)可以被用在很難對資源提前做出精確估計(jì)的情況中。該方法正被廣泛應(yīng)用在現(xiàn)有的網(wǎng)絡(luò)中。 2．根據(jù)當(dāng)前的網(wǎng)絡(luò)狀態(tài)調(diào)整應(yīng)用程序使用的帶寬實(shí)現(xiàn)相應(yīng)的自適應(yīng)操作。這需要在網(wǎng)絡(luò)中實(shí)現(xiàn)具體的資源分配和預(yù)留機(jī)制，許可控制機(jī)制及特殊的調(diào)度機(jī)制。另一方面，由于 UDP 協(xié)議沒有任何擁塞控制機(jī)制，高帶寬要求的網(wǎng)絡(luò)多媒體應(yīng)用程序 往往會成為因特網(wǎng)的負(fù)擔(dān)，并且可能占用基于 TCP 上的應(yīng)用程序本應(yīng)平等分得的那份帶寬資源。在提供無差別的、盡力而為的服務(wù)，且無任何 QOS 支持機(jī)制的網(wǎng)絡(luò)中，可用帶寬、時(shí)延和丟包率都是時(shí)變參量。 XXXX汽車工業(yè)學(xué)院畢業(yè)設(shè)計(jì)（論文） 21 流媒體 傳輸控制的研究 流媒體 傳輸控制的特點(diǎn)給傳統(tǒng)網(wǎng)絡(luò)提出了許多要求。而一小段多媒體數(shù)據(jù) 的丟失往往不會造成嚴(yán)重的后果，再加上為保證數(shù)據(jù)的實(shí)時(shí)特征，一般不要求數(shù)據(jù)重發(fā)，所以對差錯控制的要求很低。 三、普通數(shù)據(jù)的傳輸服務(wù)可以隨時(shí)改變傳輸速率，而連續(xù)的多媒體數(shù)據(jù)的傳輸服務(wù)必須有幾十秒的適應(yīng)階段，以避免由于速率的突然改變而引起質(zhì)量的明顯改變。而普通數(shù)據(jù)傳輸?shù)耐掏铝靠梢栽诤芏痰臅r(shí)間內(nèi)減少到接近為零。 一、傳輸高質(zhì)量的流媒體 信息需要高網(wǎng)絡(luò)帶寬的支持。一些較常見的例子有網(wǎng)絡(luò)電話，視頻會議，視頻點(diǎn)播。 4）安裝 JBuilder2021（集成開發(fā)環(huán)境） 。 2）安裝 JMF: 選擇將 JMF 的開發(fā)和運(yùn)行環(huán)境安裝在 JDK 的路徑 d:\Program Files\Java\ jdk1_5_ _0_17中 ,使 JMF 與 JDK 融為一體 ,這樣 可以免去操作系統(tǒng)中設(shè)置 Java 環(huán)境變量。用同XXXX汽車工業(yè)學(xué)院畢業(yè)設(shè)計(jì)（論文） 20 樣的辦法設(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)境 至少兩臺能運(yùn)行 Windows 操作系統(tǒng) 的 PC,運(yùn)行該實(shí)例時(shí) ,其中一臺用來當(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 提供XXXX汽車工業(yè)學(xué)院畢業(yè)設(shè)計(jì)（論文） 19 了豐富的類庫 ,由 SunMicrosystem 公司單獨(dú)提供 (指不包含在標(biāo)準(zhǔn) JDK 中 )的 Java Media Framework(JMF)提供了對多媒體編程的比較完善的支持。 JMF 體系結(jié)構(gòu) Java 作為一種優(yōu)秀的面向 對象的編程語言 ,具有簡單、可移植、分布式、多線程、安全等諸多特點(diǎn)。每隔一段時(shí)間，發(fā)送 RTCP 包報(bào)告 RTP 包的接收情況。每隔一段時(shí)間，接收 RTCP 包并加以分析，發(fā)現(xiàn)網(wǎng)絡(luò)擁塞后調(diào)整 的壓縮參數(shù)。 流 媒體 壓縮模塊：該模塊從緩沖區(qū)獲 取 數(shù)據(jù)，采用 壓縮算法進(jìn)一步壓縮，然后將數(shù)據(jù)傳給下一個(gè)模塊。 攝 像 頭 流 媒 體 采 集 I n t e r n e tH . 2 6 3 壓 縮利 用 下 層 網(wǎng) 絡(luò) 協(xié) 議 傳 輸數(shù) 據(jù) 封 裝 成 R T P 包 圖 流媒體 發(fā)送端的系統(tǒng)流程圖 XXXX汽車工業(yè)學(xué)院畢業(yè)設(shè)計(jì)（論文） 18 流媒體 接收端的系統(tǒng)流程圖如圖 所示。系統(tǒng)結(jié)構(gòu)分為兩大部分： 流媒體發(fā)送端和流媒體 接收端。在實(shí)時(shí)傳輸協(xié)議 — RTP 的基礎(chǔ)上，實(shí)現(xiàn)流媒體 實(shí)時(shí)傳輸。它 直接關(guān)系到系統(tǒng)的運(yùn)行效果，關(guān)系到系統(tǒng)能否被客戶接收。 基于 RTP 協(xié)議的網(wǎng)絡(luò)多媒體應(yīng)用程序 ，主要分為兩個(gè)部分，一部分是負(fù)責(zé)通過網(wǎng)絡(luò)發(fā)送數(shù)據(jù)的主機(jī)端（ RTP Servers）程序 ，另一部分是接收數(shù)據(jù)的客戶端（ RTP Clients）程序。例如：手機(jī)網(wǎng)絡(luò)平臺的開發(fā)一般是基于 Java 的，憑著 Java 跨平臺的優(yōu)點(diǎn)，基于 Java開發(fā)的流媒體實(shí)時(shí)傳輸系統(tǒng)有望移植到手機(jī)平臺。第二種方案是在嵌入式平臺下實(shí)現(xiàn)服務(wù)器子系統(tǒng)和在 PC 機(jī)上實(shí)現(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ò)中實(shí)時(shí)傳輸和接收媒體流 [10,11]。 方案三 . 采用 JAVA 媒體框架（ JMF）實(shí)現(xiàn)流媒體實(shí)時(shí)傳輸 JMF 是一種采用 Java 語言開發(fā)流式媒體應(yīng)用的 API，它采用統(tǒng)一的結(jié)構(gòu)和消息傳遞協(xié)議，可以提供數(shù)據(jù)的回放，控制，處理及傳輸?shù)裙δ?。本地服?wù)子系統(tǒng)包括兩個(gè)基本的工作模塊：編碼模塊以及 Linux 操作系統(tǒng)下編寫硬件的驅(qū)動程序和網(wǎng) 絡(luò)服務(wù)模塊 (利用嵌入式平臺的 TCP/IP 網(wǎng)絡(luò)功能，實(shí)現(xiàn)專用的RTP/RTCP 協(xié)議 )。嵌入式操作系統(tǒng)內(nèi)核版本為 。相應(yīng)的交叉開發(fā)環(huán) 境選用 :宿主機(jī) (CP 機(jī) )采用 FedoraCore3，采用 CMO 口和目標(biāo)體通信 。選擇商業(yè)化的嵌入式 Li nux 操作系統(tǒng)可以減小很多的工作并且提高了系統(tǒng)的性能，另外，使用商業(yè)化的嵌入式 Linux 操作系統(tǒng)是不需要版權(quán)費(fèi)，只需付給商家一定的服務(wù)費(fèi)。只有嵌入式 Linux 內(nèi)核，是無法進(jìn)行嵌入式系統(tǒng)開發(fā)的，還需要很多的 GNU 項(xiàng)目支持，包括 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 在實(shí)時(shí)性方面不如一些商業(yè)的嵌入式操作系統(tǒng)，但是在一些對實(shí)時(shí)性要求不是很高的嵌入式系統(tǒng)中得到了廣泛地應(yīng)用。 Linux 內(nèi)核支持眾多的處理器，并且針對特定的處理器做了許多性能優(yōu)化工作。 Linux 是完全符合 GNU/GPL 許可的操作系統(tǒng)內(nèi)核。但是都需 要較高的成本，這是在嵌入式系統(tǒng)設(shè)計(jì)中必須考慮的一個(gè)問題。 DirectShow 提供有支持基于 WDM 驅(qū)動程序XXXX汽車工業(yè)學(xué)院畢業(yè)設(shè)計(jì)（論文） 15 的捕捉和調(diào)諧設(shè)備的過濾器，也有支持早期的 VFW 視頻捕捉卡的過濾器以及為 ACM（ Audio Compression Manager）和 VCM（ Video Compression Manager）接口編寫的編解碼器。DirectShow 將媒體數(shù)據(jù)封裝到帶有時(shí)間戳的樣本中，以實(shí)現(xiàn)同步回放。為了達(dá)到視頻流和聲音流需要的吞吐量，只要可能， DirectShow 會調(diào)用 Direc tDraw 和 DirectSound。 DirectShow 的設(shè)計(jì)正是針對以上問題。 ，包括： ASF， AVI， MPEG 和 DV。兩者應(yīng)同時(shí)開始，同時(shí)結(jié)束，協(xié)調(diào)工作。 在處理多媒體信息時(shí)，可能會碰到以下問題： ，必須得到快速的處理。另外， DirectShow 還集成了 DirectX 其它部分（比如 DirectDraw、 DirectSound）的技術(shù)，直接支持 DVD 的播放，視頻 的非線性編輯，以及與數(shù)字?jǐn)z像機(jī)的數(shù)據(jù)交換。運(yùn)用 DirectShow，可以很方便地從支持 WDM 驅(qū)動模型的采集卡上捕獲數(shù)據(jù)，并且進(jìn)行相應(yīng)的后期處理乃至存儲到文件中。 XXXX汽車工業(yè)學(xué)院畢業(yè)設(shè)計(jì)（論文） 14 第二章 總體方案設(shè)計(jì) 方案論證 方案一 .采用 DirectShow 框架實(shí)現(xiàn)流媒體實(shí)時(shí)傳輸 DirectShow 是微軟公司提供的一套在 Windows 平臺上進(jìn)行 流媒體處理的開發(fā)包，與 DirectX 開發(fā)包一起發(fā)布 [6,7]。統(tǒng)計(jì)項(xiàng)包括： ① SSRC_n（源標(biāo)識符）： 32 位， SSRC 源標(biāo)識符； ②丟失率： 3 位，自上一次發(fā)送 SR 或 RR 后，源 SSRC_n 的 RTP 數(shù)據(jù)包丟失率； ③累計(jì)丟失包數(shù)： 24 位，接收開始后丟失包數(shù)的累計(jì)； XXXX汽車工業(yè)學(xué)院畢業(yè)設(shè)計(jì)（論文） 13 ④擴(kuò)展的最大順序號： 32 位，低 16 位包含來自源 SSRC_n 的 RTP 數(shù)據(jù)包的最大順序號，高 16 位使用相應(yīng)的順序號循環(huán)計(jì)數(shù)時(shí)順序號的擴(kuò)展； ⑤間隔到達(dá)抖動： 32 位，使用無符號整數(shù)； ⑥最近發(fā)送方報(bào)告的時(shí)間戳（ LSR）： 32 位，最近接收的 RTCP 發(fā)送方報(bào)告包中 NTP 時(shí)間戳的中間 32 位，如無 SR 被接收，此字段為 0； ⑦自 最近發(fā)送方報(bào)告之后的延遲（ DLSR）： 32 位，從源 SSRC_n 接收的最后的 SR包到發(fā)送此接收報(bào)告塊之間的延遲，如無 SR 包從源 SSRC_n 被接收，則 DLSR 字段置0； 接收方報(bào)告包（ RR）的格式同 SR 包基本相同。 表 RTCP 發(fā)送方數(shù)據(jù)包 0 16