系統實作

5.2 系統實作

目前傳送 stored video 已有做 smoothing. 但在傳送攝影機即時 影像的情況(也就是 online 資料傳輸)並未加上 smoothing.所以現在

的目標就是將此演算法實作上去.

首先，先了解 Server 如何傳送即時影像.攝影機每秒鐘抓 25 張 照片，每張照片用 JPEG 壓縮後經由無線網路傳到 Server，在 Server 內會將 JPEG 解壓縮，再從新壓縮成 MPEG-4 格式的資料，存在 Server 的 buffer 內，然後再切成一個一個的封包送出去.這個流程就是下面 的系統架構圖中的左半部在做的事情.

圖 5.4 控制封包傳送速度的單元在整個系統中的位置 我們之前已經完成的 stored video smoothing 是在 rate & error control 這個方塊中實作的，在圖中以紅色圈圈標記出來.在此方塊 裡有個 thread 叫作 smoother，當有一個 client 連進 server 就會啟 動一個 smoother，它不斷看系統時間，每經過 40ms，就會發出數個 token 給 streamer，而 streamer 拿到一個 token 就能丟出一個封包，

基本上就是藉由發 token 的快慢來掌控系統的傳輸速度.所以我們只 要在開啟 stored video 檔案時，抓出這個影片的 video trace，用 MVBA 運算一次就能得到 smoothing 的排程，接著把這個排程經過 packet base 的修正，最後修正後的排程會送到 smoother 的手上，

smoother 就是根據這個排程來決定每 40ms 要丟出幾個 token.例如 說，smoothing 的排程從第一個 frame 開始依序是 6，5，5，6，5，4，

5...個封包，則 smoother 這個 thread 就會第一個 frame 時間放出 6 個 token，過了 40ms 後的第二個 frame 時間，就看表放出 5 個 token，

再過 40ms 放出 5 個 token，再來依序是 6，5，4，5...

我們發現在 online smoothing 的情況，從 camera 來的資料會存 在一個 buffer 裡，Buffer 是一串 Link List，如圖 5.4:

圖 5.5 online 影像緩衝區之結構

每個 node 代表一個 frame，新進來的 frame 會接在 Head 的前面.

當新進來的 frame 是第 3 個 I frame，那 server 就會把第 2 個 I frame 之前的 frame 從 buffer 中清掉.這樣設計的目的在於，讓 client 抓 的第一張 frame 是 I frame.因為 client 剛連進 Server 時，總是從

link list 的尾端往回抓資料，而 link list 的尾端會保持是 I frame，所以 client 抓的第一張 frame 會是 I frame.另外有一種情 況，如果有個 client 還沒抓完從第一個 I frame 到第二個 I frame 之間的所有資料，在 Server 端的 buffer 會因為拿到了第 3 個 I frame 而清掉了第一和第二個 I frame 之間的資料，那 client 就會跳過那 些被刪掉的 frame，直接從下一個 I frame 開始抓取.至於為何會有 Client 還在抓資料，Server 卻把那些資料清掉的情形，可能是因為 Client 進來抓第一筆資料的時間點是 Server 快要拿到第 3 個 Frame Server 的 buffer 容量愈大，我們能夠做 smoothing 的視野就愈大(也 就是前面提到的 window size， W)，做出的平順排程可以更平順，

但是相對的，client 會感覺到更大的延遲.這個參數設成 2，就是代 表即時性很高的 online 傳輸.

那麼，在 online smoothing 的情況，我們要怎麼修改現有的

thread 呢?online 與 stored video 最大的差別是資料的來源，從檔 案變成記憶體中的一個區塊.我們想要把第 3 章的演算法套到傳輸平 台中.在演算法中有幾個重要的參數: W: window size， alpha: 運 算周期， b: client 端 buffer 大小，還有就是 d(t): 在 window 內 每個 frame 的資料量大小.

我們需要的參數都在手邊了，現在只要在 streamer 抓取 buffer 裡 online 的資料時，讓 smoother 這個 thread 每 alpha 個 frame 時 間長度做一次 packet-based MVBA 運算，就能決定從運算的時間點 起，到下 alpha 個 frame 時間的 smoothing 排程.所以需要對現有之 stored video smoother 的修正，就是加上一個能即時從系統中得到 MVBA 運算所需各項參數的涵式，以及每 alpha 個 frame 時間長度就 運算一次的判斷式，然後在 streamer 中找到 online 的流程，在適當 的地方放上一個讓 smoother 插手管理丟封包的機制.windows 作業系 統提供了一組 post()和 pend()指令，當執行到 pend()這行指令時，

若記數器為 0，程式會停住，等到其它 thread 執行一個 post()，計 數器內的數字+1，pend()被鎖住的地方就能繼續跑(計數器內數字會 -1).我們利用這組指令來完成 smoother 的控管動作.用 pend()讓系 統在丟封包前停下來，而 smoother 是另一個 thread，看系統時間以 及 MVBA 運算結果執行 post()，這個 40ms 的 frame 要 5 個封包的話，

就執行 5 次 post()，系統中負責丟封包的 thread 就可以丟出 5 個封 包，要丟第 6 個封包前會被 pend()鎖住，在 40ms 後等 smoother 執 行了 post()，才能繼續丟封包.

所以 smoother 是一個獨立於傳輸 thread 外的 thread，負責計算 smoothing algorithm，並且每隔一段時間跟據 smoothing 的運算結 果送出 post().負責傳輸的 thread 在 semaphor 拿到 post()後就能繼 續動作，一個 post()可以讓 streamer()送出一個封包.