Re: [libdc1394-devel] [SPAM RBL] Re: VIDEO1394_IOC_LISTEN_CHANNEL ioctl failed! and Bad images

[Damien D. <ddo...@is...>]

Hello Martin,

On Fri, 2007-01-05 at 17:30 +0100, Martin Peris wrote:
> Hello Damien,
>=20
> Thank you for taking time to answer my e-mail, you all are doing a grea=
t
> job with this library.
>=20
> I think I have some answers...=20
>=20
> I've been investigating a bit, and the  problem with the limit in the
> size of the allocated DMA buffer  is not so obscure.
>=20
> vmalloc_32() allocate virtually contiguous memory (32bit addressable),
> the default maximum amount of memory reserved for this depends on each
> kernel compilation, and in my case it was set to 128Mbytes that's why I
> had an error if tried to allocate too many buffers.
>=20
>  but at boot time you can specify how much virtually contiguous memory
> you want with the parameter vmalloc, so if you want about 512Mbytes of
> memory for vmalloc you should add the parameter vmalloc=3D536870912 to =
the
> line that defines the kernel parameters. (If you use grub there should
> be a line like this on /boot/grub/menu.lst)
>=20
> kernel          /boot/vmlinuz-2.6.15-27-686 root=3D/dev/sda2
> vmalloc=3D536870912 ro quiet splash
>=20
>=20
> That killed my problem with:=20
>=20
> dc1394_capture.c) VIDEO1394_IOC_LISTEN_CHANNEL ioctl failed!
> Libdc1394 error (dc1394_capture.c:dc1394_capture_setup_dma:382): Captur=
e
> is not set : Could not setup DMA capture

This is great! I don't remember seeing a solution to this problem
before. I'll add your comment to the FAQ.

> But there is still the other issue, and that one is really obscure for
> me :P, the wrong images...=20
>=20
> I investigated a bit on this too. I decided to shot the cameras with an
> external trigger and found something very interesting...
>=20
> I got a while(1)  on wich I call dc1394_capture_dma with the wait flag,
> so the program hangs waiting for the frame, I shot the trigger
> externally, and then dc1394_capture_dma returns succesfully, the image
> is OK. Let's go for another shot, the thing goes right, but after 2 or =
3
> shots dc1394_capture_dma hangs waiting for the frame, I shot the
> trigger, but dc1394_capture_dma does not return.... so... I shot anothe=
r
> trigger and then returns and the image is wrong.
>=20
> My interpretation is that at some point we loose some packages sent fro=
m
> the camera, so the frame isn't complete (and the call to
> dc1394_capture_dma does not return), and the next time that the camera
> receives a trigger and sends the image , the last frame that wasn't
> complete gets completed with the packets of the new frame (so the call
> to dc1394_capture_dma returns).

This is a very reasonable interpretation ;) You can be sure about this
by checking the image shift that occurs on the bad picture. The shift
should a multiple of the number of bytes per packet.

> I need to surf a bit more inside the code of libdc1394 and libraw1394
> but something tells me that it is what is happening.
>=20
> Am I right? Is there any solution? We know the frame rate... could we
> set a time out to discard a frame if it isn't complete on one frame rat=
e
> time or something like that?  Or some kind of data flow control? I don'=
t
> know what could be done, you are the experts ;)

I don't think we can determine the framerate exactly. For instance, the
external trigger can result in a 'completely random framerate'.

The solution is usually to check the physical data path, namely the
cables and connections. The cables should be of the recommended length
(4.5m max) and it is a good idea to buy them from a reputable
manufacturer. I bought some in Taiwan that were totally unreliable;
changing the cable fixed the problem instantly.

To further diagnose the problem, try to set your camera to 100Mbps
instead of 400. If this solves the problem then the problem is very
likely in the cable/connectors.

Now, if someone has an idea about how we can re-sync the image flow once
a packet is dropped it would be very welcome. I think that the first
packet of every frame as a control bit set to 1. Maybe we could use
that?

Damien

--=20
  _    Damien =E9=AB=98=E5=8E=9F Douxchamps, PhD
 ('-   Post-doctoral investigator
 //\   Image Processing Group, NAIST
 V_/_  http://damien.douxchamps.net/