LDS Algorithm - System Implementation - 改善起始延遲及畫面品質之使用者經驗於使用可調式視訊編碼的點對點串流系統

5 System Implementation

5.2 LDS Algorithm

在 LDS 排程演算法裡，我們使用 VB.NET 作為程式撰寫之基礎並執行於 Windows 平台上。其架構如下圖 15 所示，分成三個模組：搜尋模組(Searching Module)、選擇模組(Selection Module)、排程模組(Scheduling Module)。其中搜尋 模組主要功能為尋找某一特定階層檔案的網路位置，Hash File Name 程序將每個

_,檔案的檔名進行雜湊(Hash)後取得 hash_id，Compare Hash ID 程序再透過 Chord-P2P 環境，利用雜湊後的 hash_id 進行字串比較，尋找在網路中擁有這個檔案的候選節點群並回傳一候選節點清單(List of Candidate Peers)。

此清單被搜尋模組從中挑選出一個最適合的節點來取得須要的檔案，由下式 清單結構；而 Check Bandwidth、Check Priority 程序則根據表 7 的規則，檢查下 載清單結構裡每個_,的頻寬以及優先權值，判斷是否該進行下載或是取消，以 達到最佳的下載順序；最後 Download File 程序先產生一執行緒(Thread)再利用

HTTP Protocol 進行_,檔案的下載。在本地端會有一塊空間用來暫存待播放的影

像稱為緩衝區(Buffer)，每完成一個回合的排程後，為了節省網路資源，Check

Buffer 程序發現緩衝區的大小超過所設定的門檻值時，表示緩衝區內的資料太多

還不急著進行下一回合的排程及下載，等待一段時間後，再檢查一次，若緩衝區的大小低於門檻值，則可進行下一回合的排程程序。

Figure 15 An Overview of LDS Procedure.

6 Experiments and Results

6.1 Test Environment

實驗的環境包含了三個角色 Client、WAN Emulator 以及 Peer A、B，如下圖 16。其中 Client 負責在 P2P 網路中搜尋一段串流視訊來觀看； WAN Emulator 則是用來模擬真實網路環境，藉此消除內部測試網路環境過於單純之問題，除了限制各點之間的點對點頻寬之外，實際測試時並針對封包的延遲時間(RTT/2)、

遺失率(Loss Rate)、重複率(Duplication Rate)、錯誤率(Corruption Rate)進行參數之設置；最後 Peer A、B 負責模擬 P2P 網路中大量的節點，並提供串流視訊檔案。

Figure 16 Test Environment.

6.2 Test Cases

將一個十二秒的串流視訊以每一秒的時間間隔分割成十二個不同區塊

(chunk)，再將每一個區塊分別用 JSVM 壓縮成三個不同品質的階層檔案(layer)：

Baseline @ Level 1.3、Scalable Baseline @ Level 2.1、Scalable High @ Level 2.2。

考慮將不同的區塊個數進行每一回合的 LDS 排程程序，若區塊個數過少則會因下載程序會過於頻繁而造成同時有太多傳輸進行使得傳輸時間增加，反之，

若區塊個數過大表示同時有過多的階層檔案進行傳輸，也會使得傳輸時間增加，

從表 8 中可得知當區塊個數為三時所得到的效果為最好，也就是每回合排程三個

(2)不做任何處理的 Random Selection Algorithm、以及第二章的相關研究中所提及 的(3)Smooth Algorithm without delay 和(4)Smooth Algorithm with 1 sec[5]，以了解 畫面品質(Picture Quality)、演算法效能(Performance of Algorithm)、使用者等待時間(User Waiting Time)與起始延遲時間(Startup Latency 數值)的影響。同樣於相關研究中所提的 GaiaSharp[6]系統，由於其方法與內部元件結合較緊密，因此無法

好的，其畫面品質接近滿分 3；而 Random 是隨機挑選節點以取得檔案，因此挑到 RTT 值大的節點機率較高，造成畫面品質不穩定；最後 Smooth_No_Delay 以及 Smooth_Delay_1 固定從 RTT 值最小的節點取得基礎層，RTT 值次小的節點取得增強層，因此當網路環境越來越差時取得增強層的時間便會增加，使得增強層來不及在最終播放時間之內取得，造成其畫面品質無法提升，僅維持在基本品質的部分。因此 LDS 能有效的改善畫面品質，並改善了 Smooth Algorithm 將近一倍以上的畫面品質。

(A) RTT/2 (B) Loss Rate

Figure 17 Picture Quality.

