Sinan Nalkaya wrote: The options you want for satellite are --async, --fec, --max-bitrate on the sender, and --nosync on the receiver: udp-sender -f deneme.mpg --portbase 3000 --mcast-rdv-addr 224.2.2.1 -mcast-data-addr 224.2.2.2 --interface eth1 --async --fec 8x6/64 --max-bitrate 39m udp-receiver -f deneme.mpg --portbase 3000 --mcast-rdv-addr 224.2.2.1 --nosync --interface dvb0 The --async parameter instructs the sender not to expect anything back from the client (... which would usually not be possible or advisable for a satellite transmission), and --fec instructs the sender to include redundancy (... as the receiver cannot ask for retransmissions, we need a different way of dealing with packet loss) --fec IxF/N means "for every N datablocks include F Fec blocks, and use I interleave". If less (or equal) than N blocks are lost in a fec group, the group may be recovered by use of these redundant blocks. "Interleave" is meant to offer better protection against burst packet loss (many consecutive packets lost). It works by keeping I fec groups open at once, and alternating among them. So, with I=8 the first packet transmitted will be of group 1, the next of group 2, etc. and the nineth will be group 1 again. The effect of this is that a burst packet loss is spread over many groups. With the parameters above (8x6/64) we can afford to lose 48 packets in a row (which would mean that each of the 8 groups would only lose 6 packets), whereas with no interleave, we would fail at 6. Higher interleave does need more memory though, and introduces more latency. Increasing the F/N ratio increases bandwidth needs (more redundancy) --mcast-rdv-addr sets the "rendez-vous" address, to which the packets are sent that set up the transfer. --mcast-data-addr sets the address of the actual transfer. N.B. Currently, both addresses cannot be the same, but this will be fixed in one of the next versions. The --nosync parameter on the receivers instructs udp-receiver not to use synchronous disk writes. This is important as synchronous disk writes may make the receiver temporarily unavailable for some amount of time, and as the async mode on the server effectively switches off flow control, this may lead to interrupted transfers. With --nosync, the probability of such happening is much, much lower. Regards, Alain