Billy Biggs wrote:
Petr Vandrovec (VANDROVE@xxxxxxxxxx):
Sometime in the past, Gerd wrote:
Another (and IMHO better) approach is to allow multiple
applications queue up capture requests. If a second application
asks for a video frame while the driver is busy capturing the
frame for the first application, it can simply put the request
into a queue instead of returning -EBUSY. This might need some
more changes through (depending on the current driver design).
I think that it is very bad idea. You should either support delivering
one buffer to more than one app (like current vloopback does), or you
should return BUSY. Otherwise if you start second grabber application
(by mistake or whatever) while one is already running, you'll start
seeing missed frames for no apparent reason.
But of course if you have some ideas how to handle such case without
disturbing existing grabbing/output processes...
I agree. Dropping frames is very bad. Wouldn't multi-application
grabbing be handled best by some userspace library? Similarily for
loopbacking etc? There's too much desired functionality (colourspace
conversion, jpeg decoding, compression API, multi-apps, etc) that seems
to demand a standard userspace component. The V4L2 API might be too
complex if you start to add too much.
I am new to the V4L2 world, but I have the strong feeling that a v4l2 userspace
library is a very sensible approach.
The V4L2 interface seems to go in a direction where every stream format is
passed more or less unchanged to userspace. This leads to a situation where
application developers have to understand ( and implement ) every single format
in order support a wide range of video devices.
IMHO, Billy's idea would provide a good solution for this: A userspace library
which handles various format transformations, if necessary, and which presents
_one a few_ possible output formats to the user. The V4L2 API already is quite
complicated, and sometimes, less is more...
'Norbert
