On Thu, 2008-01-31 at 08:20 +0100, Hans Verkuil wrote: > On Thursday 31 January 2008 02:05:46 Daniel Kristjansson wrote: > > Hey, I've recently learned that it is impossible to switch inputs > > when using the latest ivtv drivers unless you close all the open file > > descriptors for a video device first. Working around this in MythTV > > would be a nightmare since the class that does channel changing and > > input switching for all V4L and V4L2 devices is deliberately kept > > isolated from the class that handles recording with the ivtv drivers; > > they use separate file descriptors and operate in different threads. > > That brings me here since it looks like it might be much easier for > > me to fix this in the ivtv driver than working around the problem in > > MythTV, and fixing this upstream would have the bonus of allowing > > other applications to continue to use the ivtv drivers. > > > > Anyway, can anyone give me pointers on where to start? I'm assuming > > that on the input switching ioctl I will need to close up and restart > > streaming on all open file descriptors, but what else needs to be > > done? > > Hi Daniel, > > The easiest way to solve it is to check whether S_INPUT returns EBUSY > and in that case pause the encoder (VIDIOC_ENCODER_CMD), call S_INPUT > again and restart it with ENCODER_CMD.
Hmm, that may allow for a more elegant hack in MythTV than a close/open requirement. I'm installing 2.6.24 now so I can test the hack I've attached here: http://svn.mythtv.org/trac/ticket/4466 We already have a similar hack for the ConvertX drivers which require streaming to be stopped during input switches... The hack checks if we're using the "ivtv" drivers and if so does a VIDIOC_ENCODER_CMD PAUSE and RESUME around the input switching code. > > I'm assuming that if were really that simple it would have been > > fixed already, so what were the underlying issues? > > Changing inputs means changing the video digitizer settings. > Unfortunately, doing that on the fly can confuse the MPEG encoder > hardware and you get flickering of the screen every so often: I suspect > that the encoder has problems resyncing to the new video stream. This > is not a problem when changing channels since in that case the > digitizer doesn't need to be reprogrammed. I spent quite some time on > this trying to solve it without requiring applications to stop the > encoder first, but I've not been able to find a solution for it. > > On the one hand this could be solved in a similar way (pause, change > input, resume) inside the driver, but I rather disliked introducing > such an unexpected side-effect and since the v4l spec clearly allowed > returning EBUSY I decided to do that. The biggest advantage of solving this in the driver is that it allows for backward compatibility. Even if pause/change input/resume becomes the preferred method, it will take a long time before all applications are both patched and _distributed_ with this fix. In the meantime ivtv will be perceived as broken by the end users. Also when EBUSY is returned the application needs to know which driver is being used because each driver that does this on input switching requires a different workaround, so this ends up putting a lot of hardware specific driver code into each application which is quite inelegant. Plus, design wise, this is at odds with the V4L2 philosophy which says that it should be possible to have one application handling streaming and another handling channel changing, settings changes and and input switching. The V4L2 API allows this, but I think that was only done to make the initial porting of brain-dead V4L1 drivers to V4L2 a little simpler. The ivtv driver is pretty much the opposite of a brain-dead V4L driver. -- Daniel _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
