Hi Andy, I'll reply from work here, sorry for the top-post.
In the driver sources, zoran_driver.c, zoran_v4l_queue_frame(), you'll see that the -EBUSY is because we don't set the buffer state from BUZ_STATE_PEND. This should be done in v4l_sync() in the same file, but isn't done because of the timeout (line 929-930). Adding a line in between there to set the buffer state to BUZ_STATE_DONE should be ok. (I'm not sure whether v4l is clear on this, however, i.e. whether we should unqueue queued frames on error return or not; it probably depends on the error... Something like "on timeout, unqueue, but on interrupt, remain queued. If anyone knows, please join in the discussion.) Cheers, Ronald -----Original Message----- From: Andy Brown [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 9:40 AM To: Ronald S. Bultje; mjpeg-users@lists.sourceforge.net Subject: Re: Mjpeg-users Digest, Vol 8, Issue 2 Ronald S. Bultje wrote: > Hi, > > On Wed, 2007-01-02, Andy Brown wrote: >> So from what you explain, I cannot stop this from causing the device to >> stop delivering the data and require the device to be closed then re-opened? > > You don't need to close it, you just need to re-queue the frame for > capture. I.e., your _application_ is responsible for handling te capture > error. The driver doesn't crash or anything, it simply returns an error > on he sync call, because the next frame could not be delivered (it got > lost), probably along with a whole bunch of more frames if the > interference is really bad. Simply discard them and continue queueing > frames for capture and you should be fine. > > (Note, however, that this is the theory; in practice, we never actually > test that. If you want, we can add a --ignore-frame-errors or so to > lavrec and see if it really actually works, and fix possible driver > errors, but that will require some small testing + patching from your > side.) Ah, right. Sorry I'm not any good at image programming, so bear with me on this one! That makes a lot of sense though Ronald. What I'm getting is the first frame dropped with an: "sync error in proc 11048: Timer expired" and then the second attempt: "mcapture error in proc 11048: Device or resource busy" error, which are both generated from this piece of code: vid_mmap.frame = viddev->v4l_curbuffer; if (ioctl(dev, VIDIOCMCAPTURE, &vid_mmap) == -1) { motion_log(LOG_ERR, 1, "mcapture error in proc %d", getpid()); sigprocmask (SIG_UNBLOCK, &old, NULL); return V4L_FATAL_ERROR; } vid_mmap.frame=frame; if (ioctl(dev, VIDIOCSYNC, &vid_mmap.frame) == -1) { motion_log(LOG_ERR, 1, "sync error in proc %d", getpid()); sigprocmask (SIG_UNBLOCK, &old, NULL); } (I understand this is difficult to understand only seeing a small portion of the code). What I'm understanding from you, is that I should be able to change this so it isn't a fatal error, and continue trying to retrieve frames, simply skipping the 'bad' ones? I'll give that a try, as I'd love to get this working! Thanks for your assistance. Regards, -- Andy w: http://www.thebmwz3.co.uk ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
