動態頻寬管理視訊串流伺服器

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文. 指導教授：. 黃文吉. 博士. 動態頻寬管理視訊串流伺服器 A Video Streaming Server with Dynamic Bandwidth Management. 研究生：. 陳. 祜. 中華民國. 九十七. 琦年. 撰六. 月.

(2) 中文摘要. 中文摘要本論文中將結合視訊串流伺服器(Video Streaming Server)及我們所發展的動態頻寬管理視訊串流法則(Dynamic Bandwidth Video Streaming Management)，讓視訊串流系統在調節頻寬的時候可以達到以下兩點目標： (1) 當總流量超過安全範圍，調節頻寬時可最小化視訊品質之降低。 (2) 頻寬充足時，調節頻寬且最大化的提昇視訊品質。. 另外，我們撰寫了一個使用本演算法則之視訊串流伺服器模擬程式以及建立了一個使用本演算法的視訊串流伺服器。而本論文將分析比較模擬所獲得的數據及實際運作時所量測到的數據，證明本論文所提出之演算法則是有效的。. 關鍵詞：Dynamic Bandwidth Management, Streaming Server. I.

(3) 英文摘要. ABSTRACT. In this thesis, we propose a bandwidth management algorithm and implement a video streaming server with this algorithm. We want the system can achieve two goals as follows: (1) When total used bandwidth of video streaming server is over safety area, video streaming server will manage bandwidth and minimize video quality decadence. (2) When total used bandwidth of video streaming server is under safety area, video streaming server will manage bandwidth and maximize video quality increase. In order to verify this algorithm, we implement a video streaming system simulate program using the algorithm and also implement a positive video streaming system. We will test these two systems in several scenarios and get some measurements. According to those measurements, it can be observed that the algorithm is effective and useful.. Keywords：Dynamic Bandwidth Management, Streaming Server. III.

(4) 英文摘要. 致謝. 非常感謝黃文吉老師在這兩年間對我不辭辛勞的指導，讓我無論是在專業上或者是待人處事都獲益良多。這段學習的時間有很多的成長與體驗，是我人生旅途中美好的回憶，老師非常感謝您！同時很感謝已畢業的學長威智、瑞鴻、一志、映男及汶錫還有其他許多的學長姐們謝謝你們的教導，很榮幸能當你們的學弟，也感謝韋德、小賴、凱富、永隆、智傑、定寬及慧雅同學們，我們一路走來的歡笑甘苦我會永遠當做美好的回憶。也感謝可愛的學弟正存、大雕、家璿以及很多的學弟妹們的幫助，謝謝。當然柏諺、楊公、雨農、建富與你們相處並且互相鼓勵的時光也是我永遠無法忘記的。同時在這裡，我想要感謝我最愛的女朋友怡君，這麼多年來謝謝妳在身邊的陪伴，不管是學業還是生活上的互相扶持，因為有妳所以讓我有更美好的人生，也因為有妳讓我可以在最困難的時候沒有放棄，謝謝妳。最後要感謝我的家人們，謝謝您們，因為你們遠在台南，我不能陪在你們身邊，但你們卻是我幾年來最大的支持，將此論文獻給親愛的你們。. IV.

(5) 目錄. 目錄中文摘要英文摘要目錄致謝第一章. 緒論. 1.1. 研究背景及動機...........................................................................................1. 1.2. 研究方法及目的...........................................................................................5. 1.3. 論文架構.......................................................................................................7. 第二章 2.1. 基礎理論介紹串流媒體與相關技術...................................................................................8. 2.1.1 串流媒體簡介.......................................................................................8 2.1.2 支援串流媒體之傳輸協定..................................................................11 2.1.3 串流媒體伺服器..................................................................................13 2.1.4 Codec 與 Container format................................................................16 2.1.5 固定與可變 BitRate.............................................................................17 2.2. Video Lan Client (VLC)..............................................................................18 2.2.1. 簡介...................................................................................................18 V.

(6) 目錄 2.2.2. 第三章 3.1. 3.2. 第四章. 程式功能模組....................................................................................20. 系統架構動態頻寬管理視訊串流法則...................................................................22 3.1.1. 群組架構.........................................................................................23. 3.1.2. Merge 程序......................................................................................25. 3.1.3. Split 程序.........................................................................................29. 實現法則之視訊串流系統架構…...........................................................33 3.2.1. 模組介紹….....................................................................................33. 3.2.2. 串流伺服器架構….........................................................................36. 實驗數據與系統效能分析. 4.1. 模擬情境說明..........................................................................................38. 4.2. 串流系統測試說明..................................................................................40. 4.3. 頻寬調節分析..........................................................................................42. 4.4. PSNR 分析...............................................................................................46. 第五章. 結論與未來展望. 5.1. 結論..........................................................................................................50. 5.2. 未來展望..................................................................................................51. 參考文獻..................................................................................................................52. VI.

(7) 目錄. 附圖目錄圖 2-1 多媒體串流架構圖..........................................................................9 圖 2-2 串流傳送端之處理過程..................................................................9 圖 2-3 接收端之處理過程........................................................................10 圖 2-4 QuickTime Streaming Server(1).....................................................13 圖 2-5 QuickTime Streaming Server(2).....................................................14 圖 2-6 Muxer / audio and video formats matrix.........................................16 圖 2-7 VLC 解決方案................................................................................18 圖 2-8 VLC 所支援之媒體格式................................................................19 圖 2-9 VLC 所支援之串流格式................................................................20 圖 2-10 VLC 作多媒體串流時模組運作架構..........................................21 圖 3-1 群組架構.........................................................................................23 圖 3-2 Merge 程序虛擬碼…......................................................................28 圖 3-3 Merge 程序流程圖..........................................................................28 圖 3-4 Split 程序虛擬碼.............................................................................30 圖 3-5 Split 程序流程圖.............................................................................31 圖 3-6 串流系統之有限狀態機.................................................................32 圖 3-7 行為模擬模組運作流程.................................................................35 VII.

(8) 目錄圖 3-8 系統架構圖.................................................................................36 圖 3-9 系統運作流程.............................................................................37 圖 4-1 情境一、二之頻道數據.............................................................39 圖 4-2 串流系統測試畫面(一)..............................................................40 圖 4-3 觀看介面.....................................................................................41 圖 4-4 串流系統測試畫面(二) [模擬使用者].......................................41 圖 4-5 串流系統測試畫面(三) [模擬使用者].......................................41 圖 4-6 頻寬調整狀態[情境一-模擬程式].............................................42 圖 4-7 頻寬調整狀態[情境一-串流系統].............................................42 圖 4-8 頻寬調整狀態[情境二-模擬程式].............................................43 圖 4-9 頻寬調整狀態[情境二-串流系統].............................................43 圖 4-10 實測值與模擬值比較[情境一-系統流量]...............................44 圖 4-11 實測值與模擬值誤差[情境一-系統流量]...............................44 圖 4-12 實測值與模擬值比較[情境二-系統流量]..............................44 圖 4-13 實測值與模擬值誤差[情境二-系統流量]..............................44 圖 4-14 頻寬調整狀態(串流系統)[情境三].........................................45 圖 4-15 PSNR 值分析圖[情境一-模擬程式]........................................46 圖 4-16 PSNR 值分析圖[情境一-串流系統]........................................46. VIII.

(9) 目錄圖 4-17 PSNR 值分析圖[情境二-模擬程式]............................................47 圖 4-18 PSNR 值分析圖[情境二-串流系統]............................................47 圖 4-19 實測值與模擬值比較[情境一- PSNR 值分析圖] ......................48 圖 4-20 實測值與模擬值誤差[情境一- PSNR 值分析圖] ......................48 圖 4-21 實測值與模擬值比較[情境二- PSNR 值分析圖] ......................48 圖 4-22 實測值與模擬值誤差[情境二- PSNR 值分析圖] ......................48 圖 4-23 PSNR 值分析圖 (模擬程式)[情境三] ........................................49. IX.

(10) 第一章緒論. 第一章緒論在本章中，我們將說明本論文研究的背景與動機，並簡單的介紹本論文研究的方法與目的，最後並介紹本論文各章節的架構。. 1.1 研究背景及動機隨著網際網路頻寬的增加，視訊串流(Video Streaming)[2][3][4][5]的相關應用及研究獲得了極大的重視，視訊串流服務也蓬勃發展，諸如近來世界知名的視訊服務網站 youtube、日本知名的視訊服務網站 NicoNcio 以及台灣電信龍頭中華電信的視訊服務頻道 HiChannel 都是典型的視訊串流服務。在網際網路上的資料傳輸方式有三種，單點傳播(Unicast)、廣播(Broadcast) 及多點廣播(Multicast)，其分述如下 (1) 單點傳播(Unicast)：指資料傳輸的目的節點 (destination node) 只有一個。現有一般的串流應用，常用此種方式來傳送資料。 (2) 廣播(Broadcast)：將資料傳輸到指定的目的網路上, 而在目的網路上的所有節點皆為目的節點。 (3) 多點廣播(Multicast)：將資料傳送給某一特定群體 (Group) 的所有成員 (members)，而屬於同一群體的各個成員可能是散佈在各個不同的網路上。在 RFC1112 這份文件中，定義了其內容。. 1.

