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
mmcclell@xxxxxxxxxxx
