Ah, thanks for setting me straight on the requirement for the
*application* to control when frames are buffered vs. dropped. That does
On Tue, 2003-11-25 at 06:20, Johann Schoonees wrote:
> Hi Dan, Damien
> I'll reply to both your emails together.
> Dan Dennedy wrote:
> > On Mon, 2003-11-24 at 05:16, Damien Douxchamps wrote:
> >>Hi Johann,
> >>On Sun, 2003-11-23 at 22:44, Johann Schoonees wrote:
> >>>>> 4. Add a new flag member to the dc1394_cameracapture stucture called
> >>>>>something like dma_extra_buffer_enable which switches copying to
> >>>>>dma_extra_buffer on or off. (We will have to decide what to do if
> >>>>>both drop_frames and dma_extra_buffer_enable flags are set.)
> > 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.
> I have found it necessary in my application to be able to do neither.
> In other words, I do not want to drop frames and I do not want to
> buffer them either. Mostly, I just want to know by how many frames I
> am behind in the DMA ring buffer and be able to flush them if I can't
> catch up.
> I get the impression that most of the libdc1394 development is done
> with desktop PCs in mind, perhaps to support webcams or the like. In
> more stringent environments (embedded processors doing image
> processing and other jobs in real time) one cannot always afford to
> have the dc1394_dma_multi_capture() function do an unexpected memcpy()
> to an extra buffer if the timing is tight.
> I think my application is fairly representative of such situations: I
> do not want to lose any frames if possible, but I also cannot afford
> the overhead of extra buffering. My interface to the rest of the
> system is specified to say: if I can't keep up with my processing
> load, then I may drop a frame as long as I tell the system which one I
> dropped (for example by a frame number or a gap in a series of frame
> As it is currently implemented, buffering is done in a bursty way. In
> systems which have to synchronize processing with regular external
> events it leads to situations where, once a frame gets copied to
> extra_buffer, it triggers a cascade of more extra_buffer copying and
> may not catch up again. The reason for such behaviour is that while
> dc1394_dma_multi_cpature() returns frames from dma_extra_buffer (i.e.
> while dma_extra_count>0), frames heap up in the DMA ring buffer.
> So, for me (and presumably others who do real-time processing) it is
> not just a simple drop_frames/extra_buffer decision. I need more
> information about how full the DMA buffer is and finer control over
> when to flush frames from the ring buffer.
> >>- 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.
> > 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.
> I understand the original intention of drop_frames. But as I
> explained above, a "no drop/no extra buffer" would make a lot of sense
> in my application. Especially if it is accompanied by feedback on the
> number of frames by which we are behind in the DMA ring buffer.
> I do not think adding this new functionality will change the capture
> model within libdc1394 much. The only change would be for existing
> code to add a line like dma_extra_buffer_enable=1 to the existing
> I agree that the meaning of drop_frames changes slightly. It used to
> mean (and may continue like that if we decide not to make the proposed
> changes) "IF drop_frames, flush frames from the DMA ring buffer if we
> fall behind, ELSE buffer them in user space." With the proposed
> change its meaning would become "IF drop_frames, flush frames from the
> DMA ring buffer if we fall behind, ELSE leave them alone."
> All dma_extra_buffer_enable does is to allow the separation of the
> quite different concepts of flushing and buffering. Which makes me
> think, if we do go ahead with such a change, would it be better to
> rename drop_frames to flush_frames?
> >>>>> 6. Allocate memory for dma_extra_buffer in
> >>>>>dc1394_dma_multi_capture() if
> >>>>>dma_extra_buffer_enable&&dma_extra_buffer==NULL. That enables the
> >>>>>user to request extra buffers by modifying dc1394_cameracapture on the
> >>>>>fly. (Currently this could cause a segfault.)
> >>>>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
> >>>No, I don't think that would work. What I meant was that a user may
> >>>change their mind after initially setting up with
> >>>dma_extra_buffer_enable=0 (so that no memory gets allocated to
> >>>dma_extra_buffer which is set to a null pointer). If
> >>>dma_extra_buffer_enable is set some time after initialization/setup
> >>>then dc1394_dma_multi_capture() needs to detect this and quickly
> >>>allocate some memory to dma_extra_buffer (preferably by calling the
> >>>new proposed fundtion _dc1394_alloc_extra_buffer()) before
> >>>memcpy(dma_extra_buffer,...) tries to access the null pointer.
> > 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 don't mind either way. This is not a high priority for me.
> My original thinking was that the user (as opposed to the developer)
> sees a certain view of the libdc1394 interface and, hey! here is a
> flag called frop_frames (or dma_extra_buffer_enable or whatever) what
> happens if I change it? The user should not have to worry about
> details like memory allocation and whether they need to restart when
> some flags are changed but not others. All the typical user cares
> about is high-level functionality like "can I do buffering and where
> do I switch it on and off." The low-level code can take care of the rest.
> PS: I have written a little wrapper around libdc1394 (actually it is
> not so little: 2800 lines) which defines an implementation-independent
> interface to a generic camera. The user need not know that the bus is
> IEEE 1394. Exactly the same interface can be used for USB cameras,
> CameraLink, etc. by writing the appropriate code behind the interface.
> It has high-level general functions like cam_create(),
> cam_destroy(), cam_get/set_frame_dims(), cam_get/set_framerate(),
> cam_get/set_trigger_source(), cam_get/set_single_shot(),
> cam_get/set_run_stop(), cam_point_to_next_frame(), cam_unpoint_frame()
> and so on. Anything (even frame dimensions and frame rates) can be
> changed at any time, even while the camera is running. No need for
> the user to know anything about the constraints of IEEE 1394 or
> libdc1394. Also an example program which uses the interface. Some
> day I'll tidy it up and put it somewhere accessible. J.