研究生了沒: ns2

顯示具有 ns2 標籤的文章。顯示所有文章

2008年6月14日星期六

實驗八影像傳輸效能分析與評估

實驗目的:了解各種影響影像傳輸的因素

實驗步驟與實驗七差不多

STEP1

使用ffmpeg對yuv檔案做轉換成為m4v檔案，此實驗中使用不同量化程度的視訊串流做比較，參數為qscale,量化階級:2~31

STEP2

接著再用MP4Box將m4v檔案轉成mp4檔案，需注意的是，若之後要使用不同封包大小傳送串流，下面的MP4Box的mtu選項須與之後的NS2模擬環境所使用的封包大小ㄧ致。

STEP3
利用mp4trace將影片中每一個frame相關資訊取出存在foreman_qcif.st檔案中
STEP4
接下來就可以使用ns2模擬工具開始模擬網路效能啦

STEP5

NS2模擬完後產生傳送紀錄檔sd,接收端記錄檔rd,及影片記錄檔foreman_qcif.st and mp4 file,經由etmp4 產生一個有畫面遺失的mp4檔案:

$ ./etmp4.exe sd rd foreman_qcif.st foreman_qcif.mp4 foreman_qcife

STEP6

use ffmpeg.exe to 回復上ㄧ步重建的mp4檔案成yuv檔案

STEP7
使用 avgpsnr.exe獲得重建後的yuv之PSNR value =26.609
影響影像傳輸因素探討

a. 產生GOP length 9的方式:

b.產生GOP length 15 的方式

2008年6月13日星期五

實驗七 MyEalvid-NT

實驗目的:

了解如何使用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，抓完後打開檔案移除前兩行

存檔放入資料夾lab7裡頭

STEP2

使用NS2進行模擬

模擬結束後，會得到傳送端傳送封包的紀錄檔sd及接收端收到的封包記錄檔rd

STEP3
再進行評估分析前，須先轉換trace file的格式

轉換完會得到Verbose_StarWarsIV.st影片記錄檔

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
經由下面操作可得平均延遲時間及最大延遲時間

STEP6

先把資料收集起來 $awk'{print $1, $2}' delay_pkt.txt > delay_pkt
開始繪圖

畫面平均延遲時間及最大延遲時間

$awk'{print $1, $2}' delay_1.txt > delay_1

STEP7
封包與畫面抖動率

封包抖動率:

$awk'{print $1, $3}' delay_pkt.txt > jitter_pkt

畫面抖動率:

$awk'{print $1, $3}' delay_1.txt > delay_frame

2008年6月5日星期四

實驗六: MyEvalVid

實驗目的:

Video Server 傳送影像至 Video Receiver，中間經過Internet 、無線網路，我們討論無線連接造成的封包遺失。

我們針對影像使用MyEvalvid 做Peak to Signal Nosie Ratio 評估，PSNR(峰值訊號雜訊比程式)是一種較為被大眾接受的影像品質鑑定客觀指標。步驟如下

STEP1

我們使用ffmpeg.exe 把工人(foreman)的YUV檔案轉成m4V檔案

-s => set frame size , qcif means 176*144

-vcodec = >指定壓縮方式，如mpeg4

-r =>set frame rate ，這裡設定每秒30個畫面

-g => set the group of picture size，設定每一group有9個畫面

-bf = >use 'frames' B frames，設定I與P之間or P與P之間有兩個frame

-i = >input file name，輸入來源影片 foreman_qcif.yuv

STEP2

用MP4Box把 .m4v 再轉成 .mp4

STEP3

用mp4trace.exe 將每一個frame的資訊擷取出來存到forman_qcif.st中

其中 192.168.0.2 is destination ip ，destination port number is 12346

(這邊設定不重要，因為沒有真的傳上網)

現在在lab6裡頭有這四檔案
foreman_qcif.st 裡面有400筆資料
between H and P or P and P have 2 B frame (與壓縮時的參數相關)

STEP4

開始用NS2模擬工具模擬網路效能 (lab6_1.tcl)

參數為 :

opt(0) = good->good 的機率
opt(1) = bad->bad 的機率
opt(2) = 在 good state下，封包發生錯誤的機率
opt(3) = 在 bad state下，封包發生錯誤的機率
opt(4) = seed number
opt(5) = 把每一畫面切成多少size大小的封包

傳送端送出659個封包，但接收端只收到652個封包

遺失率為0.0106

STEP5

使用模擬過程產生的TX記錄檔sd、RX記錄檔rd 與影片記錄檔foreman_qcif.st 和 mp4檔案

經由tmp4產生一個畫面有遺失的影片foreman_qcife.mp4

STEP6

