How should i develop my p2p streaming system

Question

i have tried some way as following to develop in half year. But it still not works as i wish.
h1. 1.
h3. main idea:
Use jmf RTP api to link each peers.
h3. implement:
RTPManager( transmitter) ---> RTPManager (receiver )
receiver create a merged CloneableDataSource (2 tracks) to RTPManager for tramsmit on receiver.
And create SendStream to next peer on each RTPManager for tramsmit .
h3. result:
The first receiver have good quality. But the next peer's result is bad and lag. The third peer is worse that second peer.
There is video/audio synchronous problem sometimes. Maybe fail recovery can't be perfect done due to new stream realize time.
h1. 2.
h3. main idea:
Use custom DataSource to buffer a few seconds.
h3. implement:
RTPManager/custom rtp sender( transmitter) ---> DataCatcher ---(sychronized queue)--> PullBufferDataSource ----> Player (create by Manager)
h3. result:
Data reached PullBufferDataSource and buffer for 5 seconds(timestamp subtraction). if player starts, all buffer in PullBufferDataSource will be eated by the player. Screen displayed by the player is quickly go through. Does player do not support auto time synchronization?
h1. 3.
h3. main idea:
Direct transmit data in disk to peer. Use SeekableStream to play.
h3. implement:
Custom data chunk sender( transmitter) ---> catcher(write to data) /////--> ByteDataSource(seekable read from not complete data)
h3. result:
it's good for playing from start to end. But if data chunk sender doesn't sends from first position, player remains sound and video stoped. if sended data play in KMplayer, it works.
Sorry for poor English, and any suggestion?
Thank you in anvanced..

Answer 1

h1. 1.
h3. main idea:
Use jmf RTP api to link each peers.
h3. implement:
RTPManager( transmitter) ---> RTPManager (receiver )
receiver create a merged CloneableDataSource (2 tracks) to RTPManager for tramsmit on receiver.
And create SendStream to next peer on each RTPManager for tramsmit .
h3. result:
The first receiver have good quality. But the next peer's result is bad and lag. The third peer is worse that second peer.
There is video/audio synchronous problem sometimes. Maybe fail recovery can't be perfect done due to new stream realize time.There is a lot of processing involved in doing it this way, most of it unnecessary. That'll add delay, which will result in dropped packets.
A better design would be to implement the RTP forwarding at the network level.
Suggestion: [http://java.sun.com/javase/technologies/desktop/media/jmf/2.1.1/solutions/RTPConnector.html]
Write a custom RTP connector (sender and receiver) such that the receiver will not only receive the RTP packets, but also forward them to whoever it forwards them to. This will minimum the processing on each peer, which will reduce the delay and thus minimize packet loss.
h1. 2.
h3. main idea:
Use custom DataSource to buffer a few seconds.
h3. implement:
RTPManager/custom rtp sender( transmitter) ---> DataCatcher ---(sychronized queue)--> PullBufferDataSource ----> Player (create by Manager)
h3. result:
Data reached PullBufferDataSource and buffer for 5 seconds(timestamp subtraction). if player starts, all buffer in PullBufferDataSource will be eated by the player. Screen displayed by the player is quickly go through. Does player do not support auto time synchronization?RTP systems have a built-in mechanism to prevent the player from going too fast, which is simply, the packets come in real-time, so the player's job is to play them as fast as it can. If you're dropping 30% of your packets, and buffering the packets, you'd expect the player to play the data 30% faster than it should...because those missing packets aren't replaced with blank packets or duplicate packets or anything, they're just simply not in the stream...
Suggestion: Use a PullBufferDataSource that will manage how fast data is given to the player based on the timestamps of the available frames.
For instance, if your player is playing packets at 30 FPS, but you're only getting every other frame (50% frame loss), then you'd want to deliver data one frame at a time with a delay equal to one frame... so read, sleep, read, sleep...etc...
With a PushBufferDataSource, the player will not read data until told to do so with a call to transferData...
h1. 3.
h3. main idea:
Direct transmit data in disk to peer. Use SeekableStream to play.
h3. implement:
Custom data chunk sender( transmitter) ---> catcher(write to data) /////--> ByteDataSource(seekable read from not complete data)
h3. result:
it's good for playing from start to end. But if data chunk sender doesn't sends from first position, player remains sound and video stoped. if sended data play in KMplayer, it works.If you're doing it directly from disk, then you're not including the file header that JMF needs to figure out how to play the file.
Suggestion: If you want to send from some point other than the middle, just grab the file header and append it to the beginning of the stream...