Hi! > > > > 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 > > that. > > 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. Well, fd's are hard, because application can do fork() and now interesting stuff happens. Threads are tricky, because now you have locking etc. libv4l2 is designed to be LD_PRELOADED. That is not really feasible with "complex" library. > > 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 > > library... > > Nothing prevents writing an upper layer on the top of libv4l in > order to provide such kind of functions. Agreed. > > 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. Yes, we need something like pulseaudio for V4L. And yes, we should make it transparent for applications using libv4l. Regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
