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

[Edgard Lima]

Ok, Martin and Fredrik, thanks

Ive just commited to v4l2src.

It has some improvements proposed by wingo in bug #338818 and the patch 
Martin sent me to fix framerate detection.

Could you please try it?

Could you please try tests/icles/v4l2src-test with your webcam

BR,
Edgard Lima - alima
edgard.lima at indt.org.br



ext Martin Rubli wrote:

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