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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux