> > ATTACHMENT part 3.2 message/rfc822 > Date: Thu, 10 Oct 2002 11:21:58 -0500 > From: Billy Biggs <vektor@xxxxxxxxxxxx> > To: video4linux-list@xxxxxxxxxx > Subject: Re: Re: v4l2 api > > 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. But that is exactly what I said, for some reason the previous idea of returning EBUSY was attributed to me. So let me repeat what I said. My suggestion (and I have implemented this on other h/w and I know works) is to have a user space mapped ring of buffers that are grabbed and stored in time order (using TSC or something like that in x86 land) These buffers are continously filled by the DMA engine of the frame grabber h/w. Any user process can then map the range of these buffers and pick up the frames that it wants. It it wants to run at half rate it can then decide to skip every other frame in time etc .. Multiple consumers can also map the ring of buffers and can be simultaneously receiving this stream. On a uniprocessor system, this will depend on the context switching and the memory b/w being sufficient to allow the different streams to be copied/processed from the global ring, to each process's local memory but on a MP system this could actually make a very usable stream server. -- Shrijeet __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com
