具体见：http://hpds.ee.ncku.edu.tw/~smallko/ns2/Evalvid_in_NS2.htm

I extended Jirka klaue’s work, EvalVid - . I wrote some codes to integrate researchers can easily experiment with MPEG video transmission using the NS2 simulator. One can download the file from here. But, remember to send me an email and add the following paper in your reference if you want to use this tool.

 Chih-Heng , An Evaluation Framework for More Realistic Simulations of MPEG Video Transmission”,  Journal of Information Science and Engineering (accepted) (SCI, EI)

 In the beginning, I describe how to integrate

 p.s. If you want to use the codec provided by this tool-set, you must use windows system. I have no source code for the NCTU codec. If you want to run the simulation under Linux platform, I suggest that you use my newer tool-set at http://140.116.72.80/~smallko/ns2/myevalvid2.htm.

 (Video Demo: how to insert those codes into NS2)

Method 1:

1.      Put a

 Modify the file

 struct

 

        // packet type (see above)

       size_;                // simulated packet size

                // unique id

       error_;              // error flag

            // # of corrupted bits

      

                   // timestamp: for q-delay measurement

                     // receiving interface (label)

  direction_;        // direction: 0=none, 1=up, -1=down

  // source routing

       

 

 //add the following three lines

  int frametype_;               // frame type for MPEG video transmission (Henry)

  double

  // send time (Henry)

unsigned long

 

2.      Modify the file

class

Agent : public Connector {

  void recv(Packet*, Handler*);

．．．．．．

inline

// add the following two lines

  inline void set_frametype(int type) { frametype_ = type; } // (Henry)

  inline void set_prio(int prio) { prio_ = prio; }  // (Henry)

 protect

: ．．．．．．

                // default

 // add the following line

  int frametype_;                // frame type for MPEG video transmission

 

．．．．．．

 private:

  void

};

 

3.      Modify the file

