Thanks for responding Damien.
Damien Douxchamps wrote:
>
> Why do you ask for the supported video modes if the video mode that you
> select is hardcoded anyway?
>
This was just left in for experimentation reasons.
>> // setting device name
>> snprintf(device_name, 255, "/dev/video1394/%d", cameras[i]->port);
>> if (dc1394_set_dma_device_filename(cameras[i], device_name)
>> != DC1394_SUCCESS) {
>> fprintf(stderr,"unable to set dma device filename!\n");
>> clean_up_exit_all_cameras(cameras, numCameras);
>> }
>
> You only need to setup the device file if you use exotic
> names. /dev/video1394, /dev/video1394-X and /dev/video1394/X are all
> supported.
>
This actually seems to be where the problem lied. I simply took out
this setting, since as you said it will automatically detect if it is in
/dev/video1394/X and it seems to work fine now. I wasn't able to track
down exactly what was wrong.
>> /*-----------------------------------------------------------------------
>> * setting capture parameters
>> *-------------------------------------------------------------------*/
>>
>> if (dc1394_dma_setup_capture(cameras[i],
>> DEFAULT_VIDEO_MODE,
>> DEFAULT_ISO_SPEED,
>> DEFAULT_FPS,
>> options.ring_buffer_size,
>> DEFAULT_DROP_FRAMES) != DC1394_SUCCESS) {
>> fprintf(stdout, "dma_setup_capture failed\n");
>> clean_up_exit_all_cameras(cameras, numCameras);
>> }
>> <it continues on, but this is where the error occurs>
>
> It probably means that the camera does not support the video
> mode/format/fps combination. Add some printfs after asking for the
> available video modes and also check that the camera supports the FPS
> you specify.
>
It seems fine after I removed the set device_name manually. I don't
think this was the case.
>
> Another (partial) solution would be to try the latest CVS of libdc1394
> but it will require some changes in your code. It will be easier to
> track the failure because the format setup and the capture setup are now
> separated.
We're still having some problems getting 2.0.0-pre6 to work. We're
still getting some weird behavior, but we're currently trying to track
it down.
Thanks again,
James

Hello,
So I was originally using the filltime field in the camera structure to
time how fast we were getting the images, and we kept getting instances
where the the time would actually jump backwards so we tried looking at
the system time as well as the fill time field. So, we ran the code
attached in timetrial.c. Of importance, the particular part of the code
that measures the time when the image is written,
struct timeval t0, t2;
gettimeofday(&t0, NULL);
for (uint_t frameNum = 0; frameNum < options.num_frames; frameNum++){
//fprintf(stderr,"capturing frame %d\n", frameNum);
//fflush(stderr);
/* capture data */
err=dc1394_dma_capture(cameras, numCameras, DC1394_VIDEO1394_WAIT);
DC1394_ERR_CHK(err,"failed to capture\n");
gettimeofday(&t2, NULL);
t2seconds = t2.tv_sec - t0.tv_sec;
t2microseconds = t2.tv_usec;
struct timeval *t1 = dc1394_video_get_filltime(cameras[0]);
t1seconds = t1->tv_sec - t0.tv_sec;
t1microseconds = t1->tv_usec;
fprintf(stdout, "p:%ld.%06ld:%ld.%06ld\n",
t2seconds, t2microseconds,
t1seconds, t1microseconds);
// free buffers for next frame
for (uint_t i = 0; i < numCameras; i++) {
dc1394_dma_done_with_buffer(cameras[i]);
}
}
So for the first 20 frames the time difference between system
time(systime) and filltime are the same, but then afterward the filltime
jumps back in time to the first time instant, and continues at the same
rate (see figure time.jpg). Note that I also used frame buffer size of
20, so it seems that the filltime buffer is looking at the time that the
frame was captured on the last buffer place. (i.e. if frame 1 was
captured at time 0, then then frame 21 captured at time t is stored in
the same memory location at time 0, but the filltime field would still
use time 0). Has anyone used the filltime buffers and had the same problem?
Thanks,
James Sherman
P.S.
The .c file was compiled using the Feb. 06, 2007 libdc version,
g++ -g -O2 -Wall -I/opt/libdc1394-2.0.0-20060207/include/dc1394 -o
timetrial timetrial.c -lm -lstdc++ -L/opt/libdc1394-2.0.0-20060207/lib/
-L/usr/local/lib -lraw1394 -ldc1394
and the output from timetrial was redirected to a file, and these
commands will extract the relevant times
cat tmp.time | grep ^p: | awk -F: '{print $3}' > tmp.filltime
cat tmp.time | grep ^p: | awk -F: '{print $2}' > tmp.systime
Yesterday (though I can't replicate the results today), showed that even
in the first 20 frames, the value in filltime for frame i was actually
the time when frame i+1 was captured. I don't understand how this is
happening, since filltime is only modified in setup_capture function.

Hi,
is it possible to have two applications reading images from the same
camera using libdc1394? I would like to have coriander running
simultaneously with my application. I haven't looked into this problem
but was wondering if someone has tried it yet? If so can they both
control the features of the camera?
Thanks for any help on this topic
Andy

It's me again. I had a small typo in my explanations of the error:
Deniz Bahadir wrote:
> ...
> else {
> if (version!=-1)
> return DC1394_FALSE; <----------
> else
> return DC1394_SUCCESS; <----------
> }
>
> return DC1394_SUCCESS;
> }
>
>
> It seems to me, that you tried to merge three errors in one. ;-)
> The first error is that instead of returning "DC1394_FAILURE" you return
> DC1394_SUCCESS" (where the first arrow points to).
I meant:
The first error is that instead of returning "DC1394_FAILURE" you return
"DC1394_FALSE" (where the first arrow points to).
Other than that, the email should be correct. :-)
So seems the fix.
That's all folks,
DENIZ