(11) 第一章緒論現有的視訊串流服務大多是根據 Content Delivery Network(CDN)[1]之 Client-Server Model 方式，傳送單點傳播(Unicast)之視訊串流給每一位視訊串流使用者，而使用此種串流架構具有以下的缺點： (1) Flash Crowds[1][5]：當伺服器在短時間內忽然湧入大量視訊串流需求，稱之。例如在節目剛開始之時，使用者有可能會在這段時間內大量連進視訊串流伺服器，即使強大的伺服器仍舊可能無法負荷住需求。 (2) Single Point of Failure[1] [5]：對於 Client-Server Model 的架構而言，一但因為意外造成伺服器當機或是受到攻擊，則會造成整個串流系統的毀壞或是不穩定。 (3) Bandwidth Cost[1] [5]：在 Client-Server Model 架構下伺服器是提供視訊串流的唯一來源，因此伺服器的流量即為整個網路系統的瓶頸，整個串流系統的效能取決於伺服器的頻寬，為應付大量的視訊串流需求，串流伺服器的提供廠商常常必須跟網路頻寬的提供者 (ISP)租用大量的頻寬。雖然使用此種架構有上述的缺點，但現實中大多數串流服務提供者仍然使用此種架構，因為此種架構有它的方便性及穩定性。. 2.

(12) 第一章緒論首先，使用多點廣播(Multicast)雖然可以有效減低網路的頻寬，但多點廣播 (Multicast)在現實的網路環境中，有多數網路設備並不支援的問題，因此不能保證用戶端可以使用多點廣播(Multicast)的技術。其次，廣播(Broadcast)只適用於 Lan 的環境下，並不適用於一般大眾的使用環境。最後是最近極為熱門的網路技術─點對點技術（peer-to-peer，簡稱 P2P）[5]，點對點技術在串流上的應用潛力不可小覷，但是現階段卻有一些重要的問題待突破，以下簡述幾點： (1) 分享問題：P2P 的技術最大的好處在於每位使用者不單單只是接收端也同時是提供串流內容的傳送端，此種方法可以有效解決串流伺服器需要大量頻寬的問題。但如果每位使用者都躲在 NAT 底下而不能提供分享或是自行設定不分享，那 P2P 的架構就會退回到傳統的 Client-Server Model。 (2) 安全問題： . P2P 軟件本身即為木馬程式。. . 身份攻擊(identity attacks)：跟蹤網絡上之用戶，並且進行騷擾式或是入侵式的攻擊。. 上述幾點是點對點技術安全問題的一些例子。. 3.

(13) 第一章緒論 (3) ISP 端的問題：因為 P2P 技術會大量的佔用頻寬，所以大多數的 ISP 會對 P2P 技術做限制，如限制 TCP 連接數，封鎖 P2P 協議，限制下載/上傳速度等。因為以上的技術都有待解決的問題，所以到現在為止大多數的串流服務提供者依然是使用 Client-Server Model[1]方式，傳送單點傳播(Unicast)的視訊串流給視訊串流使用者。而使用 Client-Server Model 方式有一個最重要的問題─Bandwidth Cost，為了容納更多的使用者，串流服務提供者必須要跟 ISP 租用更多的頻寬。此外，當串流服務提供者超用租用頻寬時，還必須给付超過頻寬的罰款給 ISP，因此頻寬的管理是一件極為重要的事情。. 4.

(14) 第一章緒論. 1.2 研究方法及目的為了改善超出頻寬的問題以及在有限頻寬下服務更多的使用者，現有常見之視訊串流伺服器通常使用變動位元之視訊串流方式調整使用頻寬(如 Windows Server 2003 中的 Windows Media Services)，此種調整方式有幾個問題可以討論： . 變動一個頻道的視訊串流位元數，會直接影響到許多使用者所收看到的畫質，此作法並沒有對調節頻寬與損失的視訊品質做平衡。. . 當大量使用者離開頻道時，串流伺服器沒有辦法馬上做反應，調整串流品質。. 因為如此，在本篇論文中我們將解決的問題是： (1) 當總流量超過安全值，調節頻寬時可最小化視訊品質之降低。 (2) 頻寬充足時，調節頻寬且最大化的提昇視訊品質。為了解決這些問題，我們提出了一個多頻道多群組的視訊串流伺服器架構，同時使用動態頻寬管理視訊串流法則來調節我們的視訊串流伺服器。在本論文中，我們撰寫了一個多頻道多群組的視訊串流架構模擬器。我們的模擬系統特色在動態的隨機模擬，每位視訊串流使用者會隨機的選擇一個頻道及頻道中不同畫質的群組，並根據所設定的機率在一段時間內模擬使用者轉台的動作。另外此模擬系統也提供設定不同機率的情境劇本，來模擬使用者在不同情境. 5.

(15) 第一章緒論下的行為模式(如多數使用者快速加入體育頻道的情境、多數使用者漸漸離開伺服器之情境)。而本論文實現之視訊串流伺服器(Video Streaming Sever)會依據使用者的使用狀況，以及伺服器現有的頻寬及設定之參數去調整頻道的群組，達到限制頻寬流量的目的，同時提供給使用者品質落差小的視訊串流服務。且本論文實現之視訊串流伺服器另外擁有一個特色，此特色為自動行為模擬之 Client 端，這些 Client 端使用 Ajax 技術[13]，可以讓我們套用模擬程式時所使用的情境劇本，自動操作諸如轉台、停止收看之類的動作，此 Client 端技術讓我們在做系統測試時方便許多。. 6.

(16) 第一章緒論. 1.3 全文架構本篇論文共分為五章，以下分別為各章的標題及內容概述：【第一章】緒論本章主要說明本論文的研究背景及動機，並對本論文的研究方法和目的做概觀的簡介。【第二章】基礎理論介紹本章將介紹本論文所應用的到一些先備知識(如視訊串流)及對本論文所使用的 Streaming Server(Video Lan Client)作介紹。【第三章】系統架構在本章中將介紹本論文實現之視訊串流系統架構，還有我們提出之動態頻寬管理視訊串流法則。【第四章】實驗數據及系統效能分析本章中將利用本論文的模擬系統產生出多種不同情境下之數據然後跟本論文所實現的串流系統所得之數據做比較及相關討論。【第五章】結論與未來展望本章將對本論文做出總結，提出某些應該改進的地方，同時也提出本系統可能延伸之部分。. 7.

(17) 第二章基礎理論介紹. 第二章基礎理論介紹在本章中我們會介紹本論文所用到的串流技術及所使用的視訊串流伺服器，幫助我們在檢視本視訊串流系統架構時，可以有更深入的了解。. 2.1 串流媒體與相關技術隨著科技發展，網路時代來臨，人們時常利用各式各樣的裝置(如 PC、PDA、 Notebook)，透過網路連線隨時隨地的存取網路上的資源。以網路發展的趨勢來看，從文字(BBS)瀏覽到影像(HTML)瀏覽，到多媒體影音資料的傳輸(Movie)。多媒體傳輸的發明是重要的技術突破，其對網路世界的衝擊，也發揮出極強大的影響力(如 youtube 的發展)。. 2.1.1串流媒體簡介多媒體檔案(如影片、電視直播、音樂)的檔案容量通常都較為龐大，如果採用一般的下載方式來進行傳輸，必須要等到完全下載完後才可以觀看，會花費過多的等待時間，另外在某些儀器上儲存媒體比較小(如 PDA)，也沒有辦法支持此種方式，為了解決以上的問題便開始發展了多媒體串流技術(Media Streaming)。多媒體串流，係利用串流技術在網路環境上傳輸多媒體檔案。透過串流技術傳輸影音多媒體，可讓使用者無須下載完整檔案，便可以一邊下載一邊播放，讓使用者節省下大量的等待時間。. 8.

(18) 第二章基礎理論介紹為了避免傳輸上的問題造成播放中斷，目前的串流機制都會在使用者端建立緩衝區(Buffer)，播放程式便取用緩衝區的資料，以維持播放的順暢及品質。. 圖 2-1 多媒體串流架構圖圖 2-1 所示為多媒體串流架構，此架構最主要有幾個模組：壓縮模組、串流伺服器與收視端的撥放器。壓縮模組主要功能是將多媒體資料做壓縮，壓縮成可以在網路上傳送的格式及大小，因此壓縮模組可說是整個系統的核心。串流伺服器主要功能是提供串流的建立、管理與傳送。接收端播放器主要負責接收及解壓縮然後播放多媒體串流。圖 2-2 及圖 2-3 為串流傳送端的與接收端之處理過程。如圖 2-2 所示，傳送端透過訊號來源(擷取裝置如電視卡、攝影機或是本地端的多媒體檔案)獲得多媒體資料，影像部分先透過串流伺服器轉換成多媒體串流的資料格式，之後透過網際網路傳輸這些封包。. 圖 2-2 串流傳送端之處理過程 9.

