[LARTC] Wireless links + Realtime video >= Headache! (long queue

[LARTC] Wireless links + Realtime video >= Headache! (long queue

[Justin Todd]

[-- Attachment #1.1: Type: text/plain, Size: 1383 bytes --]

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?


[-- Attachment #1.2: Type: text/html, Size: 2586 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

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

Re: [LARTC] Wireless links + Realtime video >= Headache! (long queue

[Carl-Daniel Hailfinger]

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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc