SYSTEM ANALYSIS

Existing system
When a new peer requests to join an existing peer, it specifies the sub-stream(s) it would
like to receive from the existing peer. These sub-streams do not have to be consecutive.
Contingent upon availability of bandwidth at existing peers, the receiving peer decides how to
multiplex a stream onto its set of neighboring peers, giving rise to our description of the Zattoo
live streaming protocol as a receiver-based, peer division multiplexing protocol. The details of
peer-division multiplexing are described in Section II-A while the details of how a peer manages
sub-stream forwarding and stream reconstruction is described in Section II-B. Receiver-based
peer division multiplexing has also been used by the latest version of Cool Streaming peer-topeer protocol though it differs from Zattoo in its stream management (Section II-B) and adaptive
behavior (Section II-C) [4].
To obtain a list of potential neighbors, a joining peer sends out a SEARCH message to a
random subset of the existing peers returned by the Rendezvous Server. The sub stream indices is
usually represented as a bitmask of n bits, where n is the number of sub-streams defined for the
TV channel.
Disadvantages
High in memory need.
Packet loss ration high.
Cannot able send multiple videos at same time.
Slow data transmission.
Not good continuous video streaming.

Proposed system
We propose a general framework for streaming of pre-encoded media data in multi path
networks, which encompasses network and media aware metrics.
We perform the first theoretical media flow analysis on the optimality of number, and choice of
network paths, in terms of end-to-end Quality of Service.
We provide a linear time media aware routing algorithm that outputs the optimal set of network
paths to be used in the streaming process, along with the corresponding flow rate distribution.

ADVANTAGES OF EXISTING SYSTEM:

Fully connected network, link capacities decrease with distance

Random cross traffic so no data loss.
Streaming 100 kbps from sender to receiver.
High speed video streaming without buffering.
Congestion is expected delay of packet
Low memory and bandwidth is needed to deliver video within the groups.

MODULES DESCRIPTION:
This Project Has Following Three Modules
Transmitter
Receiver
RTCP monitor
Transmitter:
This Modules is used to transmit raw bit video information contained as packets .it maintains
packets information when the receiver will receive the packets from the transmitter. Initially user
wants the ip address and port number of the target machine that is receiver side machina .The
Following Protocols are Used in This Transmitter Module.
Protocols:
Video For window (VFW)
Real Time Transport Protocol(RTP)

The VFW sends media files to RTP. The RTP sends it to the receiver side machineVFW
sends the media files to JMF. It can capture, playback, stream, and transcode multiple
media formats .
The RTP Can Act as Multiple Mode as Follows
Unicast Method:
Allows only one client to connect and receive the transmission

 Multicast method:
Allows multiple clients to connect to the server. Obviously the multicast allows more
flexibility with the allowance of more than a single user to get the content

It can capture,

playback, stream, and transcode multiple media formats

Receiver:
This Modules is used to Receive raw bit video information contained as packets .it maintains
packets information when the Transmitter will Complete the packets .the packets from the
transmitter.Initially user wants the ip address and port number of the target machine that is
receiver side machine.The Following Protocols are Used in This Transmitter Module

RTCP Monitor:
RTCP monitor is adapted in both sender side as well as the receiver side.
In both side it will report the information passed across the channel (i.e.)
the timings of packets. is a real-time end-to-end transport protocol. However, considering RTP as
a transport protocol may be misleading because it is mostly used upon UDP, Which is also
considered as a transport protocol. On the other hand, RTP is very closely coupled to the
application it carries. So, RTP is best viewed as a framework that applications can use to

implement a new single protocol. RTP doesn't guarantee timely delivery of packets, nor does it
keep the packets in sequence. RTP gives the responsibility for recovering lost segments and
resequencing of the packets for the application layer. There are a couple of benefits in doing so.
The application may accept less than perfect delivery and with video or speech there usually is
no time for retransmissions. Also the sender may provide, instead of retransmission, new or
updated data that tries to fix the consequences of the original loss

SYSTEM ENVIRONMENT

HARDWARE REQUIREMENTS:

System

: Pentium IV 2.4 GHz

Hard Disk

: 40 GB

RAM

256 MB

Key Board

LG

Mouse

: Logitech

Floppy Drive

: 1.44 MB

Monitor

: 15 inch VGA Color monitor

SOFTWARE REQUIREMENTS:

Operating System

: Windows XP Professional

Front end

: Netbeans 8.0

Coding Language

Java