From: Hans Verkuil <[EMAIL PROTECTED]> > On Thursday 29 November 2007 20:16:51 TheHog wrote: > > From: Hans Verkuil <[EMAIL PROTECTED]> > > > > > On Wednesday 28 November 2007 13:09:45 TheHog wrote: > > > > From: Hans Verkuil <[EMAIL PROTECTED]> > > > > Date: 21-Nov-2007 09:28 > > > > > > > > > On Wednesday 21 November 2007 02:57:32 TheHog wrote: > > > > > > With ivtv 0.10.6, I get the error "IOError: [Errno 16] Device > > > > > > or resource busy" when setting the input (v4l2-ctl -i, > > > > > > ioctl). With ivtv 0.10.5 it did work. That is, with 0.10.6 it > > > > > > is not possible to change the input from tuner to e.g. > > > > > > composite or svideo while the device is open. Is this a know > > > > > > issue? Is it solved in a later version? Note that 0.10.6 is > > > > > > the current default in Gentoo. > > > > > > > > > > No, this is a feature: changing inputs like that could cause a > > > > > corrupt MPEG stream so I changed the driver to prevent people > > > > > from switching to another input when a capture is in progress. > > > > > > > > What exaclty causes the bad packets in the MPEG stream? Is it the > > > > PVR firmware or ivtv? > > > > > > It's really the hardware: changing the input will mean changing the > > > settings of the digitizer chip (saa7115 or cx2584x). This means > > > that the cx23416 can receive a bad frame from the digitizer which > > > means that the MPEG stream also gets corrupted. > > > > > > > I found some code in xine's input_pvr plugin that > > > > copes with corrupted streams: it does an close/open on the device > > > > to obtain a valid stream again. That's probably why Freevo users > > > > didn't encounter the issue. > > > > > > > > Do you plan to re-enable the functionality to switch inputs while > > > > a capture is in progress in the future? > > > > > > I have no plans, unless someone can figure out how to safely change > > > inputs. There might be some magic incantation, but experience has > > > shown that it is quite tricky to get it working under all > > > circumstances. > > > > OK, I understand. I presume it is not possible to detect that > > situation in the ivtv driver and discard the frame since it has > > already been encoded into the stream? Instead, is it possible to put > > the digitizer chip "on hold" (maybe causing the cx23416 to insert > > black frames into the stream)? That way, clients of ivtv can issue a > > "hold - change input - continue" sequence without closing and > > re-opening the video device? > > It might be possible to use some workaround like that to make it work. > The problem is with the cx23416 part where the documentation on what to > do in a situation like this is for all practical purposes non-existant. > So the only way to fix this is to simply experiment a lot. I'm not > going to do that myself (too many other tasks), but I'm perfectly > willing to give pointers if you want to take this on. >
OK, I'll give a try after my current work with xine has been done. Cheers, Richard. _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