(19) 第二章基礎理論介紹如圖 2-3 所示，接收端透過網際網路接收到影像及聲音資料，先將這些封包存放到緩衝區(Buffer)中，透過同步裝置將聲音與影像資訊同步，最後再由播放器輸出多媒體資訊。. 圖 2-3 接收端之處理過程多媒體串流主要應用模式有兩種：即時傳輸(On Live)與隨選傳輸(On Demand)，分述如下[4][5][6]： . 即時傳輸(On Live)：訊號來源經過壓縮後，隨即利用伺服器，經由網路傳送到播放器。標準的應用範例有雙向的視訊會議、電視頻道的轉播以及即時監控。. . 隨選傳輸(On Demand)：媒體經過壓縮處理後，存放在伺服器的資料庫內，當使用者向伺服器提出播放要求時，伺服器才經由網際網路傳送到使用者手上。標準的應用範例有隨選視訊、線上音樂商店(iTune)。. 10.

(20) 第二章基礎理論介紹. 2.1.2支援串流媒體之傳輸協定目前串流技術大致可分成三類： . 第一類串流技術：係利用網頁伺服器，將多媒體資料送的使用者手上。因為網頁伺服器使用 HTTP(HyperText Transfer Protocol )通訊協定，所以此種方式又稱 HTTP Streaming。使用此種方式的好處是不需再另行建置串流伺服器，這種方式也是最先在市場上出現的串流方式。因為使用 HTTP 協定不容易偵測當時網路環境，所以必須先備妥不同速率的資料，以適用於不同頻寬的網路。又因為 HTTP 使用 TCP(Transmission Control Protocol)通訊協定，當傳輸資料遺失時會要求重傳，因此會形成延遲(delay)。. . 第二類串流技術：係利用獨立的串流伺服器，將多媒體資料送到使用者手上。因為此種方式是使用 RTP(Real Time Protocol)通訊協定，所以稱為 RTP Streaming。RTP 是網際網路上針對多媒體資料串流所發展一種傳輸協定。RTP 會以一定速率，傳送一條串流到使用者手上，只要有足夠的頻寬，使用者可以立即的播放資料，播放完畢資料就會消失，要再次觀賞必須透過再次連線。. . 第三類串流技術：播放器不內建在用戶端，而是在串流過程中才送到使用者手上，此類應用技術主要在行動裝置上使用，尤其是 Java 平台。這類應用不需要在用戶端安裝太多程式，只有在需要使用時，才將 Java. 11.

(21) 第二章基礎理論介紹版的撥放器送到用戶端並且播放串流。其中 RTP 傳輸由於使用 UDP(User Data Protocol)，所以會比 TCP 快速且有效率，因此可以減少延遲現象。但是 UDP 有兩點缺點： . UDP 缺乏回報機制，所以在網路上幾乎都會有封包遺失的狀況，此種問題會造成品質下降。. . 大多數的防火牆都會擋掉 UDP 封包，所以在防火牆內無法接收到由 UDP 傳送之串流。想要穿越防火牆必須使用 HTTP tunneling 的技術，即將 RTP 包裹在 HTTP 封包中，以方便穿越防火牆。但是此種方法會增加額外的資訊，導致佔掉更多的頻寬。. RTP 又可以搭配 RTSP(Real Time Streaming Protocol)讓使用者透過 RTSP 來下指令給伺服器作像是『暫停』、『快轉』、『到帶』等等的動作。. 12.

(22) 第二章基礎理論介紹. 2.1.3串流媒體伺服器目前支援收發與播放串流媒體的產品繁多，如蘋果電腦的 QuickTime Streaming Server、RealNetwork 公司的 Helix Server 以及微軟的 Windows Media Services 最為常見，而本論文使用的是 Open Source 的 Video Lan Client，以下簡述其特色： . QuickTime Streaming Server 利用開放標準，QuickTime Streaming Server [7]能夠透過網際網路提供即時. 或是預錄的多媒體資料。藉由 Instant-On 這個創新串流技術，使用者點選的的內容會在其連結點選時立刻播放，不需等待檔案下載完畢。. QuickTime 檔案屬於高畫質，因此檔案大小相對較大。網路頻寬小的使用者觀看上會比較吃力，而且因為 QuickTime Player 所需的系統資源較高，因此較不適用於行動裝置。電影預告、產品展示等需要高畫質表現的用途常常使用其支援之格式。. 圖 2-4 QuickTime Streaming Server(1) 資料出處：http://www.apple.com.tw/quicktime/streamingserver/ 13.

(23) 第二章基礎理論介紹. 圖 2-5 QuickTime Streaming Server(2) 資料來源：http://www.apple.com.tw/quicktime/streamingserver/. . Windows Media Services Windows Media Services[8]為微軟內附於 Windows 2003 server 之串流伺服. 器。原本串流市場由 RealNetworks 的 RealSystem 佔有較大市場，但是在微軟強勢的行銷下，市佔率逐漸追過 RealSystem。其所使用的串流技術 WMV 宣稱在 ADSL 的傳送速率下，可以提供更好的品質。 WMV 的撥放器使用 Windows 內建之 Windows Media Player，Windows 作業系統的普及讓使用者不需另外安裝 WMV 播放器是此伺服器的一大特點。另外 Windows Media 增加了版權保護功能，可以限制播放及操作，這對於智慧財產權的保護有很大的幫助。. 14.

(24) 第二章基礎理論介紹 . Helix Server RealNetworks 公司首先推出了串流媒體技術，隨著網際網路的快速發展，公司迅速的發展在市場上佔有主要的地位。因為很早就開始發展串流技術，所以 Helix Server[9]擁有最多的使用者。 Helix Server 有許多先進的設計，例如：Two-Pass Encoding 二次編碼技術，可以通過對媒體內容進行一次掃描，再根據掃瞄結果提高編碼效果，唯此方法對於直播(Live Broadcast)無法支援。其音頻部份的壓縮採用 Real Audio，此種編碼於網路頻寬不足之環境下有良好的傳輸性能。 Helix Server 串流需用 RealPlayer 播放器進行播放，其使用非常方便，系統資源佔用相比於 Quick Time Player 較低，是良好的串流系統。. . Darwin Streaming Server Darwin Streaming Server[7]是蘋果電腦的開放程式原始碼計畫之一，其核心. 程式為 QuickTime Streaming Server，目前版本為 version 5.5.5。Darwin Streaming Server 中實作了 RTP、RTSP、SDP 等標準。能提供群播、單點傳播、HTTP 等多種傳輸方式，同時支援多種作業平台。 Darwin Streaming Server 可以分為兩大部分，共用工具部分與核心部份。其中核心部份主要負責封包處理、流量控制、RTSP 流程控制及建立連接等工作。共用工具部分負責網路運作與職環境相關性高的工作。. 15.

(25) 第二章基礎理論介紹. 2.1.4 Codec 與 Container format 此節將概述一下 Codec 與 Container format 的不同之處。 . Codec 為壓縮演算法，其作用在於縮小多媒體資料的大小，Codec 包括有 video codec 與 audio codec，分別負責影像以及聲音的編解碼程序。常見的 Codec 有 MEPG-1、MEPG-2、MEPG-4、Divx 以及 H.264。. . Container format 則是包含了一個或是多個 codec 編碼後的串流，包括影像串流(Video Stream)以及聲音串流(Audio Stream)。常見的 Container format 有 MPEG-PS、MPEG-TS、ASF、MOV 以及 AVI。理論上我們可以任意將 code 後的串流放進 container 中，但是實際上還是有相容性的問題。. 下圖列出可以互相搭配的 Codec 與 Container format：. 圖 2-6 Muxer / audio and video formats matrix 16.

(26) 第二章基礎理論介紹. 2.1.5 固定與可變 BitRate . 固定 BitRate：因壓縮方式的不同，使得在傳輸過程中有些應用需要保持一定的 BitRate。在 Streaming 時由 Server 端直接送出不需要做調整，其 BitStream 的 BitRate 不會變動。. . 可變 BitRate：在一些壓縮方式下，多媒體資料可以允許在傳送時有不同的 BitRate，亦及傳送的 BitStream 其 BitRate 可以變動，這需要在 Encode 之時下參數。在實際應用上，當我們發現當時網路狀況不穩，可以及時的將多媒體串流以較低的 BitRate 產生且送出，使得使用者可以獲得較順暢的串流。. 在一般伺服器會在判斷連線狀態後，針對網路情況來調整，而調整方式為針對 BitRate 的增加或減少來做調整. 17.

