實驗七、MyEalvid-NT

實驗目的：

1.瞭解經由更改MyEalVid所得之MyEalVid-NT的系統架構。

2.瞭解可解畫面比例(Decodable Frame Rate)此效能評量指標的意義。

3.瞭解可解畫面比例的分析模型。

4.瞭解如何使用MyEalVid-NT去評量多媒體網路的效能。

5.使用MyEalVid-NT去驗證所得知可解畫面比例分析模型。

背景知識：

這次使用修改MyEvalVid形成的另一個工具組MyEvalVid-NT。

他跟MyEvalVid的差別在於將Evaluate Trace(ET)做了修改，使它能

計算出可解畫面比例(Decodable Frame Rate)、封包/畫面遺失率

(packet/frame loss rate)、封包/畫面的端點與端點延遲(packe/frame

delay)與封包/畫面的抖動率(packet/frame jitter)。

實驗步驟：

先簡單介紹這個實驗的網路架構，Video Server會經由Internet和無線

網路傳送影像到Video Receiver，介於Video Server和無線Access Point

的連接為有線的連接，並且我們假設此有線連接上不會發生封包遺失。

另外，介於Internet和Video Receiver的連接為無線802.11連接，在此

無線連接上會發生封包遺失的情況，所以會導致影像品質變差。

Step1：先到網站抓取video traffic trace file。

Step2：抓取下來的video traffic trace file 之後，打開這個檔案，把前兩行的敘述移除

不過事實上，我打開這個檔案已經沒有那兩行了！

Step3：開cygwin，切換到lab7的目錄下

Step4：進此資料夾之後，直接執行NS2去進行模擬。

整個模擬過程結束之後會產生傳送的記錄檔(sd)和接收的記錄檔(rd)

接下來的效能評估程式et就是使用影片記錄檔、傳送紀錄檔和接收記

錄檔來做分析的動作。附帶說一下，這個模擬過程要稍微等一下下，

一開始只看到SORTING LISTS ...DONE，之後會有一段時間沒看到

動作，稍微等一下下之後，模擬過程結束後就會在繼續顯示後四行文字

(上圖有顯示)

Step5：要做評估分析之前要先轉換trace file的格式，我使用lab7資料夾裡面提

供給的convert.awk來做轉換的動作

這個步驟獲得的Verbose_StarWarsIV.st檔案是影片紀錄檔

Step6：接下來就要使用et這個程式去進行評估分析的動作，他是利用之前的

sd、rd、Verbose_StarWarsIV.st去做比較，如此就可以得知這情況下

，可解畫面數有多少，可解畫面比例的大小為多少。

分析的結果可以得到下列的統計數據：

總共傳送了163682個封包，其中包含28770個I-frame封包，

45339個P-frame封包，89573個B-frame封包

遺失的封包共1595個，其中包含281個I-frame封包，433個P-frame封包

881個B-frame封包。

frame的統計數據：

總共傳輸89998個畫面，其中包含7500個I-frame，22500個P-frame和

59998個B-frame，而遺失的畫面總共1578個，其中包含275個I-frame，

424個I-frame和879個I-frame

然後從這些數據得到可解畫面比例(the decodable frame rate)是

0.913543的大小

Step7：使用lab7資料夾內的delay.awk計算平均延遲時間和最大延遲時間

使用awk擷取資料來繪圖 使用gnuplot繪圖

畫面平均延遲和最大延遲計算

使用awk擷取數據來繪圖 使用gnuplot繪圖 Step8：封包與畫面的抖動率(packet/frame jitter)

封包抖動率，使用awk擷取數據

使用gnuplot繪圖
畫面抖動率，使用awk擷取數據 使用gnuplot繪圖

實驗六、MyEvalVid

