【正文】 實際上本程充的開發(fā)難點并不在于JAVA語言或者說是程序本身，我認(rèn)為最難之處是在于你能不能不真正理解，領(lǐng)會計算機網(wǎng)絡(luò)。不能退縮，要持堅下去，持之以恒。一開始，摸不著頭腦，但是畢竟這種語言還是很有用的。當(dāng)時我想需一個跨平臺的語言，能夠在不同的平臺上也能夠運行，而JAVA語言正好滿足我要求，所以我選擇了JAVA。其次，在開發(fā)過程中，由于工作需要，我熟悉了JBuilder2006,Inno step,Exe4j,等工具軟件和使用。首先，設(shè)計這樣一個C/S系統(tǒng)，就要在整個過程中貫穿一種系統(tǒng)工程的概念，把握這個系統(tǒng)。通過使用JMF技術(shù)實現(xiàn)基于RTP協(xié)議流媒體的實時傳輸,為應(yīng)用實例進(jìn)一步設(shè)計提供了理論基礎(chǔ)。本實例在Windows操作系統(tǒng)下開發(fā),因此,開發(fā)工具和Java虛擬機都安裝于Windows環(huán)境中。 本章簡要敘述了系統(tǒng)的測試方案以及對媒體流的實時傳輸?shù)臏y試結(jié)果。再通過Inno stup把EXE文件做成安裝程序。綜合測試結(jié)果表明，各功能模塊基本實現(xiàn)預(yù)期功能，能夠?qū)崿F(xiàn)視頻流的實時傳輸。第四章 系統(tǒng)測試 系統(tǒng)測試結(jié)果與分析在服務(wù)器子系統(tǒng)正常運行的情況下，用戶進(jìn)行IP地址設(shè)置和端口號的設(shè)置。利用這一特點，可以實現(xiàn)網(wǎng)上視，音頻會議，網(wǎng)絡(luò)教學(xué)等實時性強的任務(wù)，可以說RTP為人們獲取信息和交流開拓了廣闊的天地。當(dāng)監(jiān)聽到媒體數(shù)據(jù)流事件時,獲取該媒體數(shù)據(jù)流,構(gòu)造播放器,獲取播放窗口。 if (pw != null) { () // 關(guān)閉播放窗口 (pw)。else if (evt instanceof ByeEvent) { // 數(shù)據(jù)接收完畢由RTCP放出ByeEvent ( Got \bye\ from: + ())。 當(dāng)監(jiān)聽到60秒內(nèi)沒有數(shù)據(jù)源到達(dá)時，結(jié)束會話。 return false。 } } } catch (Exception e) {} if (!dataReceived) { // 在設(shè)定的時間內(nèi)沒有等到數(shù)據(jù) (No RTP data was received.)。 () then waitingPeriod) { // 等待上面所設(shè)定的時間 if (!dataReceived) ( Waiting for RTP data to arrive...)。 // 最多等待60秒 try{ synchronized (dataSync) { while (!dataReceived amp。 // 等待數(shù)據(jù)到達(dá) long then = ()。調(diào)用Manager.creatplayer(dsouree)創(chuàng)建一個Player對象。如果檢測到NewReceiveStreamEvent事件，調(diào)用getReceiveStream，通過stream=((NewReceivestreamEvent)event).getReceiveStream從NewReceiveStreamEvent中檢索ReceiveStream。②創(chuàng)建一個public void update(ReceiveStreamEvent event)方法來監(jiān)聽NewReeeivestreamEvent。先用mgr=(SessionManager)new ()創(chuàng)建一個SessionManager。它從媒體流中檢索Datasource，通過sessionManager為每個特定的Reeeivestream構(gòu)建一個player，(Datasouree)。 // 將該播放窗口加入向量數(shù)組中2)為RTP會話進(jìn)程中每個新接收到的流創(chuàng)建一個Player。 // 實現(xiàn)播放器 PlayerWindow pw = new PlayerWindow(p, stream)。 // 通過數(shù)據(jù)源構(gòu)造一個媒體播放器 (this)。 // 得到接收數(shù)據(jù)的格式 else ( Recevied new RTP stream)。這種方式創(chuàng)建Player的程序代碼如下:RTPControl ctl =(RTPControl) ()。調(diào)用addControllerListener(this)監(jiān)聽RealizeCompleteEvent。根據(jù)JMF中的回放機制，當(dāng)接收數(shù)據(jù)沒有到達(dá)時,不會返回任何Player，這時如果試圖構(gòu)建一個Realized Player將會無限制地阻塞下去。播放器根據(jù)解壓后數(shù)據(jù)的格式、尺寸、幀頻等參數(shù)再現(xiàn)圖像，還可通過時間戳實現(xiàn)視音頻同步。這里采用相應(yīng)算法的解壓縮插件實現(xiàn)。 DataSource ds = ()。// 得到加入者（發(fā)送者）ReceiveStream stream = ()。RTPManager mgr = (RTPManager)()。緊接的是客戶端的程序流程圖，程序流程圖描述了，從界面接收IP地址和端口號，設(shè)置監(jiān)聽器，當(dāng)監(jiān)聽到有數(shù)據(jù)流到來時，接收數(shù)據(jù)流并實時播放。例如，當(dāng)應(yīng)用程序需要在Player或Processor中調(diào)用一個異步方法的時候，它需要監(jiān)聽合適的事件以確定操作何時完成。（6）調(diào)用start讓Player進(jìn)入開始(Started)狀態(tài)。（5）當(dāng)Player完成Prefetching時，進(jìn)入已預(yù)?。≒refetched）狀態(tài)。（4）當(dāng)調(diào)用prefetch時，Player從Realized狀態(tài)進(jìn)入到預(yù)?。≒refetching）狀態(tài)。Realized的Player知道它需要的資源以及要回放的媒體類型。處于Realizing的Player通常從網(wǎng)絡(luò)中下載資源。在這個過程中，Player獲取僅需要它一次獲取的那些資源。（2）調(diào)用realize時，Player從Unrealized狀態(tài)轉(zhuǎn)換到實現(xiàn)（Realizing）狀態(tài)。圖中各個狀態(tài)的含義如下：（1）處于未實現(xiàn)（Unrealized）狀態(tài)時，Player已經(jīng)初始化，但還不知道媒體內(nèi)容的任何信息。）JMF采用圖中的六個狀態(tài)控制Player的回放進(jìn)程。PFCE(PrefetchCompleteEvent)事件。JMF將Player的回放過程分成六個狀態(tài)，Player總處于其中的一個狀態(tài)。Player對象用于處理媒體流并將它傳遞到輸出設(shè)備。在這個模型中，會話進(jìn)程管理（Session Manager）負(fù)責(zé)跟足蹤會話進(jìn)程的參與者及其傳輸?shù)拿襟w流。無論是發(fā)送端的還是接收端的IP地址都必須是Internet上合法有效的IP地址和端口號。 } } } }在服務(wù)器端運行發(fā)送端程序,在界面上相應(yīng)標(biāo)簽處輸入發(fā)送數(shù)據(jù)流所需參數(shù):接收端的IP地址、發(fā)送端口。 i++) { // 刪除所有RTP管理器 rtpMgrs[i].removeTargets( Session ended.)。 for (int i = 0。 // 停止處理器 ()。 停止傳輸流媒體 停止傳輸媒體流程圖傳輸結(jié)束或人為中止傳輸時,停止會話、刪除所有RTP會話管理器。//獲得具體的異常名稱 } } return null。 // 產(chǎn)生數(shù)據(jù)源的RTP傳輸流 ()。 // 加入目的會話地址 ( Created RTP session: + ipAddress + + port)。 // 得到目的機器的會話地址 rtpMgrs[i].initialize( localAddr)。 // 得到發(fā)送目的地的IP地址 SessionAddress localAddr = new SessionAddress( (),port)。 int port = portBase + 2 * i。 i 。 //得到“Push”數(shù)據(jù)流//建立RTPManagertpMgrs = new RTPManager[]。 PushBufferDataSource pbds = (PushBufferDataSource)dataOutput。數(shù)據(jù)傳輸過程中的控制信息通過RTCP包傳送[8]。所有要傳輸?shù)臄?shù)據(jù)要先處理成符合RTP標(biāo)準(zhǔn)的數(shù)據(jù)包，然后通過網(wǎng)絡(luò)發(fā)送到客戶機的相應(yīng)端口。 流媒體的實時傳輸 流媒體的傳輸流程圖 發(fā)送和接收是實現(xiàn)視音頻網(wǎng)絡(luò)傳輸?shù)年P(guān)鍵，傳輸協(xié)議的不同直接影響傳輸延時。 } return(new VideoFormat(null,new Dimension(width,height),null,)).intersects( supported)。 height = 288。 height = 144。 height = 96。Format h263Fmt = new Format()。[19]。用硬件速度快、不占用CPU，但需要相應(yīng)的壓縮卡。 流媒體的壓縮 流媒體壓縮的流程圖采集設(shè)備輸出的數(shù)字信息是原始信息，數(shù)據(jù)量大，不適于網(wǎng)絡(luò)傳輸，需要先采用適當(dāng)?shù)膲嚎s算法進(jìn)行處理，這是適用于低帶寬網(wǎng)絡(luò)的關(guān)鍵。然后調(diào)用getLocator產(chǎn)生一個媒體定位器（媒體源）。通過調(diào)用CaptureDeviceManager的getDeviceList方法獲取可用的捕獲設(shè)備列表。 //從設(shè)備管理器得到媒體源用到JMF提供的模型截取設(shè)備（Capture Device,包括視頻和音頻截取設(shè)備）。 //注冊攝像頭設(shè)備名稱用來確定設(shè)備的位置device = (str2)。編程時首先要識別設(shè)備，設(shè)定所采圖像的幀大小、幀頻率、編碼類型等參數(shù)。整個程序流程圖描述了，從界面接收IP地址和端口號，自動定位媒體源，產(chǎn)生RTP會話以及發(fā)送RTP數(shù)據(jù)流。 服務(wù)器子系統(tǒng)界面上面是發(fā)送端界面的實際效果圖。在順利接收流媒體數(shù)據(jù)一段時間之后,客戶端嘗試使用流量更高的組合接收數(shù)據(jù),并在得到一個合適的流量后為止。客戶端使用上述數(shù)組中的組合進(jìn)行嘗試接收數(shù)據(jù),直到得到一個合適的流量為止,這里所謂合適的流量是指,此流量是該客戶端可以接收到的最好質(zhì)量數(shù)據(jù)流量。)客戶端加入會話以后,首先加入端口號最小的層中接收流媒體數(shù)據(jù),這時客戶端得到主觀質(zhì)量最差的視頻流。Port1Portn:16位，表示各層的RTP端口號。,編碼后的碼流流量有可能有所變化,所以流媒體服務(wù)器需要及時通過RTCP APP數(shù)據(jù)包通知各客戶端系統(tǒng)中各層的數(shù)據(jù)流量。,幀率依次增加。 本文提出的控制方法基于分層的擁塞控制是指客戶端如何選擇加入和退出各層從而得到一個合適的網(wǎng)絡(luò)流量。在這樣的機制中，可以在傳輸?shù)拇a流中加入用于糾錯的冗余信息，在遇到包丟失的情況時，利用冗余信息恢復(fù)丟失的信息。空域的恢復(fù)使用同一幀的鄰近區(qū)域來重新組建丟失的碎片；時域的恢復(fù)使用前一幀的相應(yīng)區(qū)域來替代丟失的區(qū)域信息。 以上方法是通過調(diào)整幀內(nèi)編碼和幀間編碼的幀的混合程度來使包丟失對視頻效果的影響最小化。在這樣的機制中，可以在傳輸?shù)拇a流中加入用于糾錯的冗余信息，在遇到包丟失的情況時，利用冗余信息恢復(fù)丟失的信息?？沼虻幕謴?fù)使用同一幀的鄰近區(qū)域來重新組建丟失的碎片；時域的恢復(fù)使用前一幀的相應(yīng)區(qū)域來替代丟失的區(qū)域信息。于是，人們提出了三種方法來解決這一問題：①通過調(diào)整幀內(nèi)編碼和幀間編碼的幀的混合程度來使分組丟失對視頻效果的影響最小化。如對于MPEG，一個包的丟失可能會造成大量幀的質(zhì)量下降，直到下一個幀內(nèi)編碼的幀被正確接收為止。差錯控制機制力圖減少目的端包丟失對視覺效果造成的損害。這種機制使用較少。然而，這種基于源端的機制在異構(gòu)網(wǎng)絡(luò)中的運行情況并不是很好。在基于源端的控制機制中，流媒體源端收集反饋信息，進(jìn)行控制計算并采取相應(yīng)的控制動作。這樣可以同時使網(wǎng)絡(luò)擁塞最小和分組丟失率最小。對于可用帶寬和包丟失的處理，現(xiàn)在主要有速率控制和差錯控制機制。同時，基于流的IP交換機制也是解決這一問題的重要方法之一。對于流媒體傳輸來說，重要的信道特性是端到端時延、可用帶寬和分組丟失率。由于資源預(yù)留的代價較大，所以通常對較重要的數(shù)據(jù)采用預(yù)留的方式通信，而對于其余數(shù)據(jù)采用自適應(yīng)的方法處理。例如，自適應(yīng)可以被用在很難對資源提前做出精確估計的情況中。該方法正被廣泛應(yīng)用在現(xiàn)有的網(wǎng)絡(luò)中。2．根據(jù)當(dāng)前的網(wǎng)絡(luò)狀態(tài)調(diào)整應(yīng)用程序使用的帶寬實現(xiàn)相應(yīng)的自適應(yīng)操作。這需要在網(wǎng)絡(luò)中實現(xiàn)具體的資源分配和預(yù)留機制，許可控制機制及特殊的調(diào)度機制。另一方面，由于UDP協(xié)議沒有任何擁塞控制機制，高帶寬要求的網(wǎng)絡(luò)多媒體應(yīng)用程序往往會成為因特網(wǎng)的負(fù)擔(dān)，并且可能占用基于TCP上的應(yīng)用程序本應(yīng)平等分得的那份帶寬資源。在提供無差別的、盡力而為的服務(wù)，且無任何QOS支持機制的網(wǎng)絡(luò)中，可用帶寬、時延和丟包率都是時變參量。流媒體傳輸控制的特點給傳統(tǒng)網(wǎng)絡(luò)提出了許多要求。而一小段多媒體數(shù)據(jù)的丟失往往不會造成嚴(yán)重的后果，再加上為保證數(shù)據(jù)的實時特征，一般不要求數(shù)據(jù)重發(fā)，所以對差錯控制的要求很低。三、普通數(shù)據(jù)的傳輸服務(wù)可以隨時改變傳輸速率，而連續(xù)的多媒體數(shù)據(jù)的傳輸服務(wù)必須有幾十秒的適應(yīng)階段，以避免由于速率的突然改變而引起質(zhì)量的明顯改變。而普通數(shù)據(jù)傳輸?shù)耐掏铝靠梢栽诤芏痰臅r間內(nèi)減少到接近為零。一、傳輸高質(zhì)量的流媒體信息需要高網(wǎng)絡(luò)帶寬的支持