Agent::(packet_t

  sizeframetype_(0),

  channel

 

{

}

 

．．．．．．

Agent::(Packet* p) const

{

 

  ch->uid() = uidcnt_++;

  ch->ptype() = type_;

  ch

->size() = size_;

   /*

 // add the following line

  ch->

．．．．．．

 

4.      Create a “myudp.cc, myudp.h, myudpsink2.cc, myudpsink2.h, and mytraffictrace2.cc in it.

 

5.      modify the file

Add the following two lines

Agent/

Tracefile

set debug_ 0

 

6.      Modify the

Put mympeg/myudp.o

, mympeg/myudpsink2.o and mympeg/mytraffictrace2.o in the OBJ_CC list

 

7.      Recomplie NS2

cd

ns-allinone-2.27/ns-2.27

make clean; make

 

Method 2:

Thanks for Guohan Lu’s help.

1.      Download the patch file. (here)

 

2.      Just put the file mympeg-patch-to-ns2.28.patch in ns-2.28/ and run the following command

patch -p1 < mympeg-patch-to-ns2.28.patch

 

3.      Modify the

Put mympeg/myudp.o, mympeg/myudpsink2.o and mympeg/mytraffictrace2.o in the OBJ_CC list

 

4.  Recomplie NS2

cd

ns-allinone-2.27/ns-2.27

make clean; make

 

[Example]

This example only runs on e wants run on different environment. recompile codes. All codes coded>

 

1.      Encoding a http://megaera.ee.nctu.edu.tw/mpeg/ )

 

mpeg4encoder.exe

 

2.      One can get the compressed MPEG4 file foreman_qcif.cmp

in

3.      Use MP4.exe (from

 MP4.exe –send 224.1.2.3 5555 1000

4.      First, I use a simple topology to test the MPEG4 video delivery over a best-effort service network. The simulation environment is shown below. S1 will use the data in the file be.tcl

. One thing has to be mentioned here. In the

 S1   ----＞  R1 --- ＞R2  ----＞ D1

   ns2 be.tcl

 5.      After simulation, ns2 will create two files, sd_be and rd_be. The file sd_be is to record the sending time of each packet while the file rd_be is used to record the received time of each packet.

 6.      Using the tool et.exe (from Evalvid) to generate the received video (err.cmp).

          et.exe sd_be rd_be st foreman_qcif.cmp err_be.cmp 1

 7.      Decode the received video to yuv format. I also put the status of decoding into a file df_be.

           mpeg4decoder.exe err_be.cmp err_be  176  144  >  df_be

 8.      I think there is something wrong with fixyuv.exe. Therefore I write a new program  myfixyuv.exe to fix the decoded yuv sequence.

         myfixyuv.exe  df_be  qcif  400  err_be.yuv  myfix_be.yuv

 9.      Compute the PSNR. Use the psnr.exe (from Evalvid). But I modify the original psnr.c to add frame number id before the psnr of each frame.

         psnr.exe  176  144  420  foreman_qcif.yuv  myfix_be.yuv > psnr_myfix_be

 10.  Use the same topology above. But I frame packet is pre-marked with lowest drop probability in the application layer at source. P frame packet is pre-marked with middle drop probability and B frame packet is pre-marked with highest drop probability. R1 is implemented WRED. (See qos.tcl)

 

12.  One also can use yuvviewer.exe to see the video sequences.

   

  

 

Overview

of The structure of the as follows.

The main components of the evaluation framework are described as follows:

l           Source: The video source can be either in the YUV QCIF (176 x 144) or in the YUV CIF (352 x 288) formats.

l           Video Encoder and Video Decoder: Currently,

l           VS (Video Sender): The VS component reads the compressed video file from the output of the video encoder, fragments each large video frame into smaller segments, and then transmits these segments via UDP packets over a real or simulated network. For each transmitted UDP packet, the framework records the timestamp, the packet id, and the packet payload size in the sender trace file with the aid of third-party tools, such as te=mailto:Artur%20Ziviani dateTime=2005-04-20T09:22>

• ET (Evaluate Trace): Once the video transmission is over, the evaluation task begins. The evaluation takes place at the sender side. Therefore, the information about the timestamp, the packet id, and the packet payload size available at the receiver has to be transported back to the sender. Based on the original encoded video file, the video trace file, the sender trace file, and the receiver trace file, the ET component creates a frame/packet loss and frame/packet jitter report and generates a reconstructed video file, which corresponds to the possibly corrupted video found at the receiver side as it would be reproduced to an end user. In principle, the generation of the possibly corrupted video can be regarded as a process of copying the original video trace file frame by frame, omitting frames indicated as lost or corrupted at the receiver side. Nevertheless, the generation of the possibly corrupted video is trickier than this and the process is further explained in more details later. Furthermore, the current version of the ET component implements the cumulative inter-frame jitter algorithm for play-out buffer. If a frame arrives later than its defined playback time, the frame is counted as a lost frame. This is an optional function. The size of the play-out buffer must also be set, otherwise it is assumed to be of infinite size.
• FV (Fix Video): Digital video quality assessment is performed frame by frame. Therefore, the total number of video frames at the receiver side, including the erroneous ones, must be the same as that of the original video at the sender side. If the codec cannot handle missing frames, the FV component is used to tackle this problem by inserting the last successfully decoded frame in the place of each lost frame as an error concealment technique.
• PSNR (Peak Signal Noise Ratio): PSNR is one of the most widespread objective metrics to assess the application-level

   

where

k-1 and k = number of bits per pixel (luminance component). PSNR measures the error between a reconstructed image and the original one. Prior to transmission, one may then compute a reference PSNR value sequence on the reconstruction of the encoded video as compared to the original raw video. After transmission, the PSNR is computed at the receiver for the reconstructed video of the possibly corrupted video sequence received. The individual PSNR values at the source or receiver do not mean much, but the difference between the quality of the encoded video at the source and the received one can be used as an objective

• MOS (Mean Opinion Score): MOS is a subjective metric to measure digital video quality at the application level. This metric of the human quality impression is usually given on a scale that ranges from 1 (worst) to 5 (best). In this framework, the PSNR of every single frame can be approximatedte=mailto:Artur%20Ziviani dateTime=2005-04-20T09:25> to the MOS scale using the mapping shown as follows.

                                                          Possible PSNR to MOS conversion.

PSNR[dB]	MOS
>37 31-37 25-31 20-25 <20	5 (Excellent) 4 (Good) 3 (Fair) 2 (Poor) 1 (Bad)

 

New network simulation agents

The following figure illustrates the connecting simulation agents, namely MyTrafficTrace, and are implemented between NS2 and . These interfaces are designed either to read the video trace file or to generate the data required to evaluate the video delivered quality.

 

MyTrafficTrace

The is employed to extract the frame type and the frame size of the video trace file generated from the output of the VS component of . Furthermore, this agent fragments the video frames into smaller segments and sends these segments to the lower UDP layer at the appropriate time according to the user settings specified in the simulation script file.

MyUDP

        Essentially, the UDP agent. This new agent allows users to specify the output file name of the sender trace file and it records the timestamp of each transmitted packet, the packet id, and the packet payload size. The task of the

MyUDPSink  

MyUDPSink is the receiving agent for the fragmented video frame packets sent by This agent also records the timestamp, packet ID, and payload size of each received packet in the user specified file.

Problem of the original YUV program

When the video transmission is over, the receiver trace file has to be sent back to the sender side for the video quality evaluation. Based on the video trace file, the sender trace file, and the receiver trace file, the lost frames can be indicated. If a frame is lost due to packet loss, the ET component sets the

Currently, no standard exists to define an appropriate treatment of Other decoders, such as This type of frame is referred to as

Based on these considerations, a requirement exists to design a new algorithm capable of solving the problem of i.e. reconstructed erroneous video sequence. If a frame is decodable, the improved FV component copies this decoded YUV frame data from the reconstructed erroneous raw video file into a temporary file and keeps it in a buffer as the last successfully decoded frame data. If a frame is

 

[The projects or papers based on this toolset]

l           Chih-Heng , "A Two Markers System for Improved MPEG Video Delivery in a DiffServ Network", IEEE Communications Letters, IEEE Press, ISSN: 1089-7798, vol. 9, no. 4, pp. 381-383, April 2005

l           J. Adaptive Approach for QoS Support in IEEE 802.11e Wireless LAN," in  IEEE International Conference on Wireless and Mobile Computing , Networking and Communications (

l           H. Huang, J. , “Efficient Multimedia Transmission in Mobile Network by using PR-SCTP”, Communications and Computer Networks (CCN 2005), 10/24/2005 - 10/26/2005, Marina del

l           A. Lo, G. Performance Evaluation of MPEG-4 Video Streaming over UMTS Networks using an Integrated Tool Environment", Proceedings SPECTS 2005, 2005 International Symposium on Performance Evaluation of Computer and Telecommunication Systems, Philadelphia, PA, USA, July 24-28, 2005.

l           Vasos Pavlos Antoniou, Requirements for the Transmission of Streaming Video in Mobile Wireless Networks”, International Conference on Artificial Neural Networks (ICANN), Athens, Greece, September 10-14, 2006