實驗目的：
1.瞭解EvalVid的系統架構並得知其優缺點。
2.瞭解整合EvalVid和NS2所得之MyEvalVid的系統架構。
3.瞭解如何使用MyEvalVid來模擬和評估多媒體影像傳輸。
------------------------------------------------------------------------------
先開Cygwin，然後接換到lab6的資料夾
然後使用ffmpeg程式去對yuv檔案轉成m4v
-s : set frame size(qcif是指176*144)
-vcodec : 指定要壓縮的方式(這裡指定用mpeg4去壓縮)
-r : set frame rate(這裡設定每秒30個畫面)
-g : set the group of picture size(這裡設定每一個gop有九個畫面)
-bf : use 'frame' B frame(這裡設定I與P之間或P與P之間有兩個B frame)
-i : input file name(輸入影片檔名為foreman_qcif.yuv，輸出檔案為foreman_qcif.m4v)

轉成m4v的檔案囉!~

接下來要用MP4Box將m4v檔案再轉成mp4
結果出現找不到mvscr70.dll的訊息
上網找了一下，很快就從google找到msvcr70.dll囉!下載下來放到lab6的資料夾

在執行一次MP4Box.exe

OK!成功了!出現foreman_qcif.mp4的檔案

接下來利用mp4trace成是把影片中的每一個frame相關資訊擷取出來並存到foreman_qcif.st的
檔案中

出現foreman_qcif.st檔案下面是檔案內容
使用NS2模擬工具去模擬網路效能

模擬的時候採用random uniform error model和multicast傳送

錯誤率設為0.01，seed為1，最大封包大小為1024

模擬結束後，產生傳送紀錄檔(sd)和接收紀錄檔(rd)

傳送記錄檔，看到送出659個封包
接收紀錄檔，看到收到652個封包，所以遺失率是(659-652)/659=0.011
使用模擬過程產生的傳送紀錄檔(sd)、接收紀錄檔(rd)和影片紀錄檔foreman_qcif.st檔案
和mp4檔案，經由etmp4程式產生一個有畫面遺失的影片foreman_qcife.mp4檔
執行完之後產生了好幾個檔案
接著使用ffmpeg程式將上一步驟得到的重建後的mp4檔回復成yuv影片檔

得到foreman_qcife.yuv檔案

利用avgpsnr程式針對重建後的yuv影片檔及原始yuv影片檔

獲得重建後yuv影片的PSNR值的大小

PSNR=33.607902

使用YUVviewer程式去觀看重建後的影片和原始影片的差別

左邊是原始影片，右邊是重建後的影片

很明顯右邊的影像品質較差

是因為在上面的網路模擬傳輸過程中，有封包遺失率0.011

在傳輸過程中有某些封包丟掉

所以導致重建後的影片品質較原始影像差

實驗五、無線網路封包傳輸遺失模型

實驗目的：

1. 介紹無線網路之封包傳輸遺失模型

(隨機統一模型[分散式遺失]和

Gilbert-Elliott模型[連續性遺失])

2. 瞭解群體廣播(Multicast)與單體廣播(Unicast)

之傳輸模式對於封包傳輸遺失機率之影響。

實驗開始：

情境一：

使用隨機統一模型

(P_G=0.1，loss_model=0)和multicast傳送(comm_type=0)

執行方法：$ns lab5.tcl 0 0 0.1 0 0 0

($ns *.tcl P_GG P_BB P_G P_B loss_model comm_type)

傳送記錄檔(sd)有12351個封包被送出

接收記錄檔(rd)接收到12350個封包，封包遺失率(12351-12350)/12351=8.097e-5

情境二：使用隨機統一模型

(P_G=0.4，loss_model=0)和unicast傳送(comm_type=1)

執行方式：$ns lab5.tcl 0 0 0.4 0 0 1

傳送記錄檔(sd)有12351個封包被送出

接收記錄檔(rd) 有12351封包被接收，

封包遺失率(12351-12351)/12351=0

情境三：使用GE模型

(PGG=0.96，PBB=0.94，PG=0.001，PB=0.05，loss_model=1)和

multicast傳送(comm._type=0)

執行方式：$ns lab5.tcl 0.96 0.94 0.001 0.05 1 0

傳送記錄檔(sd)有12351個封包被送出

接收記錄檔(rd)有12351封包被接收，

封包遺失率(12351-12351)/12351=0