[gst-devel] Re: [patch] gstreamer v4l2 source frame rate detection
martin at rubli.info
Fri May 5 10:43:00 CEST 2006
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.)
On Fri, 05 May 2006 08:14:28 -0700, Edgard Lima <edgard.lima at indt.org.br>
> 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 the
>>>> application requesting it (which is what I meant with "dynamically").
>>>> 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
>>>> 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