總結

最後對 smoothing 演算法的流程在此作一個總結，一開始根據接 收端緩衝區的大小和播放的 video trace，依照 2-1 和 2-2 兩式建立 上限及下限。然後找出一個在上下限之間最平順的排程。

MVBA 是找排程的演算法中的其中一種，特點是能保証有最小的 rate variance，也就是標準差會比其它演算法還小。若有興趣了解 詳細的數學證明，可以參考[13]。

這個演算法原本是應用在 stored video 上的。我們將在下一章 探討如何將此設計修改以到適用於 online 的情況。原本在 stored video 的情況下會考慮快轉和倒轉時該怎麼做 smoothing，但在 online 的情形下，即時播放的影像不會用到快轉和倒轉，所以這部 份就不多做討論。

第三章 Online smoothing

3.1 Online 與 stored video

在前面一章已說明過 smoothing 的功用和作法， Smoothing 就是 預先在有大流量之前先多傳一點資料.舉例來說，就像是已知未來一 個月每天有多少工作量，為了減少在某段期間特別忙碌，而在較清閒 的日子事先完成未來的工作.如此一來，可以避免工作量超過負荷的 情況.且在想要同時做兩，三份工作的情況下，也方便分配與管理工 作量.

Smoothing 要傳輸的資料來源可以分成 stored video (可以想成 是 VOD， video on demand)和 online 兩種類型.STORED VIDEO 就是 要傳送的資料都已經完整地放在傳送端的硬碟裡，像是電影檔案;而 online 類型則是指欲傳送的資料要即時產生，例如視訊會議，或是 即時轉播的新聞，球賽.而同樣是 online 類型，又會因為使用者能夠 容忍的延遲長短不同而需要不同的"即時性".例如說即時轉播就能有 比視訊會議更大的延遲，看到延遲 10 秒鐘的球賽還沒什麼關係，但 用視訊溝通時，10 秒鐘的延遲大概會讓人想砸電腦吧.

Smoothing 可說是一種排程的工作，然而針對上述兩種類型的資

料來源， smoothing 的做法也有不同. 我們先分析這兩類資料來源:

1. STORED VIDEO:因為我們傳送端已經知道所有要播放的資料，所以 不管是每隔多久播出一個 frame，或是一個 frame 有多大，這些資 料都是已知的.所以 smoothing 要做的事就是把這所有的資料，從 頭到尾安排何時送資料，每次又送多少.

2. online:傳送資料即時產生，傳送端只知道數個 frame 時間長度的 資料量，我們能做排程的內容就是傳送端現有的這些資料量.

暸解 STORED VIDEO 和 online 有什麼異同之後，接下來的問題是:

1.online 的情況能否套用已有的演算法，也就是使用 STORED VIDEO 跑的 MVBA 演算法，如果可以套用，需不需要做什麼修改?

2.修改之後的 online MVBA，其效能比起 stored video 能一樣好嗎?

抑或是較差?差了多少?

接著讓我們來回答上面兩個問題:第一個問題，會在接下來的 3-2 和 3-3 小節敘述修改的方法;第二個問題則放在第四章的模擬結果中 討論.

3.2 fix size,non overlapping window smoothing

首先，我們已有一個用在 stored video 的 smoorhing 演算法，

即 MVBA.若給它一段 N 個 frame 時間長度，每個 frame 各要傳 d(t)

個 bytes 大小的資料(1<t<N)，再給它接收端的 buffer 大小 B，此演 算法就可以依此兩個參數，重新安排出這段 N 個 frame 的時間內，每 個 frame 傳多少 bytes 的資料，使得整體傳輸速率的標準差最小.所 以 MVBA 這個涵數的輸入有兩個: d(t)和 B，輸出是 A(t)， 1<t<N.

在 stored video 上，d(t)是已知的，因為整個電影檔都在手上，

當然知道每秒要播出幾個 frame，每個 frame 又有多大，B 的大小就 window 為單位的計算方法，我們稱為 fixed size， non-overlapping window smoothing，意即運算的範圍一次跳動一個 window.

在做 MATLAB 模擬的時候，我們可以把整個影片的 video trace