再次使用ffmpeg將重建的foreman_qcife.mp4 轉回foreman_qcife.yuv

STEP7

使用avgpsnr針對重建後的 foreman_qcife.yuv 及原始foreman_qcif.yuv，獲得重建後foreman_qcife.yuv的PSNR值為34.839083

STEP8
接下來用YUViwer.exe真正觀察影片差異

左邊為原始影像，右邊為重建影像
因為封包遺失率為0.01 所以好像也不怎麼明顯
不過放大後看就有差了，畫面會比較霧些

2008年5月22日星期四

應用程式named "MmApp"(修改CBR程式得來) 衍生自"Application"類別
"MmApp" generate packet , transform by "UdpMmAgent","UdpMmAgent"衍生自"UdpAgent"類別

封包是用"hdr_mm"結構來描述。

程式路徑:
packet.h c:\cygwin\home\STD416\ns-allinone-2.29\common
ns-packet.tcl c:\cygwin\home\STD416\ns-allinone-2.29\tcl\lib
agent.h c:\cygwin\home\STD416\ns-allinone-2.29\common
app.h c:\cygwin\home\STD416\ns-allinone-2.29\apps
ns-default.tcl c:\cygwin\home\STD416\ns-allinone-2.29\tcl\lib

timer-handler c:\cygwin\home\STD416\ns-allinone-2.29\common

2008年4月26日星期六

lab9 無線網路效能分析探討(-) 隱藏節點和暴露節點問題

實驗目的:

了解什麼是隱藏節點和暴露節點
了解 RTS/CTS如何降低隱藏節點問題發生的機會,以提升系統效能 3. 了解 NS2 中無線傳輸模型和門檻的觀念

背景知識:

隱藏節點問題:

節點B在節點A和節點C傳輸範圍內的交集區域內,但是A和C都不在互相的傳輸範圍內,這時有兩個節點A,C同時想傳送資料給節點B,節點A傳送資料給B時,節點C會認為目前網路閒置,同時也會傳送資料給節點B,同時傳送給節點B的資料就會發生碰撞(Collision).

這種因傳送距離而發生的誤判的問題稱為隱藏節點問題(Hidden Terminal Problem).

降低隱藏節點問題

當Tx在送出資料前先發送一個控制封包 (Request to Send),告知Tx傳送範圍內的所有節點不要有任何傳輸的動作,而Rx如果目前是空閒的,則回應一個Clear to Send 封包告訴Tx可以開始傳送料,如此一來就可以降低隱藏節點的問題,但是並不能完全解決!

暴露節點問題

Tx:C 要傳送資料給D時,發現(聽到)傳輸範圍內的B正在傳送資料給A(C是B的暴露節點),Tx:C就會延遲傳送,但這種延遲是不必要的,因為B傳送資料給A與C傳送資料給D並不衝突,因此這種因為聽到傳輸範圍內有節點在傳輸,而延遲傳輸就是暴露節點的問題
使用RTS/CTS
我們可能想到使用RTS/CTS,當C聽到B送出的RTS,但卻沒聽到相對應的CTS,那麼不就可以推論出C是自己是暴露節點了嗎?!所以C可以同時傳送資料出去,但在這種情況下,如果是別人傳送資料給C,那麼就可能預B傳送的資料發生碰撞,所以使用RTS/CTS並不能解決暴露節點的問題
傳輸模型及門檻
NS2實做了一些傳輸模型:

Free Space 是最理想的傳輸模型(檔案在~/ns-2.29/mobile/propagation.h & propagation.cc)

Two Ray Ground 除了考慮直線 path loss也考慮地面反射(reflection of ground)
(檔案在~/ns-2.29/mobile/tworayground.h & tworayground.cc)

Shadowing 是用來模擬Tx到Rx中間有障礙物時對傳送訊號的影響,常用於indoor
(檔案在~/ns-2.29/mobile/shadowing.h & shadowing.cc)

關於"門檻",NS2主要利用訊號強度門檻(Threshold)方式,判斷封包是否成功收到
NS2設定一個訊號偵測(Carrier Sense)的門檻CSThresh_ ,決定封包是否能被Rx偵測出來 (於PHY Module)
NS2會設定另一個RxThresh_ ,用來判斷封包是否能被Rx所接收 (於MAC)

(檔案在~/ns-2.29/mobile/wireless-phy.h & wireless-phy.cc)

開始實驗步驟

STEP1.

ns2提供一個小工具程式threshold.cc(在ns-allinone-2.29/ns-2.29/indep-utils/propagation)，他可以藉由輸入想要使用的傳輸模型和有效傳輸距離，而輸出相對應的參數值

用g++編譯它