> > For audio it is'nt that obvious. There is - for example - no need to > > touch TV sound if you switch the video input to the camera temporarely to > > capture a image for your webcam... > > IMHO there should be a "priority" like this: > > 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. 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 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. > (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. While thinking about the attributes I'm not sure they really should be part of the device context. For video input, video format, video norm every application needs it's own set. For the bright/contrast/audio/... settings this isn't required. In fact there are perfectly legal and useful szenarios where it is good _not_ having them in the device context. You might want to adjust the contrast for your webcam. Just start up xawtv and do so -- without stopping/restarting your webcam. Have some fancy, generic GUI tool for all sorts of v4l2 controls. 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. Gerd -- Protecting the children is a good way to get a lot of adults who cant stand up for themselves. -- seen in some sig on /.