分割成很多個以 W 為一組的小段，以此模仿 online 情況下，傳送端 收集一個 window(W 個 frame 時間長度)的動作，然後每個 window 做 一次 MVBA.

這個做法的缺點是，如果 window 的第一個 frame 要傳大量資料，

就無法預先傳送，如(圖 3.1)所示:

圖 3.1 第二個紅框 window 無法先傳 I frame 的情況 圖 3.1 是一段 MPEG-4 影片中的某 50 個 frame 的大小，如果 W=20(藍框)， 第一個藍框 window 經過 MVBA 運算後，位於框內最後 面的那根大資料(I frame)就能預先分擔掉;若 W=15(紅框)，因為 I frame 出現在第二個紅框 window 的前面部份，而且每個 window 是彼 此獨立的，所以沒辦法在前一個 window 提前傳送.

還有另一個缺點是，在 window 的第一個 frame 和最後一個 frame 都會形成 critical point.因為 MVBA 就是要對輸入的 N 個 frame 的 D(t)，找出一條介於 D(t)和 B(t)之間，從 0 到 D(N)的曲線，所以在 0(曲線的起始點，第一個 frame)和 N(曲線的終點，最後一個 frame) 都會有個 critical point.但其實這兩個 critical point 在 online 的情況下是不一定必需的，而多餘的 critical point 會造成

smoothing 效能的下降，從圖 3.2 可以看出來.

圖 3.2 non-overlapping-window 造成多餘的轉折點(紅圈) 圖 3.2 是個用 hopping-window smoothing 演算法規劃傳輸速率 的例子，本例的 window size 為 30 個 frame，一個青色的框框即代 表一個 window. 綠，藍，紅三種顏色的細線是規畫出來的排程，之

所以用不同的顏色畫線，是為了區分出是在不同的 window 中規劃出 來的.

我們可以發現，window 與 window 之間的 critical point 就算拿 掉也不會造成 underflow 或 overflow.就如圖 3.3 的粗紅線所規畫的 線段.

圖 3.3 粗紅線是沒有做 window 切割的 smoothing 規劃結果 從圖 3.3 中可以看出，沒有用 window 切開的規劃(粗紅線)比 hopping window 的方法平順(綠/藍/紅紦的細線).也就是說，本來可 以用一個速率滿足要求的情況，因為用 window 隔開而造成了多餘的 轉折點，所以必須分成許多段的速率來完成規劃，這麼做的壞處是會 拉高整體傳輸速率的峰值 peak rate.原因如圖 3.4

若 AB 線段是我們原先規劃出的傳輸速率，如今在 AB 間多了一個 轉折點 D，我們的規劃的線段就變成 ADB 連線，很明顯的可以看出，

AD 的斜率就比 AB 的斜率大，也就是 peak rate 提高了.

C

A

D B

E

圖 3.4 多餘的轉折點造成 smoothing 效能的下降

再來看有兩段的情況，若 ABC 線段是我們原先規劃的傳輸排程，

現在多了個 E 轉折點，而使最後結果變成 ABEC 連線，結果不難發現，

EC 的斜率比原先規劃的 BC 斜率大，依然是拉高了 peak rate.

最後做個總結，使用 hopping window 的方法會有二個問題， 第 一個問題是每個 window 之間會多出不必要的轉折點，我們把

hopping-window 變成 sliding-window 的方法後就能克服，這在 3.3 小節介紹 sliding-window 時一併說明;第二個問題是，出現在 window 最前端的大 frame 無法預先傳送，這個問題在下面一段文章討論;

第二個問題的原因在於，因為是 online 的傳輸，所以 MVBA 運算

時並不知道這次運算的 window 範圍外，接著會來的 frame 資料量是 大或小，但如果傳送的資料是用 MPEG 4 壓縮的話，傳輸資料的大小 會有個周期性的規律，特別是資料量很大的 I frame 每隔一個

GOP(group of pictures)會出現一次，所以我們把 window size 設為 GOP 值，然後讓第一個 window 多傳送一個 frame，也就是從第一個 I

