LARTC - Nov 2005 - Wireless links + Realtime video >= Headache! (long queue delays)

Hello LARTC gurus. I''m new to this list and have a mind boggling
problem that I cannot resolve.  Let me describe my problem:

We have a custom built wireless camera comprised of an IP encoder and a BitsyX
running Linux. It communicates to an antenna unit (Bitsyx) which plugs into a
Windows machine with a digitial video recorder:

[IP Video Encoder] -> [Linux Box 1] - 2Mbit Wireless Link -> [Linux Box 2]
-> [Digital Video Recorder running on XP]

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.

Both linux boxes do SNAT and DNAT using iptables.  Under normal conditions this
scenario works reasonably well (despite the fact that its a bit slow.)

***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?
2) Is there a way to tell the kernel to drop a packet if its not delievered
within an acceptable period of time?
3) How can you optimize your TCP stack for realtime video?



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

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/