Hi, Justin Todd schrieb:
Realtime H.263 Video (UDP) flows from the encoder to the DVR at 500kbit/sec peak. (avg is about 275-300). There is also a bit of sporatic 2-way TCP communication. ***Problem: When bit errors on the wireless link occur, video will get jerky and get behind (sometimes as much as 20 seconds!) and then suddenly the video will appear to go in fast foward and catch up again! This is clearly unacceptable for realtime video! We would rather lose the occassional packet then have it get behind. QUESTIONS: 1) will doing SNAT twice on a UDP video stream cause considerable or negligable delay?
Should not be measurable unless the Linux machines are totally overloaded. For a reasonably fast machine, 100 MBit/s wirespeed SNAT is possible, so you should be fine.
2) Is there a way to tell the kernel to drop a packet if its not delievered within an acceptable period of time?
You could try to tune the TX timeout, but I have no idea whether there is a sysctl for that.
3) How can you optimize your TCP stack for realtime video?
TCP stack? I thought you were doing video over UDP. Sending video over TCP would indeed explain your problems.
Regards, Carl-Daniel -- http://www.hailfinger.org/ _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
