Mark McClelland wrote:
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.
I wouldn't mind trying to work on the user space programming. That is
what I do well anyway. This v4l and v4l2 is just all new to me and I'm
taking awhile to get adjusted. Also, considering the project that I'm
taking up. I'm trying to create a userspace program in java that can
either use the v4l and v4l2 drivers or replicate the API itself in pure
java form.
Has me deep in white papers for the past couple of weeks now.
Altoine
--
#/bin/bash
echo Altoine B
echo Maximum Time Unlimited
echo Chicago Based and Operated
echo
/usr/games/fortune
echo
uptime ; echo