先規劃傳送.但實際上，第 1 個 window 剛算完 MVBA，過了 2 個 frame 時間長度後，buffer 裡就已經放了那根資料量大的 frame，如果我們 能提前在第 2 個紅框 window 之前多計算一次 MVBA，就能考慮到已經 放在 buffer 裡的大 frame 了.也就是說，本來是每隔 W 個 frame 時間 長度要算一次 MVBA，現在為了解決"放在 window 前面的大 frame 無 法分攤傳送"的問題而要加班，在兩次 MVBA 的計算間隔內再多算一次 MVBA.假設我們是在 W/2 加班一次，那這次看到的 window 就如圖 3.5.

圖 3.5 在兩次 MVBA 的計算間隔中多算一次 MVBA.

在這裡有兩個地方要考慮:

(1)我們該在兩次 MVBA 之間的哪個時間點多算一次?

(2)假設第 m 個 window 的開始時間為 0，且在 W/2 加班一次，則產生

問題(2)會在接下來的 3.3 和 sliding-window smoothing 演算法 一起討論.

3.3 Sliding-window smoothing algorithm

在[3]有提到一種叫 sliding window 的演算法，也可以解決上一 節的問題(1).其做法也是定一個 window size 為 W 的 window.接著每 隔 alpha 個 frame 的時間長度就重新計算一次，就像是把這個 window 滑動 alpha 個 frame，然後做一次 smoothing 的運算，其中 1< alpha

<W，圖 3.6 是 Sliding window 運算的時序圖.

圖 3.6 Sliding window 運算之時序圖

在 alpha=1 的情況下，就相當於 buffer 每進來一個 frame，就重 新計算一次 smoothing 的排程.這樣做會用掉大量的運算量.如果 alpha=W，就變成 hopping-window 的方法;若 alpha=W/2，其演算法 就剛好是前一小節提到的方法，就是在兩次 MVBA 中間 W/2 的地方再 加班一次的做法.然而[2]的模型比較通用，所以我們採用這個模型.

但[2]只提出 sliding window 的概念.並沒有詳細說明如何將 stored video 的 smoothing 演算法改進成適用於 online，這部份就是我們這

個章節要說明的.

現在來回答 3.2 提到的問題(2):圖 3.6 中，從 alpha 之後的每個 index 都有重複算了 2 次以上的 MVBA，也就是同一個 index 會有兩種 以上的排程結果，那我們該怎麼決定最終的傳輸排程? 最初沒有注意 到這個問題，把 2 次 MVBA 求出的轉折點都保留下來最後會有如圖 3.7 的情況發生，竟然規劃出負的傳輸速率

圖 3.7 混合了多次 MVBA 求出的轉折點，造成了負的傳輸速率 以圖 3.7 中的例子來說，因為做兩次 MVBA 有可能算出前一個轉 折點在第 162 個 frame index，且是在 upper bound 上，而後一次 MVBA 算出的轉折點在第 163 個 frame index，且是在 lower bound，最後 這兩次的結果都留下來，就會產生負的斜率.

合理的做法應該是以最後運算的結果為主，因為最後一次運算有 一個 critical point 出發，因為 critical point 本身就是個起始點，

從此出發，就不會無故在 window 的起點多加一個在 lower bound 上 的轉折點.在程式碼中，我們多加了一個儲存前次 critical point 的 變數 ts_last.每經過 alpha 個 frame，就會運算一次 MVBA，而運算 結果只決定了前 alpha 個 frame 的傳輸排程(alpha 之後的排程會由 之後的 MVBA 做決定).所以 ts_last 這個變數負責記錄 MVBA 的結果 中，位於 window 的前 alpha 格內的最後一個 critical point.這樣 做能成功消除負斜率的產生.

上一段敘述中，我們決定"從該 window 範圍的前一個 critical point 出發"，這裡忽略了一點:對已經送出的封包做規劃沒有意義.

也就是說，在這次 window 之前的時間，已經按照前一次規劃好的排 程傳出封包了.要從前一次 critical point 的時間點重新規畫，就算

做出了更平順的規劃，也沒辦法實行，因為那是一段已經過去的時間.

做出了更平順的規劃，也沒辦法實行，因為那是一段已經過去的時間.