了解如何使用MyEvalVid-NT去評量多媒體網路的效能,然後使用MyEvalVid-NT驗證所得知可解畫面比例分析模型。
背景:為了測是我們提出的網路架構對於多媒體傳輸的效能影響,我們會使用影片做測試,然而因為影片版權問題所以便產生了video traffic trace file 供人下載測試,而為了讓MyEvalVid能夠使用video traffic trace file 去做網路模擬動作,因此便修改MyEvalVid使之成為一個新的工具組MyEvalVid-NT。
修改了什麼呢? 兩者之間的差異在於將MyEvalVid-NT中的Evaulate Trace(ET)做了修改,使其能計算可解畫面比例(Decodable Frame Rate)、封包/畫面遺失率、封包/畫面的端點與端點延遲、封包/畫面的抖動率。
在MPEG編碼中,被編碼的視訊串流被分類為:
Intra-coded frame: 由自己本身畫面做編碼。
Predictive-coded frame:參考先前被編碼的I-frame or P-frame 及自己本身做編碼
Bi-directionally Predictive-code frame:參考先前及後來的I-frame or P-frame 及本身自己的資料做編碼
在一個GOP的I-frame裡,所有屬於這個I-frame的封包都正確被接收到則稱此I-frame可解碼的。同理類推P and B -frame。
為了得到可解畫面比例分析模型,我們要先求得影像檔案中的三個frame可解碼的期望數目
定義: 可解畫面比例 = 所有可解碼的畫面數除以一個影像的所有畫面數
所以囉~可解畫面比例的值越大代表影像品質越好囉!
實驗步驟:
STEP1
到這裡下載video traffic trace file,抓完後打開檔案移除前兩行STEP2
使用NS2進行模擬
模擬結束後,會得到傳送端傳送封包的紀錄檔sd及接收端收到的封包記錄檔rdSTEP3
再進行評估分析前,須先轉換trace file的格式
STEP4
使用et這個程式進行記錄檔sd、rd、Verbose_StarWarsIV.st做比較,就可得知在此種情晃下可解畫面數及可解畫面比例的大小為多少
可知,這次網路模擬傳輸中共送出163682 packets,其中 I-frame:28770 p-frame:45339 B-frame:89573
總共遺失:1595 其中I-frame:281 p-frame:433 B-frame:881
可解畫面比例為0.913543
total directly decodable frame 代表的意義為這個畫面所分割出來的封包全部被接收端所接收到的數目
STEP5
經由下面操作可得平均延遲時間及最大延遲時間
先把資料收集起來 $awk'{print $1, $2}' delay_pkt.txt > delay_pkt
開始繪圖
畫面平均延遲時間及最大延遲時間
封包抖動率:
$awk'{print $1, $3}' delay_pkt.txt > jitter_pkt
沒有留言:
張貼留言
try comments