Diego Zimmermann wrote:
Sorry, I forgott in the first mail I'm using udp-sender --async --mcast-data-address 229.1.1.1 --mcast-rdv-addr 229.1.1.1 --autostart 1 --fec 8x8/128 --max-bitrate 500k --interface eth1 --portbase 4002 -f announce and udp-receiver --nosync --mcast-rdv-addr 229.1.1.1 --interface dvb0_0 --portbase 4002 -f announce
Indeed, on a LAN this seems to work (changing just the name of the interface)
And the parameters are set up ok for return-channel-less transmission (verified by setting iptables on sender to drop all return traffic: still works).
As communication is now purely unidirectional, satellite latency should not make a difference either.
So, this is really weird, could you check the settings on your routers, encapsulators, etc. to make sure they aren't dropping any packets along the way? A tcpdump taken at the client, and another one at the server (just ports 4002 and 4003) would also be helpful to see whether anything is lost.
However, while running a tcpdump myself, one thing struck me: you set fec to use 8 slices size with 8 redundant packets. This is fine for large files. But for just 1500 bytes (2 payload packets), this is way overkill: indeed, this means that at least 64 packets will be transmitted (8 redundant packets for each of the 8 slices). Of these 8 slices, 6 would be completely useless, as they'd contain _only_ redundant packets, and no data packets.
--fec 1x2/128 would be more appropriate. This would still give you 100% redundancy (2 redundant packets per 2 data packets) but be far less wasteful.
Regards,
Alain