Re: [libdc1394-devel] How to avoid dropped frames (OS X)
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: David M. <dcm@MIT.EDU> - 2007-01-27 05:26:09
|
Dropped frames can happy for a variety of reasons: 1. Your app is getting behind and the ring buffer fills. 2. The bits get corrupted on the bus (since it's isochronous there is no retransmission). 3. Traffic on your PCI bus cause the DMA transfer to get delayed and a packet is dropped when the firewire chipset's FIFO fills (such FIFOs are generally around 4-8kB in size). Your case sounds like probably 1 or 3. It's pretty easy to determine if 1 is happening. Just print the frame's timestamp and the system clock when you dequeue the packet. If they diverge by more than N*t, where N is the size of the ring buffer and t is the nominal time between frames, you are almost certainly dropping frames. Given that changing the ring buffer size had no effect, you probably have situation 3 -- in which case there's really nothing you can do about it, except get a faster computer or a different firewire chipset. If you want to instrument what's happening at a detailed level, look at the function callback() in dc1394/macosx/capture.c. It is called asynchronously whenever a full frame is received: The interrupt fires, and that turns into a notification that wakes up the run loop of that thread, and then callback() is called. You can create a new callback, and call it for _every_ packet instead of just once per frame. You'll have to modify CreateDCLProgram() so that a callback is added to every DCL with SetDCLCallback, instead of just the last DCL per frame. I would advise against dequeue() and enqueue() in separate threads. It might work, but it would depend on certain Mac OS X firewire functions being thread-safe, and I'm not certain they are. Besides, the run loop for handling new frames is already a separate thread anyway in libdc1394 for Mac OS X. -David On Wed, 2007-01-24 at 18:58 +0100, Mark Munte wrote: > Hello, > under certain circumstances my app loses some frames - e.g. when the =20 > user activates Expos=C3=A9'. > I don't really understand what is the cause of the dropped frames. >=20 > I am using DMA capture under OS X. I tried several ring buffer sizes =20 > (from 2 to 40) but that does not solve the problem. >=20 > Is it correct that using DMA capture means the DMA function gets =20 > called at interrupt time? > If that is so, the only reason I could get dropped frames, is the =20 > ring buffer is full. Or might there be something else going wrong? >=20 > I am thinking if it would be a good idea to separate capturing and =20 > processing of the captured data into two separate threads. > Can I call dc1394_capture_dequeue from one thread and =20 > dc1394_capture_enqueue from another. >=20 > Would that make sense - I would appreciate some thought's on that. >=20 > Regards > Mark >=20 >=20 > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |