nDiScReEt wrote: >> On Fri, 2002-03-22 at 09:29, Mark McClelland wrote: >> >>> How about a minimal libv4l with a consistent interface for the other >>> libraries to "plug in" to? That way, libv4l would provide a standard >>> mechanism without enforcing the "policy" of a particular >>> deinterlacer, scaler, etc... >> > > You mean like a default libv4l with basic "policy" > compression/uncompression and a libpwc or libse401 type library for > more advanced and webcam specific compression/uncompression type > stuff? (showing my ignorance er.. newbieness through careful word play)
Not quite. libv4l would only provide a generic conversion wrapper API, which would be implemented by the hardware-specific "plugin" libraries. Apps would only need to link against libv4l, and new hardware could be supported by simply installing a new plugin into /usr/lib/libv4l/plugins. For example, an app wants to decompress a frame captured from an OV518 camera and display it on the screen. The app would tell libv4l to "convert format FourCC:O518 to V4L:RGB24", and libv4l would dynamically load libv4l-FourCC-O518.so and do the conversion. If the plugin can only convert to YUV420P, a second conversion would be performed (by a separate hardware-independent plugin) to get it into RGB24 format. As for deinterlacing, contrast/gamma/sharpness emulation, etc..., I would hope that a separate library would handle that. There are too many possible things a driver implementer might want to do to put it all in one generic library. If it gets too bloated, then every developer will be able to find *something* that they don't like about it, and they'll go off and pointlessly reimplement the whole thing (and demand that I port my OV518 plugin to their library). Bloated means that libv4l has grown beyond 200 lines of code, BTW. To make that abundantly clear, it should probably be called libv4l-convert :) Plugins would only need to export two functions: a getConversions() function that returns the pairs of input/output formats it can handle, and convert(inbuf, outbuf, informat, outformat). Possibly, a getCapabilities() function that tells whether the plugin supports MMX/SSE/FPU would be useful as well. Unfortunately, I hardly know anything about userspace programming, so the implementation would have to be left to someone besides myself. I barely have time to maintain and develop my drivers as it is. -- Mark McClelland [EMAIL PROTECTED] _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
