Sorry for me beeing so blind, of course libdc copys the buffers separately
but when you say, video1394 will only use Buffers, that are qeued, this=20
means, when you don't capture them, sio-receiption will stop when the ring =
buffer is full, this doesn't make any sense to me, it should be a ring=20
buffer doesn't it?
This makes sense with Saschas analysis, he just gets the old frame, and=20
when the reception only continues, when he returns the buffer to the=20
kernel again. Thus -> large number of dam=5Fbuffers, or polling for frames =
more often e.g. in an extra thread as Dan mentioned already.
And what status does the extra buffers have, when the first is marked free =
by the LISTEN=5FWAIT/POLL=5FBUFFER ioctl, all other received frames have be=
marked ready by the wakeup=5Fdma=5Fir=5Fctx upon dma completion,=20
none of them is marked queued again, because the LISTEN=5FQUEUE=5FBUFFER io=
is =5Fnot=5F called for any of them, is there another status i am not aware=
Please don't get pested by my questions, I take this opportunity to try to =
understand this video1394/libdc1394 buffering scheme more completely.
Mit freundlichen Gr=FC=DFen,
Dipl.-Ing. Tim Evers
Dan Dennedy <dan@...>
Sent by: libdc1394-devel-admin@...
cc: Sascha Lange <salange@...>, libdc1394-devel=20
Subject: Re: [libdc1394-devel] Re: video1394 / libdc1394: dm=
a capture one frame=20
On Tue, 2004-05-18 at 07:19, T.Evers@... wrote:
> 2. This depends on how may buffers you gave the kernel-ringbuffer, if=20
> setup more than 60 frames for rinbuffer, and set drop=5Fframes to 0, then=
> the next image will be 2 seconds old purposely.
It does not depend upon the number of dma buffers; it depends upon the
order and timing of the calls to capture and done=5Fwith=5Fbuffer, and, of
course, the drop=5Fframes parameter value.=20
> if you just setup 4 ringbuffer frames and set drop frames to 0 , i just=20
> see, that this whould lead to a segfault, as the libdc routine trys to=20
> memcpy away all extra frames in on coninous segment, not regarding=20
No, it does not copy in one contiguous segment; it copies each frame
separately unless it has been changed since I worked on it.=20
> if num=5Fdma=5Fframes=3D~4 and drop=5Fframes=3D1 the image shold be the m=
> but as i see it in the video1394 code:
> When you call the capture ioctl, you specify in the struct, which=20
> dma-buffer you ask to be ready, maybe this one is not updated on=20
> ringbuffer overflow.
> As i understatand the video1394 code, ther is a Problem:
> when you start iso and wat for some time, let's say 10 frames arrive in=20
> the mean time, then you call singla=5Fcapture, the ioctl is called with=20
> buffer 0, as it is the first call. buffer 0 ifs READY, now all following =
> ready-frames are summed up, and and the ioctl returns, thus buff0 is=20
> tagged FREE, buff 1to 9 are tagged READY, and buffer=3D) , then libdc193 =
> enqeues the buffers 0 to 8, because of drop=5Fframes=3D1, your applicatio=
> gets frame No.9 which is the latest. but this one is not marked FREE,=20
> will be overwritten by the kernel on the next ring-buffer-roudtrip .=20
It is true that the last frame buffer status is not FREE, but it is also
not READY. video1394 only writes to buffers that are QUEUED.
Furthermore, it only processes buffers sequentially (or circularly if
you will), so it will stop writing to buffers at the first one not
> If i am wrong, you get Frame No 0 in your app, which is marked FREE, all =
> others are re-enqeued, but this means you get the oldest frame!
Well, you are not completely wrong, but as long as you minimise the
number of dma buffers, use drop=5Fframe=3D1, and call capture and
done=5Fwith=5Fbuffer with as little latency as possible, then you are
getting the latest frame possible (while making no attempt to capture
every frame possible).
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
Mailing list for libdc1394-devel