<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans Mono'; font-size:12pt; font-weight:400; font-style:normal;"> Here's a bag of tricks: - Make sure your framegrabber is configured at a high framerate. - If it's an analog camera that is digitized by your framegrabber, you need to make sure it doesn't do deinterleaving or other multi-frame tricks. I've had a framegrabber that introduces a 80ms latency for that... - If the framegrabber can do jpeg compression by itself, use that. It's not really faster than doing it on the processor, but you get your compressed data as you go along (otherwise you have a full frame before the encoder and a full frame after the encoder, so a minimum delay of two frames). - Make sure your gstreamer pipeline isn't doing any copies. - Make sure you use v4l2src, which avoids a kernel-to-user copy in the source element. - Configure your kernel to use jumbo packets on the gigabit link. This way you can put a full video frame in each ethernet frame and you avoid fragmentation. - If all that isn't enough yet, you're in for some serious hacking :-). In the v4l2 driver, instead of passing a buffer to user space when you have a full frame, pass it when you have enough data. For already compressed data, it's the size of your UDP packets. For raw data, that means 8 lines (all that's needed for jpeg compression). You'll also need to hack into jpegenc to make it work that way. Therefore, you're probably better off dropping GStreamer altogether and directly ioctl'ing v4l2 data into jpeg buffers. - On the receiver side, the story is more or less the same. Regards, Arnout On Thursday 30 September 2010 09:18:00, STJME wrote: > I am trying to reduce the latency for a live video feed from a camera > connected to a video grabber board, compressing using MJPEG and distribute > it over UDP to a computer uncompressing the video and imediately render the > video to the display. Today, using Dual core Inte CPU's and Gbit network, > the total latency for the above scenario is 200 ms (from the light hits the > camera until the pixel illuminates). > > Q: How can I tweek the latency to get it as short as possible. > > Basically, I want to remove all buffers, compress/decompress with such > codecs and rates so it is as quick as possible. Less focus on packet loss > etc.. -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43 </body></html>