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. -- Billy Biggs vektor@xxxxxxxxxxxx
