[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [ivtv-devel] Fixing input switching with ivtv driver Duncan Webb Thu Jun 12 12:03:23 2008

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.
>> 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.

Hans, why don't you put the stop/start of the encoder in the driver, 
when changing standard or input? Is it really the best place for this 
functionality and it really the responsibility of the application to 
know the quirks of the driver?

It's a bit like putting the same code in a set of functions all calling 
one function. Wouldn't we, as programmers, move common code into a 
single function.


ivtv-devel mailing list