Re: [libdc1394-devel] Re: filltime and drop_frames

[Damien D. <d.d...@te...>]

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=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
> > I don't understand what will have to be decided. Please give me more
> > 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 do=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.

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:

- is it really interesting to have a multi_capture function? Wouldn't a
single capture function be enough? 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 ;)

- 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.

> >>  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.

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... ;-)

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