演算法流程

示意流程圖：

圖 3-23 串流資料量調控演算法示意流程圖

完整的演算法流程圖請見附錄 1。

1.每秒取三種輸入值每秒影格 速率、緩衝區緩衝量、畫面動

量，取T 次做平均。

2.檢查緩衝區 使用量>Bl

4b.執行調降函數 DelayCount =0

4a.執行調升函數，

DelayCount =0 3.DelayCount>

DelayBound?

否,DelayCount+1 是

是 否

38

StableDataRate 0 由HighRate和LowRate透過公式運算出的穩定狀態資料 速率，當進入穩定狀態時，資料速率會被設為

StableDataRate。

演算法流程說明

39

設計原因：

取T次做平均是為了拉長演算法執行的間隔時間，降低調升或調降的頻率。因每次執行 調升或調降會去變更視訊擷取裝置的參數，有些參數如B.FPS在設定時會受到硬體的限 制而有延遲時間，同時會消耗非常多的電腦效能。因此每秒取一次值，每T次做平均，

相當於每T秒才會執行一個循環，判斷要做調升、調降或不變更。

步驟二：

檢查平均緩衝區使用量是否高於BufferLimit Bl，若超過則執行調降函數，反之則執行 判斷是否為穩定狀態。

設計原因：

保持目前緩衝區使用量不超過Bl視為整個演算法的最優先目的，一旦緩衝區使用量成 長，將會造成在即時視訊連線活動時出現雙方視訊不同步的情況，同時也會有先收到音 訊後收到視訊情形，這個時間差受到發佈端的緩衝量多少來決定。

只要緩衝區使用量一超過Bl，馬上執行調降函數，以減少目前的緩衝區使用量。反之，

若要執行調升函數，則要加上限制，因為執行完調升函數有機會造成目前緩衝區使用量 的成長，而會再度執行調降函數，如此形成一個調升函數和調降函數交替執行的循環，

本論文稱此循環為「擺盪現象」。

步驟三：

判斷目前DelayCount是否超過DelayBound，若否則回到步驟一繼續執行，若是則表示 有可調升的空間，執行調升函數。DelayBound這個值會受到目前是否為穩定狀態影響。

若目前是穩定狀態，則DelayBound的值會增加，使得要累積更高的DelayCount才能執 行調升函數。當演算法執行了調升和調降各一次之後，會推算出一個穩定值，使得系統 維持在這個值不做調升。

40

設計原因：

增加DelayBound的限制是使提升資料速率的難度增加，因提升資料速率將有機會造成

緩衝量成長。DelayBound的值也受到目前是否為穩定狀態影響，當是穩定狀態時，

DelayBound值會增加，解除穩定狀態則會調回初始值。

為避免一直不斷執行調升或調降的擺盪現象，設計一個穩定狀態判斷機制。

(1)進入穩定狀態的條件是：

當演算法曾執行「調降後馬上調升」時，downup設為 true，並記下此時的資料速率為 LowRate；執行「調升後馬上調降」時，updown設為 true，並記下此時的資料速率為 HighRate。執行到步驟三時，會判斷downup和updown兩個變數是否為 true，若是則判 斷有擺盪現象，並將LowRate和HighRate兩者資料速率取平均作計算得到

StableDataRate。接著進入穩定狀態，將目前資料速率設定在StableDataRate，並且 DelayBound增加 10，使得執行調升資料速率變得困難，同時downup和updown皆設為 false。

ActionBound 50

若Motion Level超過ActionBound，則判斷視訊畫面 處於晃動狀態的依據。

41

四 a.執行調升函數 流程圖（圖 3-24）：

圖 3-24 調升函數運作流程圖

(1) 由畫面動量可知目前發佈端現場的環境是否在活動中，活動量大、畫面變動多，則 視訊擷取裝置的B.FPS也要相對提高，才能取得流暢的畫面。首先判斷畫面動量是

否超過ActionBound，若超過表示目前畫面動態需求高，則在調升時優先順序是：

B.FPS、資料速率、畫面解析度：反之，未超過ActionBound則表示畫面動態需求低，

調升時優先順序是：資料速率、B.FPS、畫面解析度。

(2) 每次在做調升時都會檢查正要調升的項目是否達到最大值，若無法調升則會換下一 個優先順序的項目做調升，直到成功調升或所有項目都無法調升為止。

(3) 執行完調升函數，DelayCount要歸零重新累計。同時，判斷目前不是穩定狀態，

DelayBound設為初始值。

42

四 b.執行調降函數 流程圖（圖 3-25）：

圖 3-25 調降函數運作流程圖

(1) 當減少資料速率時，客戶端程式會提高串流壓縮比以符合減少後的資料速率，如此 可以馬上減少串流資料量，故在演算法設計上會最先判斷是否還可降低資料速率，

若資料速率未達最低值，則會馬上減少資料速率；反之，若已達最低值，則才會依 畫面動量來決定要先調整B.FPS或是畫面解析度。

(2) 若畫面動量超過ActionBound，表示 FPS 需求高，則在做調降時，會先調降畫面解 析度，最後才是B.FPS；反之，若畫面動量未超過ActionBound，表示目前較需要對 畫面品質要求較高，則會先調整B.FPS，最後才是畫面解析度。

(3) 執行完調降函數，DelayCount要歸零重新累計。同時，判斷目前不是穩定狀態，

DelayBound設為初始值。

43