Hello Gerd, > > 1) streaming-capture > > 2) read()-capture > > 3) overlay > > > > This means that 2) interrupts 3) and 1) interrupts the 2) and > > 3). > > Hmm, don't think so. (1) + (2) should be basically the same, with > the main difference that (1) gives exclusive access to one application > (which will be able to capture with full framerate then). (2) is > basically the same, but without exclusive access. read() will put > the buffer into the quere, and multiple applications can do that at > the same time. > > If some application does (1), no other application can do (1) or (2). > If some application does (2), other applications can't to (1), but (2) > would simply queue up the capture request of the second application. > As read() does single frame capturees only, the second application > can expect to get it done within reasonable time. > > (3) can be done at "low priority" if nothing else is to do, i.e. if > nobody does either (1) or (2) or if some app does streaming capture > but failes to queue up free buffers fast enouth. If this works and > is useful depends on the hardware, so I think supporting the "low > priority" thing for overlay should be an *option* for the driver. > IMHO it should be perfectly valid for the driver to return -EBUSY > on capture requests if overlay is active. OK, you have convinced me. Perhaps things should be handled sane and symmetrical -- like you stated in a private mail to me. This means that any "normal" driver is likely to return -EBUSY if something other is going on, e.g. while 3) you cannot do 1) or 2), and while 1) is going on, you cannot 2) or 3). This will keep things simple for driver writers. IMHO this should be the default behaviour described in the v4l2-specs, so that app-writers do not rely on stuff that is only supported by some driver. If some particular hardware can handle things more effectivly, it's up to the driver. > bttv can easily route video on a frame by frame basis with nearly > zero overhead -- but only as long as it is the same video input. > So filling idle time for (1) with (3) can be done only of the input > is the same (input switching takes some time to resync which will > loose some frames which isn't allowed for (1)). For (2)+(3) at the > same time bttv could switch inputs... The same stuff applies to my driver. But I don't think it's worth the effort -- a sane capture app may lose only some frames. But these lost frames don't make a good overlay impression... > > The default behaviour for audio of 1) + 3) is, that they switch > > the audio source, too. 2) should not (in it's default > > behaviour) switch the audio source, since read() is not > > really useful for streaming capture and therefore does not > > need the audio signal. > > I don't like the driver doing to much automagically. But you agree that audio is not really useful for read() capturing? > > (Especially in your "multiple open"-draft you state > > that for read() the driver should set up the hardware, make one capture > > and then set back the settings -- with this, "streaming" is > > not possible anyway.) > > Where is the "set back" written down? The next application coming will > override them, or maybe a "low priority overlay" hanging around in the > background. But I can't see a need to set back the settings explictily. Ok, then I misunderstood something in your proposal. You write: > single frame capture, will set the format and lock down the > ressources just for that single read and frees > them when done. Two applications doing a read() capture > from time to time should happily coexist. I thought that "freeing" implies "setting back". > IMHO it is more clever to have a shared set for these controls (one global? > one per input?). Of course one needs a way to lock access to these controls, > if some application is going to record something important it probably > does'nt want allow others to f*ck up the movie by setting the contrast > control to zero. I agree with the things, Bill already sent in another mail. > Gerd Ok, my driver will support multiple capturing opens, but will deny any parallel access, no matter what it is. Please make clear (in your proposal) what things have to be per context and what stuff has to be per open. Thanks! CU, Michael.