但觀察圖 17(B)(C)的畫面品質曲線部分，當封包遺失率與重複率逐漸增加時 LDS 所能提供的畫面品質並沒有因此而下降。所以我們對照使用者等待時間的數據圖如下圖 18，同時參考使用者等待時間對畫面品質的影響時，發現這兩條曲線的走向是一致的，也就是說當使用者等待時間增加時，由於緩衝的時間增加使得有充裕的時間取得更多的階層，造成畫面品質隨著遺失率與重複率增加實並無下降。

(A) Loss Rate (B) Duplication Rate Figure 18 Waiting Time and Picture Quality.

Performance of Algorithm

我們利用「失效下載率」來當作演算法效能的指標。失效下載率指的是下載了多少失效的檔案，當取得某個增強層後因取得的時間已經超過其最終播放時間，

則這個增強層便無用處了。當失效下載率越高表示下載越多無用處的檔案，不僅對畫面品質的改善沒有幫助之外，也多增加了不必要的網路流量。

如下圖 19 所示，當我們分別設置延遲時間(A)、遺失率(B)、重複率(C)、錯誤率(D)等參數時，由於 LDS 演算法預先估算了每個階層的傳輸時間，當預測結果顯示某個階層檔案來不及在其最終播放時間之前取得，便提早決定放棄這個可能會是無效的階層，使得 LDS 所取得的檔案幾乎都能完全的增加畫面品質，其失效下載率最低；而 Smooth_No_Delay 以及 Smooth_Delay_1 則是因為增強層皆由較差的節點取得，因此傳輸的時間較長，造成完成下載時已經超過其最後播放時間，使得失效下載率高居不下。因此 LDS 演算法有最高的排程效能，並為 Smooth Algorithm 的三倍左右。

(A) RTT/2 (B) Loss Rate

User Waiting Time

在觀看串流片段的途中，有些區塊在其播放時間之前尚未取得時，必須等待一段緩衝時間等區塊下載完成，才能夠繼續串流片段的觀賞。這些所有等待的緩衝時間累加就為「等待延遲時間」。當等待延遲時間越短則表示該排程演算法越能夠有效率的利用每個區塊的最終播放期限。

如下圖 20 所示，當我們分別設置延遲時間(A)、遺失率(B)、重複率(C)、錯誤率(D)等參數時，LDS 所需要的等待時間稍長一些；而 Smooth_No_Delay 以及 Smooth_Delay_1 則是因為固定由最佳的節點取得基礎層因此傳輸的時間較快，

使得等待時間最短，但也因此造成畫面品質低落以及失效下載率最高。

(A) RTT/2 (B) Loss Rate

Figure 20 User Waiting Time.

下圖 21 說明了 LDS 在各種其況下各個區塊的等待時間分布圖，當延遲時間 (A)增加時除了一開始的區塊會有部分等待時間產生之外，在後面的區塊也產生了一些等待時間。而當遺失率(B)增加時其等待時間都集中在前面的區塊。重覆率(C)與錯誤率(C)增加時等待時間的分布則都很均勻。

(A) RTT/2 (B) Loss Rate

Figure 21 The Distribution for Each Chunk.

Start-up Latency

當使用者送出觀看串流影像的需求一直到使用者真正看到影像的時間稱作

「起始延遲時間」，也就是一開始所等待緩衝的時間。

如下圖 22 所示，當我們分別設置延遲時間(A)、遺失率(B)、重複率(C)、錯誤率(D)等參數時，LDS、Random、Smooth_No_Delay 以及 Smooth_Delay_1 的都落在 15 秒左右的平均值裡。

(A) RTT/2 (B) Loss Rate

Figure 22 Startup Latency.

Picture Quality v.s. User Waiting Time

針對 QoE 的兩項影響因素：畫面品質以及使用者等待時間，從上述結果可得知 LDS 在畫面品質部分有最好的表現但讓使用者等待一段時間，相反的，

Smooth Algorithm 卻是讓使用者等待較短的時間但只提供基本的畫面品質。因此我們想知道在網路環境相同的條件下，若讓 Smooth Algorithm 提供較好的畫面品質時，其等待時間是否依舊較短，如下圖 23 所示，一開始 LDS 提供基礎畫質時須讓使用者等待一些時間，但當畫質需求漸升時，反而 Smooth Algorithm 所需要的等待時間越來越長，甚至超過 100 秒，這是因為所有區塊的增強層都是由 RTT 值次小的同一節點取得，使得此節點的負擔太重造成所有增強層的傳輸時間加長。

因此可得知 LDS 能在有限的等待時間之內提供使用者最佳的畫面品質。

Figure 23 Picture Quality vs. User Waiting Time.

7 Conclusions and Future Works

儘管 P2P 視訊串流技術的應用越來越廣泛，但關於使用者經驗品質(QoE)仍然較少被討論。在本文中，我們考量到 P2P 網路中大量的節點各自擁有不同的使用需求，為了滿足不同使用者的需求，我們利用可調式視訊編碼的特性，讓不同的使用者可依需求觀看不同畫質的視訊影像。

