[gst-devel] Re: [patch] gstreamer v4l2 source frame rate detection

[Martin Rubli]

Hi,

What's important to remember when considering multiple opens is that for  
many devices it doesn't make any sense. Take the case of TV cards, for  
example: Even if the driver were to allow two applications to open the  
same device at the same time, they would fail to work because every card  
would try to get hold of the tuner to change the frequency, etc. This is  
something that the driver cannot reasonably translate to hardware controls.

For webcams, it seems easier to find a way to make sens of multiple opens.  
You could be having a video conference while a program is running in the  
background that takes a snapshot once a minute and uploads it to a  
website. (Why anyone would do that is beyond me, but that's a different  
story. ;-) So far so good.

The problems start when you look at how current applications are  
implemented. They usually set parameters like compression format, capture  
size, frame rate to suit their needs (and capabilities as far as decoding  
of e.g. MJPEG is concerned). And if they fail to do so, they usually  
refuse to capture anything at all.

So even if you had a driver that supports multiple opening of the video  
stream (I don't know of any), applications would have to be quite flexible  
in the sense that only the first application would be able to set the  
parameters and those that come later would have to settle for whichever  
format is currently active.

When they talk about panel applications in the standard, this could be  
understood as a separation of concerns. Say you run Ekiga to stream video  
 from your TV card, you'd still want to be able to change the channels with  
a separate application. So Ekiga gets the video stream but the panel  
application still gets to control certain parameters.

To sum up and to answer Edgard's previous question: With the current  
driver and application situation I think it's fair to assume that only one  
application has access to the video stream at a given time. And even in  
the case that I described above, the frame rate (and other parameters)  
would not change from one frame to the next.

(I'm no expert in the topic of remote controls but from what I've seen,  
those use the I2C interface, which runs in parallel to and unaware of V4L.)

Cheers,
Martin


On Fri, 05 May 2006 08:14:28 -0700, Edgard Lima <edgard.lima at indt.org.br>  
wrote:

>
> Hi Fredrik,
>
> Could you please explain better  
> http://v4l2spec.bytesex.org/spec-single/v4l2.html#AEN185 how it works.
>
> Thanks,
> Edgard Lima - alima
> edgard.lima at indt.org.br
>
>
> ext Fredrik Persson wrote:
>
>>>> Ok, granted, but that is not something the device would do without the
>>>> application requesting it (which is what I meant with "dynamically").  
>>>> And
>>>> it's easy to fix, too. Just call get_fps to update the v4l2src->fps_x
>>>> variables when the video mode is changed in set_norm. Do you want to  
>>>> write
>>>> this? Like I mentioned, I couldn't test it with a TV card anyway.
>>>>
>>>>
>>> Couldn't a v4l2 devide be opened by two apps at same time? If so, is  
>>> the second app alowed to change the input, or is it read-only?
>>>
>>
>> (Not knowing exactly what is beeing discussed in this thread, I can  
>> answer this single question.)
>>
>> No, a v4l2 device (typically /dev/video0) can only be opened once. If a  
>> second app wants to use /dev/video0, the first app will have to close()  
>> it first.
>>
>> /Fredrik Persson
>>
>>