Re: Using V4L as sub process (thread/fork, ANYTHING!!!!)

[David J. Topper]

Thanks for the helpful replies, but I'm still at a loss. Here's some more detailed info. I'm sure it's possible to make this work, but am currently at a loss. In any case, I'll outline the two main methods I'm trying.

0. Background
--------------

I've got a GTK application which uses a canvas to draw various objects. It works quite well. I'm trying to add a new object that does video processing. So basically, I create a button called "start_capture", which when clicked will start rendering video to a GDK drawing area.

1. Pthread case
----------------

I've got a callback connected to the start_capture button which creates the "read_video" thread. Here's my "read_video" code:

void *read_video() {
int i, retval;
struct timeval tv;
long newframetime;

while(1) {
printf("reading video\n");
i = -1;
while(i<0) {

i= ioctl(cam,VIDIOCSYNC, &frame);
if(i < 0 && errno == EINTR) continue;
if (i < 0) {
perror ("VIDIOCSYNC");
exit(-1);
}
break;
}

q++;

buf = bigbuf + vidbuf.offsets[frame];
mapbuf.frame = frame;

if (ioctl(cam,VIDIOCMCAPTURE, &mapbuf)<0) {
perror("VIDIOCMCAPTURE");
exit(-1);
}

draw_video_to_darea();

frame++;

}
}

The problem is that since this function never returns, I never get control back to my application. The start_capture button remains pressed and my "draw_video_to_darea()" function simply renders video to the external window / drawing area. I'm at a loss as to how I can set this up NOT to require a while(1) loop.

If I don't join the thread, I get an Xlib error:

Xlib: unexpected async reply (sequence 0xb4b)!

of course the "sequence" changes. Yes, I am using the gtk_thread_init() call and the rest. There is no sharing of data in my app (yet) so it's not a mutex issue.

2. gdk_input_add case
----------------------

If I set the following:

fd = open("/dev/video",O_RDONLY);

gdk_input_add(fd,
GDK_INPUT_READ,
GTK_SIGNAL_FUNC(read_video),
NULL);

NOTHING HAPPENS!!!! I need to open /dev/vbi instead. Of course in this case, my read_video() function doesn't have the while(1) loop. But the problem with opening /dev/vbi is that it seems to get VERY FREQUENT updates. So the gdk scheduler is calling read_video at an incredible rate. Looks great for video refresh, but bogs down my application.

I've tested out this method w/o rendering the video to a window ... same problem. So it has something to do with the actual reading / polling of the video device.

----------------------

I'm looking at the glib functions g_source_add() and whatnot, but they seem much more involved. Anyone have some decent examples?

Thanks all,

DT
--
Technical Director, Virginia Center for Computer Music



--
video4linux-list mailing list
Unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/video4linux-list