support autofocus / autogain in libv4l2
Mauro Carvalho Chehab
mchehab at s-opensource.com
Mon Apr 24 21:47:31 EDT 2017
Em Mon, 24 Apr 2017 23:29:14 +0200
Pavel Machek <pavel at ucw.cz> escreveu:
> > > For focus to be useful, we need autofocus implmented
> > > somewhere. Unfortunately, v4l framework does not seem to provide good
> > > place where to put autofocus. I believe, long-term, we'll need some
> > > kind of "video server" providing this kind of services.
> > >
> > > Anyway, we probably don't want autofocus in kernel (even through some
> > > cameras do it in hardware), and we probably don't want autofocus in
> > > each and every user application.
> > >
> > > So what remains is libv4l2.
> > IMO, the best place for autofocus is at libv4l2. Putting it on a
> > separate "video server" application looks really weird for me.
> Well... let me see. libraries are quite limited -- it is hard to open
> files, or use threads/have custom main loop. It may be useful to
> switch resolutions -- do autofocus/autogain at lower resolution, then
> switch to high one for taking picture. It would be good to have that
> in "system" code, but I'm not at all sure libv4l2 design will allow
I don't see why it would be hard to open files or have threads inside
a library. There are several libraries that do that already, specially
the ones designed to be used on multimidia apps.
Resolution switch can indeed be a problem on devices that use MC
and subdev API, as a plugin would be required to teach the library
about N9 specifics (or the Kernel API should be improved to let
a generic application to better detect the hardware capabilities).
> It would be good if application could say "render live camera into
> this window" and only care about user interface, then say "give me a
> high resolution jpeg". But that would require main loop in the
Nothing prevents writing an upper layer on the top of libv4l in
order to provide such kind of functions.
> It would be nice if more than one application could be accessing the
> camera at the same time... (I.e. something graphical running preview
> then using command line tool to grab a picture.) This one is
> definitely not solveable inside a library...
Someone once suggested to have something like pulseaudio for V4L.
For such usage, a server would be interesting. Yet, I would code it
in a way that applications using libv4l will talk with such daemon
in a transparent way.
> > The above looks really odd. Why do you want to make libv4l2 dependent
> > on sdl?
> I don't, but I had some nasty problems with linker; this should really
> go into application but it refused to link. Scary libtool.
> > If you're adding a SDL-specific application, you'll need to add the
> > needed autoconf bits to detect if SDL devel package is installed,
> > auto-disabling it if not.
> > Yet, I don't think that SDL should be part of the library, but,
> > instead, part of some application.
> Agreed. libtool prevented me from doing the right thing.
if you add libSDL detection at configure.ac, you likely won't need to
deal with libtool.
On a quick look at web, it seems that there's a m4 module that does
the right thing, according with:
More information about the linux-arm-kernel