> 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 am very new in this area, and have not spent too much time looking into the current infrastructure, but I was looking into doing something like this for supporting multiple opens. The 2 avenues I was going to look into are 1. Sort all frame requests (as long as the requested formats were similiar or subsets of each other) into a queue of requested buffers with a global timestamp. Every attached/opened client can then just pick up the buffer for the timestamp that it requested. You could even have multiple clients effectively snooping the same feed. 2. Was to implement a very very simple scheduler, which would "context switch" the video stream into the next app that requested video buffers and was still unsatisfied. If state changes can be minimized (i.e. minimal reseting of format info) fairly fine grained multiplexing should be possible given the low data rate of NTSC/PAL. Also, on the timestamp idea, does anyone here know of the top of the head if linux on x86 uses the TSC register of the CPU if it available (I know, I know, I should go look at the code :-() Thanx > Gerd > > -- > 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 > > > > __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com
