[gst-devel] Re: [patch] gstreamer v4l2 source frame rate detection
edgard.lima at indt.org.br
Fri May 5 13:19:20 CEST 2006
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
Edgard Lima - alima
edgard.lima at indt.org.br
ext Martin Rubli wrote:
> 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
> 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.)
> 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.
>> 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
>>>>> 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
More information about the gstreamer-devel