Re: [libdc1394-devel] Re: filltime and drop_frames
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Damien D. <d.d...@te...> - 2003-11-24 16:12:03
|
Hi Dan, Johann, On Mon, 2003-11-24 at 15:12, Dan Dennedy wrote: > On Mon, 2003-11-24 at 05:16, Damien Douxchamps wrote: > > Hi Johann, > >=20 > > On Sun, 2003-11-23 at 22:44, Johann Schoonees wrote: > > > >> 4. Add a new flag member to the dc1394_cameracapture stucture cal= led=20 > > > >>something like dma_extra_buffer_enable which switches copying to=20 > > > >>dma_extra_buffer on or off. (We will have to decide what to do if=20 > > > >>both drop_frames and dma_extra_buffer_enable flags are set.) >=20 > This parameter is not necessary because this behavior is directly > related to the drop_frames behavior. The latter condition of both > enabling drop_frames and a new dma_extra_buffer flag is a complete > contradiction. That was my understanding until Johann came ;) > > > > I don't understand what will have to be decided. Please give me mor= e > > > > details. > > >=20 > > > dma_extra_buffer_enable!=3D0 means don't drop frames if possible but=20 > > > buffer those by which we are behind. > > > > > > drop_frames!=3D0 means drop all frames by which we are behind. > > >=20 > > > It is possible that the user can set both flags. Then do we drop=20 > > > frames or not? We will have to decide which flag has precedence if=20 > > > both are set simultaneously. My inclination is to play it safe and d= o=20 > > > the buffering, i.e. dma_extra_buffer_enable has precedence. > > >=20 > > > This is only a preliminary idea for the dma_extra_buffer_enable flag.= =20 > > > If anyone can think of a different flag that avoids the conflict=20 > > > (and breaks a minimum of existing code), please speak up. > >=20 > > I realize I've never quite understood the purpose of the extra_buffer! > > ;-) A quick reading of dc1394_capture didn't help but I still have two > > comments: >=20 > The purpose is to minimize the chance of dropping a frame if it is > important to try to capture every frame. >=20 > > - is it really interesting to have a multi_capture function? Wouldn't a > > single capture function be enough?=20 >=20 > Actually, it is more the other way around. Single capture is simply > multi capture called one iteration. >=20 > > The comments in dc1394_capture (line > > 325) seem to indicate that the extra_buffer is only for multi capture, > > so removing this feature might remove the problem. I personally think > > that it's very easy to use a "for (each camera on the bus) do capture > > end" so I don't really see the point of this multi capture at all. Then > > again, I did not understand all the code ;) >=20 > Multi capture takes care of switching between multiple cameras across > multiple 1394 buses; something that is not trivial. If multiple capture is not simply a loop on a single capture procedure, we should definitely keep it. > > - if the parameter is meaningful, then I would suggest to use some enum > > type to limit the possibilities to the 3 meaningful ones: no drop/no > > extra buffer, drop/no extra buffer and no drop/extra buffer. It could > > still be a bit mask but it would be on 2 bits. >=20 > I do not agree with this change. > "drop/no extra buffer" and "no drop/extra buffer" is the current > behaviour. > "no drop/no extra buffer" does not make any sense because what is one > supposed to do with the extra frames you receive? After all, you > requested no dropping of frames. The only reason it might make sense is > to completely change the capture model within libdc1394. This is my point of view too. > > > >> 6. Allocate memory for dma_extra_buffer in=20 > > > >>dc1394_dma_multi_capture() if=20 > > > >>dma_extra_buffer_enable&&dma_extra_buffer=3D=3DNULL. That enables = the=20 > > > >>user to request extra buffers by modifying dc1394_cameracapture on = the=20 > > > >>fly. (Currently this could cause a segfault.) > > > >=20 > > > >=20 > > > > So in short this would let the user re-allocated the ring buffer on= the > > > > fly(to change its size)? Would this done by re-calling > > > > dc1394_dma_setup_capture? > > >=20 > > > No, I don't think that would work. What I meant was that a user may=20 > > > change their mind after initially setting up with=20 > > > dma_extra_buffer_enable=3D0 (so that no memory gets allocated to=20 > > > dma_extra_buffer which is set to a null pointer). If=20 > > > dma_extra_buffer_enable is set some time after initialization/setup=20 > > > then dc1394_dma_multi_capture() needs to detect this and quickly=20 > > > allocate some memory to dma_extra_buffer (preferably by calling the=20 > > > new proposed fundtion _dc1394_alloc_extra_buffer()) before=20 > > > memcpy(dma_extra_buffer,...) tries to access the null pointer. >=20 > If someone wants to change their capture settings after capture is > started, they must stop capture, make the change, and re-start. Changing > this on the fly is stupid and will make it needlessly complex. I'm wondering which code sequence would create such segfault. This kind of error never happened to me. > IMO, the only legitimate problems are to avoid segfault and those > related to filltime. To be honest, filltime was something first added to > video1394 outside the libdc1394 project. Problems with filltime are also > in video1394 because it has no way to set the filltime for each buffer > of multiple frames returned. >=20 > I am wondering if I can update libdc1394 to use the new raw1394_iso API. > There is a param on the iso_receive callback that provide some cycle > time information, but I have to analyse further if it is enough.=20 Is it correct that this upgrade to the new ISO API would make video1394 obsolete and that the capture would perform better? In that case this is the one big step forward we should make in libdc1394 capture. > > Before saying any more stupid things I guess I'll have a deeper look at > > the code to understand what this extra buffer really is... ;-) >=20 > It is really quite simple. If you choose to not drop frames, then what > should be done with those potentially extra frames? Why, buffer them, of > course. I was confused with by difference between dma_ring_buffer and dma_extra_buffer. I feel better now ;-) Damien --=20 _ Damien Douxchamps (=B0- PhD Student / Research Assistant //\ Image Processing Group, Telecom Laboratory, UCL, Belgium V_/_ http://www.tele.ucl.ac.be/MEMBERS/Douxchamps_Damien_e.html |