結論與相關探討

對於本章的第一節，本論文點出在此系統，處理影音資料總共會用到9個 thread，處理影像使用5個thread，處理音訊使用4個thread。讀者一定感到困惑，

為什麼一定要用到9個thread，一個或是3~4個thread不行嗎?或是，使用更多的 thread不也一樣可以嗎?

當只使用單一thread，在所有子系統的暫存器間，往返搬運媒體資料，所有 的執行順序都必須依序執行，以此系統為例，自camera抓取媒體資料，放入 parser，作資料壓縮，送入網際網路，這一連串的程序是相當冗長的。當程式執 行至將封包送入網際網路時，程式必須要回到最初的子系統物件，也就是自 camera抓取媒體資料，當程式要回到此程序時，必須要經過多層函式的呼叫，

才能回到此程序，因此就浪費了許多時間在做多層函式的呼叫，整個程式的效率 就會相當的差，相對的接收端做播放時就會有很大的延遲，因此本研究不使用單 一thread。

本研究是依子系統的各別功能，而由專屬的thread來執行任務，為了就是要 解決上述的問題，只要thread所要執行的是多個程序，就會發生上述效率變低的 問題。但若所使用的thread過多呢?此種情形，就會浪費作業系統的資源，每一 個thread都會佔有一記憶體的位置，也就是當產生一新的thread就會消耗記憶體 空間，切換thread時會產生額外的負擔，因此不應該使用過多的thread。

(2)排程機制的選擇

本研究所選用的排程機制是自定排程，並且配合Java虛擬機的標準排程機 制，並不使用Round Robin或Time Sharing等排程機制。以Round Robin來說，

雖然子系統應該會照著一定的順序執行，但在一些條件下希望能讓給其它thread 先執行，例如前面所提及SourceThread會將壓縮完成的資料放入多工器的暫存 器中，當發現此媒體資料是結尾時，就會鎖住此thread，讓其它thread先執行。

或是當多工器的暫存器以被寫滿時，會由其它thread將資料讀出，再將後緒未完 成壓縮的資料寫入多工器。

以Time Sharing 來說，我們很難預測每一個 thread 要執行多久，很有可能 有些thread 處理媒體資料時，還未處理完成，其執行權就由 Java 虛擬機收回了，

因此，此種排程機制並不適合本系統。

(3)優點與缺點

在本章節中，我們可以觀察到thread(1)~(4)並沒有依照順序執行，完全是 依照作業系統、資料壓縮和暫存器當時的實際情況而執行的。在實際的系統中，

是無法保證當時作業系統的狀態或是網路的狀態，舉例來說，在網路發生壅塞 時，thread(4)暫時無法送出封包，而先交由其它的 thread，因此在等待 thread(4) 可以執行前，可以由其它的thread 執行其它任務，才不會有整個系統停止運作

的情形發生。

但是，以處理一張照片的觀點來看，因multithread 可能無法依序執行，因 此使得處理的時間變長，此是因為處理每一張照片的時間都有重疊到，當處理此 次的照片時可能為下一次的處理做準備，因而拉長了此次處理照片的時間。

第五章 結論

由本論文的第二章到第三章中，可以了解到擷取影音資料，直到傳送至遠方 用戶端所需的處理程序。其中包含了許多領域的相關知識，如各種影音壓縮知 識、網路程式設計和通訊協定。探討藉由JMF API對於處理原始的媒體資料，在 每一個階段所提供的功能，以及Java Socket所提供有關於Socket API套件。

整個系統的運作，藉由建立數個thread 和 thread 的同步機制，我們可以達 到對數個thread 某種程度上的控制，使得 thread 之間相互合作，所有的子系統 達到制衡，換句話說就是thread 之間達到制衡以執行資料的傳遞，使得系統整 體比較單一thread 執行效率較高。

經由第四章的試驗，可以了解到要控制camera 適當的休眠時間是不太容易 的，必須要考慮到CPU 的使用率和抓取照片的時間點。利用 drainSync.wait(time) 的機制可以改善即時傳輸的效益。以暫存器來做為thread 之間溝通的橋樑可以 使得負責儲存封包的暫存器不需要太大，利用thread 之間的制衡達到暫存器再 利用的好處。

由於本論採用為主動傳輸串流資料至接收端，建立RTP封包送至遠方的用戶 端，傳輸端與用戶端之間並無連線溝通的程序，因此只達到作為主動傳輸多媒體 資料的系統，並未提供伺服器的功能，因此還有很大的發展空間。

若要將本論文所提的系統發展為一串流伺服器，可藉由2.5.1節所介紹的 Java Stream Socket API建立伺服端，使用API的相關函式處理用戶端主動連線 的要求，再由本論文所提傳輸多媒體串流資料的系統作為OSI中的Transport layer傳送RTP封包至用戶端。

若希望能同時接受數個用戶端的要求，可配合3.6節Java Thread，對於每個 用戶端的要求，由一thread來處理，就可以達到伺服端處理多個用戶端連線的要 求。以上都是本論文未來可以更進一步去研究的幾個方向。

參考文獻

[1]Java 網路程式設計 作者:黃嘉輝 出版:文魁 [2]http://java.sun.com/j2se/1.5.0/docs/api/

[3]Java 網路程式設計 作者:elliotte Rusty Harold 譯者:蔣大偉 出版: 歐萊禮 [4]H. Schulzrinne, Columbia University, “RTP: A Transport Protocol for

Real-Time “,RFC3550. Titl, July 2003.

[5]http://java.sun.com/products/java-media/jmf/index.jsp

[6]Java Thread 深度探討 作者:Soctt Oaks&Henry Wong 譯者:楊尊一 出版: 歐萊禮

[7]Java2 物件導向技術專題 Design Pattern、Framework、Multithread、

Concurrent 作者:戶松豊和 譯者:李于青 出版:博碩

[8]Java 虛擬機深入解析 作者:Bill Venners 譯者:葛湘達 出版:麥格羅.希爾 [9]http://www.ietf.org/rfc/rfc2190.txt

附件一 Thread 順序和時間量測的數據

附件二 暫存器空間不足的特例

297(millisecond)

bQ3 不足

附件三 SourceThread(V)封鎖試驗 (1)無設置時的情況

連續 壓縮 2 張 照片

(2)設置 10 秒時的情況

(3)設置 20 秒時的情況

(4)設置 40 秒時的情況

自傳

韓孟潔，民國七十年生於屏東市。民國九十三年畢業於國立高雄應用科技大 學電機工程學系，於民國九十四年八月進入國立交通大學通訊與網路科技產業研 發碩士班就讀。民國九十六年八月取得碩士學位，論文題目是「多執行緒在多媒 體串流的應用」。

研究興趣是 Java/C/C++程式開發，希望可以達到恣意揮灑的境界；生活興 趣靜態方面:看電影、卡通、布袋戲，動態方面:籃球、棒球、游泳、田徑。