(27) 第二章基礎理論介紹. 2.2 Video Lan Client (VLC). 2.2.1 簡介 VideoLan[10]計畫是一個開發多媒體播放器的計畫，爾後加入了影音串流傳輸的功能。此計劃原本是Ecole Centrale Paris(http://www.ecp.fr)的學生的一個專題計畫，在2001年2月1日以GNU General Public License (GPL)發佈後，現在計畫成員橫跨二十多國。作為VideoLAN 最主要的軟體 ─ VLC (VideoLAN Client)多媒體播放器，現已被研發成一個跨平台、具有完整特徵的多媒體播放程式及串流伺服器。圖2-7 為VLC所能提供的Streaming Solution：. 圖 2-7 VLC 解決方案. 18.

(28) 第二章基礎理論介紹 VLC串流平台有以下幾點特色： . 具有跨平臺的特性：現有Linux、Microsoft Windows、Mac OS X、BeOS、 BSD、Pocket PC及Solaris等版本。. . 支援媒體格式豐富：其壓縮格式函式庫核心使用FF MEPG，因此可支援之格式豐富，下圖為其支援之媒體格式：. 圖 2-8 VLC 所支援之媒體格式 . 模組化設計：可依開發者需求選擇符合的模組，減少不必要的浪費，同時可依照功能需求調整到最佳化的系統架構。由於此模組化的設計同時可容易達到跨平台或相容於各種不同的作業系統。. . Thread：VLC採用Thread方式運作，有效節省系統資源。. 19.

(29) 第二章基礎理論介紹 . 支援豐富的串流協定：其支援之串流協定豐富，有HTTP、RTP…等多種串流格式，圖2-9 為所支援之串流格式：. 圖 2-9 VLC 所支援之串流格式. 2.2.2 程式功能模組 VLC以模組化架構[10]開發其計畫，各種模組在被使用時才runtime的載入。每個模組依不同功能提供不同的特性。此種架構讓開發者可以容易的去修改模組，開發出不同的應用。以下簡述各類型的模組特性： . Interface Module：整個程式的起點，使用者通過其中一種介面模組，來與程式溝通，其中的Dummy Module採用命令列字串溝通。. . Access Modules：此模組允許VLC讀取不同來源的stream，例如：vcd、dvd 或網路的來源，且在runtime的期間分析stream，以找到最適合的模組。. . Demuxer Modules：在2.1.4節中有提到container format是用來包裝的， Demuxer模組為用來解析內容的模組，Demuxer會從包裝中取出串流然後再把內容送給decoder。 20.

(30) 第二章基礎理論介紹 . Codec Modules：支援各種壓縮格式的模組，其核心大多使用FF MEPG。另也有自行提供之編解碼模組。例如libmpeg2負責MPEG2的解碼、MAD負責聲音的解碼等。. . Video Filter Modules：對影像做調整的模組，如adjust模組可以用來改變影像的對比度或是亮度。. . Video Output Modules：選擇對系統最適合的影像格式輸出。. . Audio Output Modules：會先對系統找出最適合的聲音模組。同時設定聲音輸出格式，如聲音取樣頻率、單聲道或雙聲道以及暫存記憶體的大小。. 圖 2-10 VLC 作多媒體串流時模組運作架構. 21.

(31) 第三章系統架構. 第三章系統架構在第一章中我們提到 Bandwidth Cost 是一個現實且重要的問題。在實務上串流服務提供者為了容納更多的使用者，必須要跟 ISP 租用更多的頻寬，同時，當串流服務提供者超用租用頻寬時，通常必須给付超額罰款給 ISP。因此，在可用的頻寬流量下，頻寬的管理是一個重要的課題。就頻寬管理部份，常見的方式是使用變動位元之視訊串流方式調整使用頻寬，此種調整方式我們在 1.2 節時曾經討論過它的問題。而在 1.2 節的最後面我們討論到，我們期望的頻寬調整方式應有以下幾個特性： (1) 當總流量超過安全值，調節頻寬時可最小化視訊品質之降低。 (2) 頻寬充足時，調節頻寬且最大化的提昇視訊品質。在此章節中，首先我們將介紹本論文針對頻寬調整的幾個特性，所提出的改善法則─動態頻寬管理視訊串流法則，緊接著會介紹串流伺服器的系統架構，希望這些介紹能幫助讀者對本論文有更多的了解。. 3.1 動態頻寬管理視訊串流法則對於 1.2 節最後所提出的幾點特性 (1) 『當總流量超過安全值，調節頻寬時可最小化視訊品質之降低』、(2)『頻寬充足時，調節頻寬且最大化的提昇視訊品質』。我們提出了一個基於群組的管理架構，並希望以此架構來對視訊串流伺服. 22.

(32) 第三章系統架構器做頻寬管理。本動態頻寬管理視訊串流法則包含三個部份：群組管理、Merge 程序、Split 程序。以下我們將分三節分別介紹這三部份。. 3.1.1 群組架構為了讓視訊串流伺服器可以容易管理頻寬，我們的視訊串流伺服器使用群組架構來做管理。群組的架構有幾點好處，我們將在後面的章節中討論，在此之前我們先介紹我們的群組架構，其架構如圖 3-1 所示：. S. ... C1. N Channels. … G1,1. M Groups. Cn. … G1,m. Gn,1. B 1,m. M Groups. Gn,m. B n,m 圖 3-1 群組架構. 首先，假設我們現在有一個視訊串流伺服器，此伺服器擁有 n 個頻道 (Channel)，每個頻道都會播放一份節目(Program，可能是一部電影、一個實況轉撥的球賽、一場演講或是一連串的節目內容)。每個頻道又擁有 m 個收看群組. 23.

(33) 第三章系統架構 (Group)，而每個收看群組的視訊品質是不同的，這表示每個收看群組所送出的視訊串流所佔用的頻寬大小不同。舉例來說，假設現在頻道一(Channel one)正轉播著紐約洋基隊的台灣投手─ 王建民所主投的季後賽，而這個頻道底下擁有 3 個不同畫質的收看群組G1,1、G1,2、 G1,3，這三個收看群組分別代表的是高視訊品質、中視訊品質以及低視訊品質，且其使用的頻寬分別為 768 kbp、512 kbp、384 kbp。使用此種群組架構有一個好處，使用這種架構可以讓使用者去選擇有利於使用者本身的頻寬來收看節目，如果使用者所擁有的網路頻寬較大，使用者自然可以選擇最高等級的收看群組(Group)來收看畫質最好的轉播，反之使用者可選擇低等級的收看群組，來獲得收看的流暢度。接著，我們使用tree結構來描述我們上述提到的視訊串流伺服器，root S代表視訊串流伺服器本身，伺服器擁有n個channels，以每個level 1 的節點代表一個 channel，其中每個channel以Cn來表示(C1代表Channel one)。每ㄧ個channel的節點又擁有m個groups，以每個level 2 的節點代表一個group，每個group以Gn,m來表示 (G1,1 代表channel one的group one)。而每一個group的串流使用頻寬以Bn,m來表示 B. (B1,1代表G1,1這個group所消耗的頻寬)，同一頻道中的群組的號碼越低者，其視訊品質越好(這代表B1,1大於B1,2)。 B. B. 24.

(34) 第三章系統架構. 3.1.2 Merge 程序 3.1.1 節中我們把視訊串流伺服器群組結構化，在這一節中我們將繼續討論如何去對結構化的伺服器做頻寬調整。首先，每個頻道都擁有不同的收看群組，這意味著不同的頻道之間並不會有連動關係。我們回過來看變動位元之視訊串流方法，它使用每個串流調整的方式做管理，如果在頻道二的串流佔用了多數頻寬，可能連帶的影響頻道三、頻道四的串流，使得頻道二、頻道三、頻道四的串流都需要把串流的頻寬降低，如此會連帶的把每個頻道的畫質降低。在群組化的結構中各頻道擁有不同群組，而頻道之間不會互相影響，因此我們可以對各頻道內的群組做調整，並且不致於去影響到其他的頻道，這個特性可以讓我們在調整頻寬與畫質的平衡上有很大的幫助。接著，我們試著去調整群組，使得系統釋出頻寬來。我們知道整個系統的總頻寬流量(Btotal：Total Used Bandwidth)等於每個群組的使用者(Un,m：User Number of B. Gn,m)乘以群組的輸出頻寬(Bn,m：Stream Biterate of Gn,m)，而調整每個群組的使用 B. 者將可以使總頻寬改變，意味著如果高畫質的群組的人數變少，將可以釋出頻寬。. B. total. =. i=n, j =m. ∑B. i =1, j =1. i, j. •U i, j. (1). 依照這個方式，我們發展出了 Merge 的程序，希望在頻寬使用殆盡時釋出多餘的頻寬。 25.

(35) 第三章系統架構以下是 Merge 的流程： (1) 察覺系統總流量超出安全流量值，啟動 Merge 程序。 (2) 隨機從頻道中挑選出一個頻道Cs，並對頻道Cs所擁有的所有群組Gs,m做挑選，選擇的目的在於合併兩個群組。[因為各頻道獨立，因此不會影響到其他的頻道] (3) 對挑選出來的Gs,i及Gs,j (i>j)進行合併(Merge)動作，合併動作為把高畫質群組的使用者移到低畫質群組的使用者。[移動Gs,i的使用者到Gs,j去] (4) 此時系統將釋出(Bs,i -Bs,j)* Us,i的頻寬。 (5) 再次確認系統總流量經過頻寬釋出後，是否達到安全的流量使用門檻，如果尚未達到安全門檻，再做 2 ~ 4 的步驟，直到達安全流量使用門檻。這種 Merge 方式雖可以有效的釋出頻寬，但漫無目標的合併群組卻不是一個好的調整方式。我們從群組與群組的合併中發現，雖然合併可以釋放出多餘頻寬，但是我們同時也損失了從高視訊品質群組合併到低視訊品質群組時的視訊品質。在串流系統中，最重要的還是串流使用者實際感受到的視訊品質，因此在這邊我們以每個群組串流的畫面失真率(PSNR)來當作計算視訊品質的參數。每個群組所擁有的視訊品質我們定義為D(Gn,m) (Distortion of Gn,m)，每次Merge損失的視訊品質我們則可以表示成(D(Gn,i) - D(Gn,j))* Un,i。. 26.

(36) 第三章系統架構接著我們整合釋出之頻寬以及損失之視訊品質，獲得一個頻寬─視訊品質比的成本函式(cost function)，函式如下： Cost. (G. n,i. α. =. , G n, j. ). [D (G )− D (G )] (B − B )•U n ,i. n ,i. (2). n, j. n, j. n ,i. [其中 α 為調整參數，讓不同頻道之間可以擁有不同的權重] 從函式得知成本值越小，則釋出相同的頻寬時，將擁有較少的視訊品質降低；反之當成本值越大，在提高相同的視訊品質的會增加較少的頻寬。擁有此函式後，我們可以以頻寬─視訊品質比做為調整群組之依據，加上此成本函式後，我們的 Merge 程序將變成以下的步驟： (1) 察覺系統總流量超出安全流量值，啟動 Merge 程序。 (2) 對系統中所有群組的群組組合做頻寬─視訊品質比成本函式計算，接著挑選出合併值最小的群組組合。 (3) 對挑選出來的Gs,i及Gs,j進行合併(Merge)動作，合併動作為把高視訊品質群組的使用者移到低視訊品質的使用者，合併後Gs,i群組移到集合Smerge，同時記錄下合併資訊。[移動Gs,i的使用者到Gs,j去] (4) 此時系統將釋出(Bs,i -Bs,j)* Us,1的頻寬。 B. (5) 再次確認系統總流量經過頻寬釋出後，是否達到安全的流量使用門檻，如果尚未達到安全門檻，再做 2 ~ 4 的步驟，直到到達安全流量使用門檻。 27.

(37) 第三章系統架構圖 3-2 為 Merge 程序的虛擬碼(pseudo code)： f. B. total. ≥ δ 1 then. do find min Cost. (G. n,i. ). , G n, j ∈ S. then merge G n ,i to G n , j keep G n ,i inf. while(Btotal < δ 2 ). 圖 3-2 Merge 程序虛擬碼圖 3-3 為 Merge 程序的流程圖：. Every △T check Btotal No Btotal is over boundary Yes find min Cost. merge. Yes. (G. G. n ,i. n ,i. ). , Gn, j ∈ S. to. G. n, j. Check Btotal is still over boundary? No End. 圖 3-3 Merge 程序流程圖. 28.

(38) 第三章系統架構. 3.1.3 Split 程序 3.1.2 節中我們就『當總流量超過安全值，調節頻寬時可最小化視訊品質之降低』的原則發展出 Merge 程序，此程序不但可以在系統頻寬不足時有效釋出頻寬，讓系統容納更多的使用者，同時在釋出之頻寬與損失的視訊品質上也取得平衡。在 Merge 程序中，我們會把高視訊品質群組合併到低視訊品質群組裡，此作法會犧牲掉當初選擇高視訊品質群組使用者的視訊品質。在這邊我們考慮一個情境，剛開始時使用者大量湧入，系統流量漸增，接著超出流量安全範圍，此時系統將會啟用 Merge 程序，有些高視訊品質群組的使用者將會被併入低視訊品質群組裡，並且釋出頻寬。過了一段時間後，使用者開始離開串流伺服器，系統的流量漸漸下降，接著到達頻寬餘裕的狀況，在這種狀況下我們是希望讓每位使用者都可以獲得他所要求的視訊品質，如此不只可以善用我們所租用之頻寬，也可以讓使用者獲得較好的服務。在本節中我們使用前述之群組架構，以及在 Merge 程序過程當中，群組群組之間的合併資料，發展出調整串流視訊品質之方法─Split 程序。 Split 程序概念在於紀錄下在 Merge 程序時，從高視訊品質群組併入低視訊品質群組的使用者，當系統察覺到流量到達餘裕的狀況時，將計算頻寬─視訊品質比回復某些當初被影響到的高品質視訊使用者，以求在提高這些使用者的視訊品質的同時也可以兼顧到調節頻寬，在頻寬調節與視訊品質中取的最大利益。. 29.

(39) 第三章系統架構 Split 程序步驟如下： (1) 察覺系統總流量低於安全流量值，啟動 Split 程序。 (2) 檢查系統資訊中是否有被Merge的群組。[檢查Smerge集合中是否有被Merge 的群組] (3) 對系統中所有被合併的群組做成本函式計算，挑選出視訊品質─頻寬比最大的群組組合Gs,i及Gs,j。[挑選最大值的原因在於，增加相同的頻寬下，我們可以獲得最多的視訊品質提升。] (4) 對挑選出來的Gs,i及Gs,j進行分離(Split)動作，分離動作為把原本併入低畫質群組的使用者回復到原本選擇的高畫質群組。[回復被降到Gs,j的使用者回到Gs,i] (5) 再次確認系統總流量經過分離(Split)動作後，是否達到一定程度流量的門檻，如果尚未達到門檻，再做 2 ~ 3 的步驟，直到到達安全流量使用門檻。圖 3-4 為 Split 程序的虛擬碼(pseudo code)：. If. B. total. If. S. ≤ δ 3 then merge. is not empty then. do find max Cost then split. G. (G. n ,i. while(Btotal > δ 4 ). n,i. from. ). , G n , j ∈ S merge. G. n, j. 圖 3-4 Split 程序虛擬碼. 30.

(40) 第三章系統架構圖 3-5 為 Split 程序的流程圖：. Every △T check Btotal No Btotal is under boundary? Yes Is there any group been merged? Yes find max Cost. (G. n ,i. ). , G n , j ∈ S merge. split Gn,i from Gn,j. Yes. Check Btotal is still under boundary? No End. 圖 3-5 Split 程序流程圖從系統流量使用量角度來看，我們可以將這些程序以圖 3-6 的有限狀態機 (Finite State Machine)來表示，其中各種狀態表示系統流量的狀況，一開始的系統為 Under Boundary 狀態，大量的使用者加入後系統會跳到 Normal 狀態之後再跳到 Over Boundary 狀態，此時使用 Merge 程序後將會回到 Normal 狀態，當使用者 31.

(41) 第三章系統架構大量離開後會跳到 Under Boundary 狀態。我們此時使用 Split 程序回復某些使用者的視訊品質。. Merge Procedure, Users Leave. Users Leave. Users Join Under Boundary. Normal Btotal. Over Boundary. Users Leave Split Procedure, Users Join. Users Join. 圖 3-6 串流系統之有限狀態機. 32.

(42) 第三章系統架構. 3.2 實現法則之視訊串流伺服器架構此節中將介紹本研究所建置的視訊串流伺服器，視訊串流伺服器端主要由『視訊串流模組』、『控制模組』以及『頻寬管理模組』幾個部份所構成。使用者端則由『使用者行為模擬模組』、『觀看介面』等兩部分所組成。其中『虛擬使用者模組』是為了測試視訊串流伺服器的實際運作而特別開發，此虛擬使用者模組可以模擬使用者行為，讓我們在測試串流伺服器時可以自動化測試，此虛擬使用者模組支援本論文開發的模擬程式之情境劇本(scenario)。. 3.2.1 模組介紹本系統的實作選用 Linux 為作業系統，各模組透過修改以及整合 Linux 上的開放原始碼專案(Open Source Project)來達到主要功能。選用 Linux 為作業系統有幾點好處： (1) Linux 開放原始碼較方便修改在開發上彈性高，開發成本也較低。 (2) 開放原始碼專案支援度較高，許多的開放原始碼專案都以 Linux 平台所發展，因此透過整合開放原始碼的專案可以縮短開發時間也可以節省成本。以下將介紹各模組的功能以及所使用的軟體：伺服器端(Server)： . 視訊串流模組：採用 2.2 節所介紹的 VLC (VideoLAN Client)專案做為多. 33.

(43) 第三章系統架構媒體串流伺服器。此專案擁有多樣化的輸出及輸入格式，且整合了包含 FF MPEG、x264 等的多種開放原始碼函式庫，可以支援多樣化的的多媒體格式。 . 控制模組：主要由資料庫伺服器以及網頁伺服器兩部分所組成，資料庫伺服器方面使用 MySQL Server[12]，網頁伺服器方面使用 Apache Server[11]。管理者藉由網頁介面來管理串流資訊、播放內容以及使用者資訊，而儲存資料方面則由資料庫處理。. . 頻寬管理模組：主要以我們所發展的演算法為核心，依靠控制模組所儲存的數據，透過 Ajax 語法變更使用者所接收到的串流，來達成頻寬管理。. 使用者端(Client)： . 觀看介面：觀看介面我們選擇使用 windows media player 元件，因為微軟的 windows 作業系統為最普遍使用的作業系統，因此使用者只需瀏覽內嵌 windows media player 元件的網頁便可觀賞頻道，不需另外安裝軟體，減少使用者的進入門檻。. . 虛擬使用者模組：本論文使用 Ajax 語法寫了一個內嵌在使用者端的行為模擬模組，其運作內容主要是從伺服器取得操作行為，然後透過我們所設計的 API 操作觀看介面，以此來模擬使用者觀看影音串流之狀況。舉例來說，我們可以設定好一個情境劇本其內容為，使用者在頻道二的第. 34.

(44) 第三章系統架構一個群組觀看一段時間後，大多數會跳轉到頻道二的第一個群組，用此來模擬使用者轉台的行為。而使用者端的模擬運作為(1)取得行為連結到頻道二 (2)取得行為跳轉到頻道三。這中間的轉台或是斷線都由我們所設計的 API 來操作。圖 3-7 虛擬使用者程式的運作流程：. 圖 3-7 行為模擬模組運作流程. 35.

(45) 第三章系統架構. 3.2.2 串流伺服器架構本系統的使用者只需要瀏覽我們內嵌 windows media player 元件[8]的網頁便可觀賞頻道，因此我們藉由網頁伺服器透過伺服器端的動態語法，管理以及存取串流伺服器，圖 3-8 為本系統架構圖。. 圖 3-8 系統架構圖系統運作流程： (1) 使用者透過瀏覽器連結到我們所設計的網頁，選擇欲觀看的頻道群組。 (2) 使用者資訊透過網頁伺服器存到資料庫。 (3) 透過網頁伺服器解析使用者的要求，同時設定串流伺服器。 (4) 回傳串流伺服器位置給使用者。. 36.

(46) 第三章系統架構 (5) 使用者透過內嵌的 windows media player 元件連結串流伺服器，然後向串流伺服器要求串流資料。 (6) 串流伺服器傳送串流資料，使用者使用 windows media player 元件播放串流多媒體。圖 3-9 為本系統運作流程。. 圖 3-9 系統運作流程. 37.

(47) 第四章研究與實做方法. 第四章實驗數據與系統效能分析在上一章中，我們介紹了動態頻寬管理視訊串流法則以及視訊串流伺服器的基本架構。為了驗證我們所提出的動態頻寬管理視訊串流法則，以及觀察串流伺服器實際運作情形，我們在本章中將提出數種不同的情境，接著以模擬程式以及本論文所實際架設的串流伺服器去測試這些情境，然後獲得各種數據。最後藉由分析這些數據，討論本論文所提出的法則是否可以有效的運作。. 4.1 模擬情境說明在呈現我們的數據之前，首先必須先說明整個模擬情境。我們總共有三個模擬情境，其設定分別如下： (1) 模擬情境一：在模擬情境一，我們設定串流系統擁有 3 個頻道 (Channel)，每個頻道擁有高畫質、中畫質、低畫質三個群組(Group)，系統頻寬的安全區域(Normal Btotal)在租用頻寬的 80% ~ 85%。系統使用者設定在 100 位，每個使用者有 4 種狀態，分別是閒置、觀看頻道一、觀看頻道二、觀看頻道三，各頻道之數據列於圖 4-1。系統情境設定分為兩段，前半段使用者隨意選擇加入頻道及群組，後半段使用者漸漸跳到頻道二。. (2) 模擬情境二：在模擬情境二，我們設定串流系統擁有 3 個頻道 (Channel)，每個頻道擁有高畫質、中畫質、低畫質三個群組(Group)，系統頻寬的安全區域(Normal Btotal)在租用頻寬的 80% ~ 85%。系統使用者設定在 38.

(48) 第四章研究與實做方法 100 位，每個使用者有 4 種狀態，分別是閒置、觀看頻道一、觀看頻道二、觀看頻道三。系統情境設定分為三階段，第一階段使用者隨意選擇加入頻道及群組，第二階段使用者漸漸跳到頻道二，第三階段使用者漸漸離開串流系統。. 圖 4-1 情境一、二之頻道數據 (3) 模擬情境三：在模擬情境三，我們設定串流系統擁有 9 個頻道 (Channel)，每個頻道擁有高畫質、中畫質、低畫質三個群組(Group)，系統頻寬的安全區域(Normal Btotal)在租用頻寬的 80% ~ 85%。系統使用者設定在 1000 位，每個使用者有 10 種狀態，分別是閒置、觀看頻道一、觀看頻道二、…、觀看頻道九。系統情境設定分為三階段，第一階段使用者隨意選擇加入頻道及群組，第二階段使用者漸漸跳到頻道二與頻道五，第三階段使用者漸漸離開串流系統。在實驗過程中，前兩個情境我們會應用在串流系統以及模擬程式上，接著收集相關數據，然後比較、分析所收集到的數據。而情境三會應用在 39.

(49) 第四章研究與實做方法模擬程式上，接著分析其數據，用來預測在 1000 位使用者的狀況下，實際的串流系統會如何運作。. 4.2 串流系統測試說明本章的實驗數據分為兩部分，第一部份為模擬程式所測得的數據，第二部份為實際架設的串流系統所測得的數據。在本節中將簡介我們如何測試串流系統，在測試系統時遇到最大的問題在需要足夠的使用者以及機器。本論文的系統測試環境使用本系的電腦教室，其配備有 50 台左右的電腦供測試使用，圖 4-2 為測試系統時電腦教室一隅。. 圖 4-2 串流系統測試畫面(一) 除了電腦的問題外，測試時遇到的另一個問題為使用者人數，因為本次測試需要用到 100 位使用者以上，這對於要常常做測試的本實驗是很麻煩的一件事， 40.

(50) 第四章研究與實做方法因此我們特別開發了內嵌於觀看網頁上的虛擬使用者程式，在測試時先連到我們的網頁介面，如圖 4-3 所示，接著透過內嵌的虛擬使用者程式來模擬一個使用者，此程式會隨著伺服器端的劇本行為去操縱觀看介面，如此可以把一個連到觀看介面並且開啟虛擬使用者程式的瀏覽器模擬成一位使用者，如圖 4-4 及圖 4-5 所示，一台電腦上可以模擬出 4 ~ 6 個使用者，本論文使用了大約 40 台電腦模擬出 100 位使用者，以此種方法來測試串流系統。. 圖 4-3 觀看介面. 圖 4-4 串流系統測試畫面(二) [模擬使用者]. 圖 4-5 串流系統測試畫面(三) [模擬使用者] 41.

(51) 第四章研究與實做方法. 4.3 頻寬調節分析在此節中我們將先針對系統頻寬流量進行分析，在圖中藍色線(較粗的線條) 代表的是沒有做頻寬調整的系統數據，綠色線(較細的線條)代表使用了頻寬調整法則之系統數據，紅色線(水平線)為系統之流量限制。首先，情境一的劇本內容為使用者漸漸加入系統，此情境是用來測試本論文所提出的 Merge 法則之運作狀況，在圖 4-6 的圈起來的部份可以明顯看到綠色線在上下震盪，此點接近系統流量限制，這段區域內的震盪代表的是本法則開始調節頻寬所呈現的狀態，在震盪過後系統流量一直處在流量限制下，且表現平穩。 40000. 40000 無調整狀態 Se rv er流量限制. 30000 25000 20000 15000 10000 5000. Server流量限制. 25000 20000 15000 10000. 245. 230. 200. 215. 170. 185. 140. 155. 110. 125. 80. 95. 50. 65. 35. 5. 時間 (分鐘 ). 20. 230. 0. 245. 200. 215. 170. 185. 155. 125. 140. 95. 110. 80. 50. 65. 35. 5. 動態調整法則. 30000. 5000 20. 0. 無調整狀態. 35000. 動態調整法則. S e r v er 流量 (K b i t). Server流量(K bit). 35000. 時間 (分鐘 ). 圖 4-6 頻寬調整狀態 [情境一-模擬程式]. 圖 4-7 頻寬調整狀態 [情境一-串流系統]. 接著看圖 4-7，圖 4-7 為實際的串流伺服器所量測到的數據，其使用的情境劇本跟圖 4-6 的模擬程式一致。在圖 4-7 中可以發現綠色線(有做頻寬調整)在瀕臨流量限制時，跟模擬程式所展現出來的行為一樣，開始上下震盪，表示法則開始調整系統流量。綠色線後續雖然一樣是在流量限制下，但震盪幅度卻比模擬程式所獲得之數據震盪幅度還要大。接著來看情境二的狀態，情境二的劇本內容為使用者漸漸加入系統，在系統 42.

(52) 第四章研究與實做方法中穩定一段時間，然後離開系統，此情境最主要是用來檢視我們所提出的 Split 法則。在圖 4-8 的紅色圈區域可以看到，當使用者漸漸離開系統後，系統流量餘裕，系統將開始執行 Split 法則，在此之後的時間可以發現綠色線在開始往下掉時，下降的幅度較藍色線小。 40000. 動態調整法則 Server流量限制. 15000. 245. 215. 230. 185. 155. 200. 時間 (分鐘 ). 170. 5. 230. 245. 215. 185. 200. 155. 170. 125. 140. 95. 110. 65. 80. 35. 50. 0. 5. 5000. 0. 125. 10000. 5000. 140. 10000. 20000. 95. 15000. 25000. 110. 20000. 65. 25000. 80. Server流量 (K bit). 30000. 35. Server流量限制. 50. 30000. 無調整狀態. 35000. 動態調整法則. 20. 無調整狀態. 20. Se r v e r 流量 ( K b i t ). 40000 35000. 時間(分鐘 ). 圖 4-8 頻寬調整狀態 [情境二-模擬程式]. 圖 4-9 頻寬調整狀態 [情境二-串流系統]. 圖 4-9 為實際測量之數據，我們看到在前半段 Merge 部份跟情境一量測出來的數據很像，都有大幅度的震盪，到了後半段使用者開始離開後，下降幅度慢慢變小，尤其我們可以看到綠色線呈現階梯狀，這是因為 Split 法則把使用者調回原畫質，使得流量平穩一段時間後才再往下掉所造成的。接著我們將分析模擬數據與實測數據，圖 4-10 及圖 4-12 為情境一及情境二的實測值與模擬值之比較，可以發現兩者的分布曲線很相近，但實測值的震盪幅度較大，在上面的討論中有提到，我們發現實測值的震盪幅度不管在情境一或是情境二都比模擬時所測得的數值來的大。造成此種現象的原因在於實測時每個頻道所輸出的串流數據並不固定。舉例來說，頻道一的群組一所使用的視訊串流大小是 384k bps，但是在實測時我們發現它實際上會在 350k bps 上下震盪，並不會 43.

(53) 第四章研究與實做方法準確的位在 384k bps，有時候甚至會衝到 400k bps，因此造成了實測所測得的數據不會和模擬所測得的數據一般的表現。另外，在實際量測串流系統時還有網頁的傳輸以及其他因素，造成所我們測得的數據不只包含串流使用的流量，還有其他數據。 25000. 實測值與模擬值之誤 5000 4000. 實測值. 3000. 5. 0 23. 0. 5 24. 23. 0. 5. 5 21. 20. 18. 5. 0 17. 0. 15. 5. 14. 0. 12. 11. 80. 95. 65. 0 -1000 -2000 -3000. 24. 5. 0 20. 21. 5. 0 17. 18. 5. 0 14. 15. 0. 5 12. 95. 11. 65. 80. 35. 50. 5. 20. 0. 1000. 50. 5000. 2000. 35. 10000. 5. 模擬值. 20. 15000. 誤差量 (K bit). Server流量(K bit). 20000. -4000. 時間 (分鐘 ). -5000. 圖 4-10 實測值與模擬值比較 [情境一-系統流量]. 時間(分鐘). 圖 4-11 實測值與模擬值誤差 [情境一-系統流量]. 30 000. 實測值. 實測值與模擬值之誤差. 5000. 模擬值. 4000. 20 000. 3000. 5. 0. 5. 0 23. 24. 5 21. 0. 5 18. 20. 0 17. 5. 0 14. 15. 0. 5 12. 95. 11. 80. 65. 35. 0 -1000 -2000 -3000. 24. 23. 0. 5 21. 20. 0. 5 18. 17. 5. 0. 15. 14. 5 12. 0. 95. 11. 80. 65. 50. 35. 5. 20. 0. 1000. 50. 5 000. 2000. 20. 10 000. 5. 15 000. 誤差量 (K bit). Server流量(K bit). 25 000. -4000. 時間 (分鐘 ). -5000. 圖 4-12 實測值與模擬值比較 [情境二-系統流量]. 時間 (分鐘 ). 圖 4-13 實測值與模擬值誤差 [情境二-系統流量]. 因此，在圖 4-11 及圖 4-13 實測值與模擬值的誤差中可以看到實測值與模擬值的誤差，除了少數衝到 4000k bps 的部分，大約都處在 1000~3000k bps 左右，此誤差值便是由上述的原因所造成的。扣除掉以上小幅的誤差，本論文的模擬程式所模擬出來的結果，與串流系統所測得的數據是很相近的。如果我們可以把上述的因素量化然後加入到我們的模擬程式中，本模擬程式所模擬出來的結果 44.

(54) 第四章研究與實做方法將會更加的準確。圖 4-14 為情境三模擬程式所測得之數據，情境三的劇本內容為使用者漸漸加入系統，接著離開系統，與情境二相同。但情境三的設定為千人等級的串流系統，因為市面上常見的中小型串流系統其限值大多在千人左右，因此我們想知道在千人等級的串流時，本法則是否依然可以良好的運作。而從前面的討論知道，本模擬程式的數據擁有一定的準確度。因此我們將使用模擬程式來預測，當視訊串流系統到達千人等級時，系統運作會是如何的情況。從圖 4-14 的數據可以看出，其運作的情況跟我們在 100 人的系統等級所測得的數據是差不多的，因此我此法則在千人等級的串流系統中依然可以良好的運作。. 350000. 250000 無調整狀態. 200000. 動態調整法則 150000. Server流量限制. 100000 50000. 5. 5. 5. 5. 5. 5. 5. 5. 5. 5. 5 42. 39. 36. 33. 30. 27. 24. 21. 18. 15. 12. 95. 65. 35. 0. 5. Server流量 (K bit). 300000. 時間 (分鐘 ). 圖 4-14 頻寬調整狀態(串流系統) [情境三]. 45.

(55) 第四章研究與實做方法. 4.4 PSNR 分析在串流系統中，最重要的還是服務使用者實際上所感受到的視訊品質。所以在本節中，我們用與前一節相同的模擬情境做量測，去分析頻道的視訊品質。我們以所有服務使用者平均獲得之 PSNR 值來做為比較的數據。 PSNR 計算公式如下：. ⎛ 255 2 ⎞ ⎟⎟ PSNR = 10 log 10 ⎜⎜ MSE ⎝ ⎠ 其中 MSE(mean square error)公式如下：. 1 MSE = n. ∑ (X n. i =1. i. − X i'. ). 2. [Xi 為被比較圖點i的值，Xi’ 為比較圖點i的值] 就我們的法則目標，我們期望可以在調節頻寬時，讓使用者獲得視訊品質差距不大的視訊串流。 32 32. 31. 31. 30. 28. 無調整狀態. 動態調整法則. 圖 4-15 PSNR 值分析圖 [情境一-模擬程式]. 245. 215. 230. 185. 200. 155. 170. 125. 35. 5. 時間 (分鐘 ). 140. 時間(分鐘). 20. 245. 215. 230. 185. 200. 155. 170. 125. 26 140. 95. 110. 65. 80. 35. 50. 5. 20. 26. 動態調整法則. 27. 95. 27. 110. 無調整狀態. 65. 28. 29. 80. 29. 50. 平均 P S NR 值. 平均PSNR. 30. 圖 4-16 PSNR 值分析圖 [情境一-串流系統]. 首先，我們看到圖 4-15，前半段每人平均所接收到的畫質，有調整與沒有調整的系統所呈現的數據差不多，因為此時還沒有做頻寬調整。到了後半段，系統. 46.

(56) 第四章研究與實做方法開始 Merge 使用者後，兩條曲線漸漸分離，但是我們可以看到其畫質的差距一直在 1db 左右，但是從圖 4-6 可以看到，沒有調整的系統其使用的流量，卻是有頻寬調整的系統使用的流量的一倍左右。. 同樣，在圖 4-16 的部份也可以看到一樣的傾向，而圖 4-16 可以發現畫質的震盪與我們在上一節中，頻寬分析所發現的震盪很類似，我們推測應該是相同的理由造成了如此的震盪。 32. 32. 31. 31. 30 平均 PSNR. 29. c. 無調整狀態. 28 無調整狀態. 動態調整法則. 230. 245. 200. 140. 155. 110. 80. 125. 時間 (分鐘 ). 95. 50. 65. 20. 35. 5. 26. 245. 215. 230. 185. 200. 155. 170. 125. 140. 95. 110. 65. 80. 35. 50. 5. 20. 26. 動態調整法則. 27. 215. 27. 170. 28. 29. 185. 平均 P SNR. 30. 時間 (分鐘 ). 圖 4-17 PSNR 值分析圖 [情境二-模擬程式]. 圖 4-18 PSNR 值分析圖 [情境二-串流系統]. 接著，我們看到圖 4-17 是模擬程式在情境二時所獲得的數據，前半段每人平均所接收到的畫質兩者之間差不多，到了中段系統 Merge 使用者後，兩條曲線漸漸開始分離，最後又合在一起，而可以看到在中段分離的部份，其畫質的差距大概在 1db 左右，在圖 4-18 也可以看到相同的狀況。接著我們分析模擬數據與實測數據，圖 4-19 及圖 4-21 為情境一及情境二的實測值與模擬值之比較，可以發現兩者的分布曲線很相近，而與上一節所討論到的一樣，因為實測值的數據並不會固定在一個值，所以實測上所獲的的值其變動. 47.

(57) 第四章研究與實做方法幅度較大。而兩者的誤差從圖 4-20 及圖 4-22 上可以看到，除了少數的波動到達 1db 以上其餘都維持在 0.5db 裡。因此就平均 PSNR 值來看，本模擬程式的數據也擁有一定的準確度。 31.5 31. 實測值與模擬值之誤差 1 .5. 30. 1. 29.5. 5. 5. 0. 24. 23. 21. 5. 0. 5. 0 20. 18. 17. 15. 5. 0 14. 0. 12. 95. -0 .5. 11. 80. 0 65. 28. 模擬值. 50. 實測值. 35. 28.5. 0 .5. 5. 29. 20. 平均 PSNR誤差. 平均PSNR 值. 30.5. 5. -1. 24. 0. 5 21. 23. 5. 0. 5. 0 20. 18. 17. 0. 15. 14. 0. 5 12. 95. 11. 65. 80. 35. 50. 5. 20. 27.5. -1 .5. 時間 (分鐘 ). 時間 (分鐘 ). 圖 4-19 實測值與模擬值比較 [情境一- PSNR 值分析圖]. 圖 4-20 實測值與模擬值誤差 [情境一- PSNR 值分析圖]. 32. 實測值與模擬值之誤差. 31. 2. 30.5. 1 .5. 30. 1. 29.5. 0 .5. 5 24. 0. 5 21. 23. 0 20. 5 18. 0. 5 15. 17. 0 14. 0. 5 12. 11. 95. 80. 65. 模擬值. 50. 28. 0 -0 .5. 35. 實測值. 5. 29 28.5. 20. 平均 PSNR誤差. 平均PSNR值. 31.5. -1 -1 .5. 5. -2. 24. 0. 5 21. 23. 0 20. 5 18. 0 17. 5. 0. 15. 14. 5 12. 0. 95. 11. 65. 80. 35. 50. 5. 20. 27.5. -2 .5. 時間 (分鐘 ). 圖 4-21 實測值與模擬值比較 [情境二- PSNR 值分析圖]. 時間 (分鐘 ). 圖 4-22 實測值與模擬值誤差 [情境二- PSNR 值分析圖]. 圖 4-23 的部份為情境三模擬程式所測得之數據，情境三的劇本內容為使用者漸漸加入系統，接著離開系統，與情境二相同。我們由圖 4-23 的數據推測在千人等級的串流系統下，視訊品質的差距一樣會落在 1db 左右。. 48.

(58) 第四章研究與實做方法 31 30.5 30. 29 28.5 28 無調整狀態. 27.5. 動態調整法則. 27 26.5. 80 10 5 13 0 15 5 18 0 20 5 23 0 25 5 28 0 30 5 33 0 35 5 38 0 40 5 43 0. 55. 26 5 30. 平均 PS NR. 29.5. 時間 (分鐘 ). 圖 4-23 PSNR 值分析圖 (模擬程式) [情境三]. 49.

(59) 第五章結論與未來展望. 第五章結論與未來展望本章將對於我們的論文做一個總結，同時對於之後可能的發展方向作一個簡單的介紹。. 5.1 結論在本論文中我們發展了一個動態頻寬調整法則，用來解決主從式架構之視訊串流伺服器耗用頻寬資源的問題，本法則以群組架構並且使用 Merge 程序以及 Split 程序來達到本論文在 1.2 節時所討論的兩點目標： (1) 當總流量超過安全值，調節頻寬時可最小化視訊品質之降低。 (2) 頻寬充足時，調節頻寬且最大化的提昇視訊品質。在研究過程中，我們發展出一套使用此法則的模擬系統，亦實際架設了一個使用此法則的視訊串流系統。在擁有模擬系統以及實際架設的串流系統後，我們可以獲得模擬數據，接著去跟實際運作時所測得的數據做比較。經由第四章的各種數據分析，我們可以看出本論文所提出的法則，在調節頻寬以及視訊品質的影響上有著很好的成效。同時本論文提出之法則在移植到其他的串流系統上相當的方便，本論文提出之法則所需要的參數不多，只須要每位使用者的頻寬使用量，以及每個視訊串流的視訊品質，就可以透過這些參數來做頻寬調整。. 50.

(60) 第五章結論與未來展望另外，本論文在主從式串流架構的相關研究，發展出一個具有價值的平台，藉由本論文中所實際建構的視訊串流系統，在加上我們所撰寫的虛擬使用者程式，可以讓研究者自動化做真實串流系統的壓力測試，這提供我們從模擬程式到真實使用者測試之間多一個測試的選擇，減少了去尋找真實使用者的麻煩。. 5.2 未來展望使用本論文所開發的模擬程式以及搭配本論文所架構的串流系統，可以方便去測試同樣使用主從式架構的串流伺服器的法則。本論文所建構的串流伺服器有模組化的架構，此種架構提供開發者方便更換功能模組。開發者可以更換不同的模組，來使得串流系統發揮更好的效能。另外我們將以此串流架構整合本實驗室發展多時的 SIP-CAM 系統，發展出一個結合視訊、監視、轉播且方便管理的多媒體資訊平台。最後就我們所使用的視訊串流模組部份來討論，本論文所架構的視訊串流模組本身就是一個龐大的開發專案，它支援多種輸/出入串流，也支援多種多媒體格式，而且只要增加編解碼的函式庫，此串流系統便可以輕易的增加支援的多媒體格式。因為這樣的優點，我們可以開發它成為一個多媒體的轉換平台，讓使用本串流系統的管理者架設出一個可以接受任何多媒體格式，然後再輸出常用的多媒體格式給使用者的視訊串流服務平台。. 51.

(61) 參考著作. 參考文獻 [1] Apostolopoulos, J., Tina W., Wai-tian, T. and Wee, S., “On Multiple Description Streaming with Content Delivery Networks,” in Proc. IEEE INFOCOM, 2002. [2] Jan Krikke, “Streaming Video Transforms the Media Industry,” in Proc. IEEE Computer Graphics and Applications, vol 24, July/Aug, 2004 [3] Carlos E. Luna, Lisimachos P. Kondi, Aggelos K. Katsaggelos, “Maximizing User Utility in Video Streaming Applications,” in Proc. IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, VOL. 13, NO. 2, FEBRUARY 2003 [4] 涂國祥, 林盈達, “多媒體串流應用：產品比較與實例分析,“ 國立交通大學資訊科學系，新竹，2001 [5] Wikipedia, available at http://en.wikipedia.org/. [6] Streaming Methods: Web Server vs. Streaming Media Server, available at http://www.microsoft.com/ntserver/mediaserv/exec/comparison/we bservvstreamserv.asp [7] QuickTime Streaming Server, available at. http://www.apple.com.tw/quicktime/streamingserver/ [8] Microsoft Windows Media Player, available at http://www.microsoft.com/windows/windowsmedia/default.asp [9] Real Server, available at http://www.realnetworks.com [10] Open source project: VLC, available at http://www.videolan.org/vlc/ [11] Open source project: Apache HTTP Server, available at. http://httpd.apache.org/ 51.

(62) 參考著作 [12] Open source project: MySQL Database Server, available at. http://www.mysql.com/ [13] 高橋登史朗著, “Ajax 與 Google map API 入門實作,” 博碩文化, 2006. 52.

(63)