Billy Biggs wrote: > Petr Vandrovec ([EMAIL PROTECTED]): > > >>>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 _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
