Thread: [libdc] where to set "drop_frames"
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Robert H. O. <ol...@bn...> - 2008-11-10 17:14:04
|
from http://damien.douxchamps.net/ieee1394/libdc1394/v2.x/faq/#How_do_I_minimize_frame_latency "or set drop_frames (and a large DMA buffer) to get only the freshest frame when you are ready to process it" I have been unable to find where to set this. I am using libdc1394-2.0.2 After failing to find a way to specify frame_drop I tried the following: #ifdef LOW_LATENCY // testing.... is this the way to catch up and get the latest frames? Dropping everything and getting a new one? backedUpCount = 0; // keep emptying frames until there aren't any so the next dequeue will get a fresh one while(dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT, &(frames[i])) != 0) { backedUpCount++; dc1394_capture_enqueue(camera, (frames[i])); } printf("backedUpCount: %ld\n", backedUpCount); #endif dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT, &(frames[i])); Which failed with the following error message: .... backedUpCount: 0 backedUpCount: 0 libdc1394 error: VIDEO1394_IOC_LISTEN_WAIT/POLL_BUFFER ioctl failed! Segmentation Fault In short, I want to "get only the freshest frame" when I get around to processing a new. Thanks in advance for any help! |
From: vagvoba <va...@ya...> - 2008-11-12 19:50:11
|
Hi, I'm very impressed with the usability of the DC1394 library. Everything seems to be working great until I start capturing from multiple cameras on multiple threads. It usually works without problems but when the CPU has other heavy computations to do in the background the camera frames tend to break. It's hard to describe how they break but it seems like the frame buffers get shifted and overwritten. Is it possible that some dc1394 functions are not thread safe and cannot be called in the same time? Or can it be another issue? The functions that may be called simultaneously in my code are: - capture_dequeue - convert_to_RGB8 - capture_enqueue Thanks for the help in advance, Balazs Vagvolgyi |
From: Holger R. <Ra...@mr...> - 2008-11-13 09:04:15
|
Hi, you might want to try to increase your ring buffer size. This worked for me. Greetings, Holger Am 12.11.2008 um 20:50 schrieb vagvoba: > Hi, > > I'm very impressed with the usability of the DC1394 library. > Everything seems to be working great until I start capturing from > multiple cameras on multiple threads. It usually works without > problems but when the CPU has other heavy computations to do in the > background the camera frames tend to break. It's hard to describe how > they break but it seems like the frame buffers get shifted and > overwritten. > Is it possible that some dc1394 functions are not thread safe and > cannot be called in the same time? Or can it be another issue? > > The functions that may be called simultaneously in my code are: > - capture_dequeue > - convert_to_RGB8 > - capture_enqueue > > Thanks for the help in advance, > > Balazs Vagvolgyi > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: David M. <dcm@MIT.EDU> - 2008-11-13 18:33:40
|
On Wed, 2008-11-12 at 14:50 -0500, vagvoba wrote: > The functions that may be called simultaneously in my code are: > - capture_dequeue > - convert_to_RGB8 > - capture_enqueue > Balazs, As long as functions for a single camera are kept within a single thread, you should be fine with regards to thread safety. It is okay to access different cameras from different threads. The only thing you can't do is access the same camera from different threads. That said, it's always possible there's a bug that I'm not aware of. To be sure, you could try implementing your code single-threaded to see if the situation improves. However, it sounds like your problem might be FIFO overruns on your firewire controller. If there's a lot of PCI bus activity, the firewire card's FIFO can overflow before packets are transferred off the card. Some cards have a FIFO as small as 4K, which can cause this problem. Unfortunately, libdc1394 can't currently detect this type of error in software, although it might be possible to do it in the future. As Holger said, you might also just need to increase the buffer size of libdc1394. If you send a screenshot of a corrupted image to the list, I can judge better if this is the cause of your problems. You might try switching to a different firewire card. I've also seen certain motherboards that just don't do a good job mediating the PCI bus. -David |
From: David M. <dcm@MIT.EDU> - 2008-11-13 18:42:24
|
Hi Robert, The drop_frames option has been removed from version 2 of libdc1394. The documentation you are reading should probably be updated to reflect this (Damien?). The reason it was removed was because the OHCI 1394 specification does not allow it to be achieved reliably at a low-level. However, it is not hard to do what you want at a high-level: Make sure you always read frames out of libdc1394 as fast as possible. Depending on the design of your application, you may want a separate thread for this. Make the latest frame available in a buffer somewhere that's available to the rest of your application. As long as you always dequeue frames as soon as they are available, you won't fall behind. The reason libdc1394 can't do this automatically is that the firewire controller will stop capturing data if the application stops reading. We prefer not to add "behind-the-scenes" buffering to libdc1394 as this would add separate threads and memory consumption that might interfere with the design of low-level applications. -David On Mon, 2008-11-10 at 12:13 -0500, Robert H. Olsen wrote: > from > http://damien.douxchamps.net/ieee1394/libdc1394/v2.x/faq/#How_do_I_minimize_frame_latency > > "or set drop_frames (and a large DMA buffer) to get only the freshest > frame when you are ready to process it" > > I have been unable to find where to set this. I am using libdc1394-2.0.2 > > After failing to find a way to specify frame_drop I tried the following: > > #ifdef LOW_LATENCY > // testing.... is this the way to catch up and get the latest > frames? Dropping everything and getting a new one? > backedUpCount = 0; > // keep emptying frames until there aren't any so the next dequeue > will get a fresh one > while(dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT, > &(frames[i])) != 0) { > backedUpCount++; > dc1394_capture_enqueue(camera, (frames[i])); > } > printf("backedUpCount: %ld\n", backedUpCount); > #endif > dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT, > &(frames[i])); > > Which failed with the following error message: > > .... > backedUpCount: 0 > backedUpCount: 0 > libdc1394 error: VIDEO1394_IOC_LISTEN_WAIT/POLL_BUFFER ioctl failed! > Segmentation Fault > > In short, I want to "get only the freshest frame" when I get around to > processing a new. > Thanks in advance for any help! > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: Damien D. <dd...@do...> - 2008-11-16 12:07:50
|
David, Robert, On Thu, 2008-11-13 at 10:42 -0800, David Moore wrote: > Hi Robert, > > The drop_frames option has been removed from version 2 of libdc1394. > The documentation you are reading should probably be updated to reflect > this (Damien?). Thanks, the faq is now fixed. Damien -- Damien 高原 Douxchamps http://damien.douxchamps.net/ |
From: vagvoba <va...@ya...> - 2008-11-13 20:10:17
|
Thank you for the thorough explanation. The problem might be on the PCI bus. Actually that was my first guess too. I have 3 cameras capturing in the same time when the corruption is most likely to happen: 1) 1024*768 color 30fps PG Flea2 on a dedicated IEEE1394B card 2) one more Flea2 at 30fps on another dedicated IEEE1394B card 3) and a third Flea2 on the motherboard's IEEE1394A bus running at 15fps The computer used is a Dell Precision 690 workstation with a quadcore Xeon CPU. Each camera has a dedicated capture thread. The cameras are not accessed from any other threads but their own during capture. I'll try increasing the ring buffer size. Currently it's the lowest possible = 2. I'll let you know if it helped. However, I really need to keep the latency low so I'd prefer another solution. I'll capture some corrupted images too and attach to my next email. Balazs On Nov 13, 2008, at 1:33 PM, David Moore wrote: > On Wed, 2008-11-12 at 14:50 -0500, vagvoba wrote: >> The functions that may be called simultaneously in my code are: >> - capture_dequeue >> - convert_to_RGB8 >> - capture_enqueue >> > > Balazs, > > As long as functions for a single camera are kept within a single > thread, you should be fine with regards to thread safety. It is > okay to > access different cameras from different threads. The only thing you > can't do is access the same camera from different threads. > > That said, it's always possible there's a bug that I'm not aware > of. To > be sure, you could try implementing your code single-threaded to see > if > the situation improves. > > However, it sounds like your problem might be FIFO overruns on your > firewire controller. > > If there's a lot of PCI bus activity, the firewire card's FIFO can > overflow before packets are transferred off the card. Some cards > have a > FIFO as small as 4K, which can cause this problem. Unfortunately, > libdc1394 can't currently detect this type of error in software, > although it might be possible to do it in the future. > > As Holger said, you might also just need to increase the buffer size > of > libdc1394. > > If you send a screenshot of a corrupted image to the list, I can judge > better if this is the cause of your problems. > > You might try switching to a different firewire card. I've also seen > certain motherboards that just don't do a good job mediating the PCI > bus. > > -David > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: David M. <dcm@MIT.EDU> - 2008-11-13 20:56:13
|
On Thu, 2008-11-13 at 15:09 -0500, vagvoba wrote: > I'll try increasing the ring buffer size. Currently it's the lowest > possible = 2. I'll let you know if it helped. However, I really need > to keep the latency low so I'd prefer another solution. > I'll capture some corrupted images too and attach to my next email. > Increasing buffer size will not increase latency. So don't be afraid to crank it up. The buffer helps you "ride out" occasional stalls in your application, but as long as you are keeping up, you get frames immediately as they are available, regardless of the buffer size. Do you get corruption on all three cameras at the same time? -David |