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.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
