[libdc1394-devel] Re: HANG on dc1394_dma_multi_capture
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Dan D. <da...@de...> - 2002-07-23 02:16:33
|
On Mon, 2002-07-22 at 12:43, Andrew Hogue wrote: > I have another question though... what is the significance of the number > of dma buffers that you initialize the camera with? I've noticed that if > I change this number sometimes nothing works and then I increase it and it > works but there is a huge delay... am I right to think that there is a The significance is only that you need to allocate enough buffers so you never get completely behind. You will get behind in capture due to background processes, window dragging, etc. Then, hopefully the app catches up by using up the buffers and releasing them before they all become used. > buffer of images that you are storing somewhere of this size so you can > get the most recent image? If so, where is it stored? Is it stored in It is stored in memory unless it gets paged, let's hope not. There are two buffer areas. One is within video1394 that the dma addresses, and this is mmap'ed into userspace; hence the "dma" capture functions. The other buffers are internal to libdc1394 due to the nature of video1394 and multicapture. video1394 can return more than one ready buffer! However, each call to dma_multi_capture returns one image per camera. Therefore, if more than one buffer is returned, then the extra buffers are stored internally and returned on subsequent calls to dma_multi_capture(). That's just the nature of the beast. All in all, it makes libdc1394's multicapture functions rather sophisticated! > main memory or on the hard disk... right now, I have a large delay > occurring with 3 dma buffers but nothing works if I make this smaller... There should be only a slight delay using one camera. With many cameras, you can expect delays. How many cameras are running when you report this? > I've also noticed that the harddrive is thrashing around and it sounds > like its paging quite a lot which will decrease the performance and thus > the framerate... Absolutely, paging will definitely kill the performance. My example program is not very efficient by allocating an array of cameracapture structs. A more robust program will use dynamic memory allocation. For a quick fix, in dc1394_multiview.c, change the allocation of the array from: dc1394_cameracapture cameras[MAX_CAMERAS*MAX_PORTS]; to just dc1394_cameracapture cameras[MAX_CAMERAS]; Then, for each camera, it will allocate 2*x buffers, where you have siad you are using x=3. If it has to convert the yuv format or convert rgb to yuv, then there is another buffer for the target of the conversion operation. Then, this gets put into the display buffer on video hardware using Xv. You could reduce the memory overhead of the last step by using XvShm. Let's see... 640*480 *2 bytes/pixel (YUV4:2:2) = 600k *6 buffers (3 * dma+internal) = 3600k *8 cameras = 28,800k or 28MB. Because I had a bad array size, if you had set MAX_PORTS=3 and MAX_CAMERAS=8, then it allocated 24 cameracapture structs and use >84MB just for buffers! +-DRD-+ |