Layer Deadline Scheduling 演算法依每個階層區塊的最終播放時間進行排程，

再利用不同階層的優先權值以及當時的可用頻寬來進行下載順序的調整，如此便可確保在使用者等待的時間不至於過程的情況下可獲得最佳的畫面品質。

要改善使用者經驗品質可從畫面品質以及等待時間這兩個影響因素著手，從表 9 的實驗結果得知我們所提出的演算法 LDS 能提供最佳的畫面品質以及演算法效能，但卻必須付出讓使用者等待的代價。雖然 Smooth Algorithm 的使用者等待時間較短，但上圖 23 顯示當 Smooth Algorithm 所提供的畫面品質越好時所需的等待時間也越大。

Table 9 The Comparison of Results.

LDS Algorithm Random Selection Smooth Algorithm

Picture Quality Best Worse Worst

Performance of Algorithm Best Worse Worst

User Waiting Time Longer Longer Shorter

綜合以上比較可得知 Layer Deadline Scheduling 演算法能有效的改善 QoE，

但事實上，若不考慮畫質改善的部分多重描述編碼(MDC)是較適合用於 P2P 串流服務，因為 MDC 的每個描述子(Description)間各自獨立，不存在解碼時彼此依賴的問題，當某個描述子來不及傳輸時並不會有解碼失敗的情況發生。雖然 MDC 適用於 P2P 串流服務，但僅於學術上的討論並無實際的應用，因此考慮 MDC 並應用在 P2P 串流系統服務是我們下一步欲實現的功能。

Reference

[1] G. Harman, “The Intrinsic Quality of Experience,” Philosophical Perspectives, vol. 4, Action Theory and Philosophy of Mind (1990), pp. 31-52, 1990

[2] H. Schwarz, D. Marpe, and T. Wiegand, “Overview of the Scalable Video Coding Extension of the H.264/AVC Standard,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 17, no.

9, pp. 1103–1129, Sep. 2007

[3] X. Hei, Y. Liu, and K.W. Ross, “IPTV over P2P Streaming Networks: The Mesh-Pull Approach,”

IEEE Communications Magazine, vol. 46, pp.86–92, 2008

[4] M. Mushtaq, T. Ahmed, “Hybrid Overlay Networks Management for Real-Time Multimedia Streaming over P2P Networks,” Proceedings of the 10th IFIP/IEEE International Conference on Management of Multimedia and Mobile Networks and Services: Real-Time Mobile Multimedia Services, vol. 4787, pp.1-13, 2008

[5] M. Mushtaq, T. Ahmed, “Smooth Video Delivery for SVC Based Media Streaming over P2P Networks,” 5th IEEE Consumer Communications and Networking Conference, Las Vegas, NV, pp.

447–451, 2008

[6] T.C. Lee, P.C. Liu, W.L. Shyu, C.Y. Wu, “Live Video Streaming Using P2P and SVC,” Proceedings of the 11th IFIP/IEEE international conference on Management of Multimedia and Mobile Networks and Services: Management of Converged Multimedia Networks and Services, vol. 5274, pp. 104-113, 2008

[7] “JSVM software”, http://ube.ege.edu.tr/~boztok/JSVM/SoftwareManual.pdf

[8] W.P.K. Yiu, X. Jin, S.H.G. Chan, “Challenges and Approaches in Large-Scale P2P Media Streaming,” IEEE Multimedia , vol. 14, no. 2, pp. 50-59, 2007

[9] X. Zhang, J. Liu, B. Li, and T.S.P. Yum, “CoolStreaming/DONet: A Data-Driven Overlay Network for Efficient Live Media Streaming,” In Proceedings of IEEE INFOCOM, vol. 3, pp. 13-17, 2005 [10] “PPLive”, http:// www.pptv.com/

[11] “PPStream”, http://www.ppstream.com/

[12] “TVAnts”, http://www.tvants.com/introduction/superiority.html [13] “Joost”, http://www.joost.com/

[14] E. Setton, J. Noh and B. Girod, “Low Latency Video Streaming Over Peer-To-Peer Networks,”

Multimedia and Expo (ICME), IEEE International Conference, pp. 569-572, July 2006

[15] C. Wu, B. Li, “Optimal Peer Selection for Minimum-Delay Peer-to-Peer Streaming with Rateless Codes,” Proceedings of the ACM workshop on Advances in peer-to-peer multimedia streaming, pp.

在文檔中改善起始延遲及畫面品質之使用者經驗於使用可調式視訊編碼的點對點串流系統 (頁 26-0)