On Tue, 10 Feb 2009 19:18:03 +0100 Jean-Francois Moine <moinejf@xxxxxxx> wrote: > On Mon, 9 Feb 2009 18:50:15 -0200 > Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: > > > On Thu, 5 Feb 2009 10:32:31 +0100 > > Jean-Francois Moine <moinejf@xxxxxxx> wrote: > [snip] > > > Please pull from http://linuxtv.org/hg/~jfrancois/gspca/ > > > for: > [snip] > > Hmm... it seems that your tree has more changesets than what you've > > pointed on your pull request... I got here 15 patches. > > Right! And there are some more to come! I was waiting for you to do the > pull before requesting a new pull... Please, don't add newer patches after requesting me to pull, otherwise, I may not pull from it, since the other patches may not be ready yet for pulling. If you want an experimental tree, the better is to create a second tree there. > > We should really standardize those controls and prepare some patches > > for V4L2 API also, documenting what does that mean. Btw, it as not > > clear what's the difference between those "quality" controls... > > Well, each webcam has a lot of parameters. Some of them enter in the > standard controls, some other ones are very specific. > > This is the case here for the zc3xx subdriver: there is a quality > parameter in the bridge which accepts values from 0 to 3. This > parameter is automatically set by the ms-win driver according (surely) > to the luminosity, and its initial value depends on the sensor. As we > have no documentation about this quality, the best for me was to have a > specific control (CAM_QUALITY). Ok, in this specific case, I agree that maybe this could be a private control. Yet, if an userpace app is aware of it, it can have an userspace algorithm to automatically adjust it based on luminosity. > What difference with the JPEG quality? This last control is used to > load the quantization tables into the webcam. The quality is the > standard JPEG compression quality (value 0..100 in percent). > > And the last control? It is not a control of the webcam. It defines > the quantization tables which are added to the webcam raw images to > create JPEG images readable by any JPEG/MJPEG viewer. So, while their > units are the same (compression in percent), the difference between > JPEG_QUALITY and IMAGE_QUALITY is that the first one is used for > encoding (in the webcam) while the second one is used for decoding (by > the v4l library). Both of those quality controls seem standard enough to use a standard. > Indeed, I should have written some documentation, but I think most users > will play with these controls before reading anything. > > About the two last controls (quantization tables in the webcam or added > in the raw JPEG images), there is already a jpegcomp ioctl, but I could > not understand how it should work. AFAIK, only one driver implements it. If the spec is not clear enough, then we should patch the spec and use it, instead of creating yet another control for the same thing. Looking at meye.c code, the V4L2_CID_JPEGQUAL seems to control what you called as IMAGE_QUALITY, e. g. it controls what quantization table will be used. It is also a private control: #define V4L2_CID_JPEGQUAL (V4L2_CID_PRIVATE_BASE + 3) I would do, instead, something like this, at videodev2.h: #define V4L2_CTRL_CLASS_JPEG 0x009a0000 /* Jpeg class controls */ #define V4L2_CID_JPEG_BASE (V4L2_CTRL_CLASS_HPEG | 0x900) #define V4L2_CID_QUALITY (V4L2_CID_CAMERA_CLASS_BASE+17) #define V4L2_JPEG_QUALITY (V4L2_CTRL_CLASS_JPEG_BASE+0) #define V4L2_JPEG_QTABLE (V4L2_CTRL_CLASS_JPEG_BASE+1) Adding V4L2_JPEG_QTABLE to all cases where the legacy V4L2_CID_JPEGQUAL were used. > Otherwise, one interesting feature of the V4L2 API is the possibility > for any application to handle all standard and private device controls > via VIDIOC_G/S_CTRL. Usually, control changes are not done > automatically by applications, but by the users. True, but certain applications (like multimedia conference and surveillance software) may want to adjust the codec quality according with the amount of bandwidth to be used. By using a standard way, they can automatically handle such controls, and even adjusting the quality based on the luminosity of the environment. > Once a user has set > the controls to get correct images, he may start any viewer application > (but not mplayer which resets some controls to their default!). > > BTW, it should be useful to have a program which saves the control > values on disk at change time, device disconnection or reboot) and > reload them at system start or on device connection... This has pros and cons. tvtime does this for analog TV. That's a nice feature on most cases, but, when a command changes its scale, or their default values, then we have a trouble, since the saved control may produce a black image for example (we just have this issue recently with a cut-and-paste error that happened on V4L subdev). Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
