> > > 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.
For streaming capture (i.e. STREAMON, QBUF + DQBUF loop, STREAMOFF)
a v4l2 driver must hand out frames at full frame rate. Thus the driver
will likely return -EBUSY in this case, because it isn't allowed to give
out frames to another application[1]. For multiple applications reading
single frames now and then using read() the queuing approach will do
just fine through.
Gerd
[1] Well, it might be possible to do that neverless, by field splitting
for example. streaming capture of the even fields still allows to
hand out the odd fields to other apps ...
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
