This  directory  contains  the  source  code  for the MPEG1 video
stream network traffic simulator.

The binaries are at /usr/dirt/bin.

Also read /usr/dirt/bin/mpeg_README.

The source code files are at /usr/dirt/src/mpeg.

The above directory also contains the file README.

Also the input  files  to  the  server  for  the  movies  ET  and
Crocodile  Dundee are at /usr/dirt/src/mpeg. The files are et.frm
and croc-dundee.frm respectively

The system is arranged as a client server with the file  mtraff.c
containing  the code for the server and mclient.c containing code
for the client. The video stream is played out over  the  network
by  the  server using UDP. The server expects an input file which
specifies the following on each line:

<Frame Type> <Frame size in bytes>.

It is assumed that the input file specifies the type and size  of
frames  in  play order. The server simply generates frames at the
specified frame rate. Note that the frames traverse  the  network
in  play order. The receiver reassembles frames and gives them to
a dummy Mpeg1 video decoder that simulates the working of a  real
mpeg  decoder.   The receiver generates statistics at regular in-
tervals of time. More about this a little later.

The server expects the following command line options:

o -sp : The port to be used by the server

o -c : The client ip address - which may be  in  DNS  or  numeric

o -cp : The port to be used by the client.

o  -f : The name of the input file containing frame stream speci-

o -fr : Frame rate at which frames are sent into the network.

All five options are compulsory and must be specified.  The  fol-
lowing option is required in the special case as explained:

o  -nondefault  :  This switch is required if both the sender and
receiver are on the same machine. In that case it is assumed that
the machine has more than one ip address and packets are sent out
thru one interface and are received at the other after traversing
a  network. This switch should be followed by the ip address (nu-
meric format only) chosen at the sender.

For example, consider a machine talley  with  2  ip  addresses  -  and If you want a setup where packets
go out of and traverse a network and are received at Then the sender may be specified as :

mtraff -c -sp 6100 -cp 6200 -f croc.frm -fr 30 -non-

Basically this forces the sender port to bind to  the  136.48  ip
address.  Also note that since both processes are on the same ma-
chine the sender port and receiver port must  be  different  from
each  other.  Also  see the description for the nondefault option
for the client.

The receiver expects the following command line options :

o -cp : The port to be used by the client

 o -s : The server ip address - which may be  in  DNS  or  numeric
format.  Note  that if  a specific ip address was specified using
the -nondefault switch at the sender , then that same numeric  ip
address must be specified here at the client.

o -sp : The server port

o  -i  :  The resolution interval - over which the statistics are

   Statistics are printed at the end of the interval.

o -d : debug log file . Implicitly begins debug mode.  The  debug
file contains a printout of the successive
       frame  types  and frame numbers of frames successfully de-
coded. Any out of sequence frames are also reported.

o -l : output file for packet number vs network latency plot. Im-
plicitly turns on latency report mode. An xplot file
       is generated featuring network latency on y axis and pack-
et number on x axis. The report of latency assumes that the
       sender and receiver have a synchronized clock.

 The former 4 options are compulsory whereas the latter 2 may  or
may  not  be specified. The following option must be specified at
the client in the case that both the sender and the receiver  are
on the same machine.

-nondefault  :  This is complementary to the nondefault option as
explained for the sender. Use this option to specify which ip ad-
dress  the client must use when both client and server are on the
same machine, which is assumed to have more than  one  interface.
For example, in keeping with the sender specification for the ma-
chine talley, the client, also on  talley  may  be  specified  as
mclient  -s -sp 6100 -cp 6200 -i 5.00 -d debug.file
-l latency.xpl -nondefault

The receiver generates a one line report containing the following
statistics at the end of every resolution interval :

T - absolute time

PFR - Playable frame rate

TFR - Total Received Frame Rate

ATFR - Average Total Received Frame Rate. A  running  average  of

Thruput - Thruput over the last interval in bytes/sec

AL - average latency - a weighted average of the latency of pack-
ets received in the current interval

PLR - Packet Loss Rate (Packets Lost Per Second) over the current

PRR - Packets received per second in the current interval

The  systems  features an MTU size of 1470 and handles packetiza-
tion and reassembly as a special layer  above  the  sockets.   No
fragmentation by UDP occurs.

If you seek further clarifications on the tool, send email to :


Hope this helps.