Well,
here's an update about my thoughts and some work I got done.
=== Work done ===
This is in fact pre-work, to make it easier to move the current drivers
to a new scheme, whatever that new scheme will turn out to be. It's not
code, but its careful planning, and as anyone should know, it is really
boring to do, but quite important to ease the future.
The result of this is a nice gnumeric spreadsheet, which I'll now
describe. There are four sheets: functions, variables, #includes and
#defines.
The "functions" sheet shows all functions defined in the various
drivers. There are four columns: function name, V4L, AVC and DC. An "*"
or a "=" in a driver column means the function is defined for this
driver. The "=" is there to show when a function has equal
implementations in at least two drivers (ie: "=" in AVC and DC columns
and "*" in V4L means we'll need to write only two functions: one common
for IEEE1394, and one for V4L ; "=" in all columns means only one
function).
The "variables" sheet shows all variables in the pwlib linux video
subtree. There are five columns: the name of the variable, whether it is
linux-specific, in V4L, AVC or DC. Why that second column? Because the
declaration of the PVideoInputDevice class has linux-specific things! I
find it really awful design. And better yet, once you'll see where that
variable is used (the three last columns), you'll realize most of them
aren't that linux-specific, but really v4l-specific.
The "#includes" sheet shows what include files are used by the various
drivers.
The "#defines" sheet shows what constant are defined/used by the
drivers. Notice that some trigger the inclusion of debug variables, not
marked as such in that file... I think it isn't that important at the
moment.
== To be done ==
I still haven't got any code. But after discussing a little with Damien
on #gm, I feel that since I want to rewrite the video interface, I
should get it right from the start, ie: with plugins.
I would really like to discuss things more in-length before any cut'n
pasting+coding. I would like to get rid of the v4l-specific thingies in
the PVideoInputDevice class. This is evil. Especially since it is
defined in videoio.h, and adds that arch cruft (at that place it is
cruft) by #including. ptlib/videoio.h! Yes, two include files, with the
same name... PVideoInputDevice should stay fully arch-agnostic.
The way I think about it, the PVideoInputDevice class should be a
plugin-manager class, and could be used not only for linux, but also for
any reasonable system (POSIX?). The rest would be plugins.
A plugin would have a prefix (V4L, IEEE1394AVC, IEEE1394DC, ...), and
add it to the list of devices it thinks can handle, so that the manager
would know which plugin to use when asked to open "[V4L]/dev/foo"; that
would allow the manager to do its magic, without breaking all apps.
== Questions ==
The main question is: when do we load the plugins, and thus know what we
have at disposal? We don't really want to scan them twenty times, but we
don't want to change the way the programs that use pwlib work, and I
find it a little tricky; looking at the way a gm does device detection:
gw->video_devices = PVideoInputDevice::GetInputDeviceNames ();
gw->video_devices += PString (_("Picture"));
there is no created PVideoInputDevice at that moment, but since we want
to return the device names, we need the plugins!
PVideoInputDevice *grabber;
grabber = new PVideoInputDevice();
grabber->SetPreferredColourFormat (color_format);
...
when PVideoInputDevice() is called, looks like a good moment to load
plugins, but I think it is already too late as gm already tried to get
the devices names...
And there's also the little technical detail that I don't know (yet) how
to code a plugin in C++. Already done so in C with dlopen...
== Conclusion ==
I need some advice, some directions, some doc, and some contradictory
view. If you find any missing informatoin or anything false/inaccurate
in the spreadsheet, I would be glad to know about it!
Snark
PS: this little program shows that sscanf may be enough for the manager
to get the driver name... notice that the driver name shall not be
bigger than ten characters in that example.
#include <stdio.h>
static char *tests[] = {
"V4L /dev/video0",
"IEEE1394AVC /dev/raw1394",
"IEEE1394DC /dev/raw1394",
"PLOP TIC /dev/toto",
NULL
};
int main(int argc, char **argv)
{
char **deviceline, driver[11], *devicename;
for(deviceline=tests; *deviceline!=NULL; deviceline++)
{
if(sscanf(*deviceline, "%s", &driver) != 1)
printf("Error\n");
else
{
devicename=*deviceline+strlen(driver)+1;
printf("Device line: %s\n Driver: %s\n Device: %s\n",
*deviceline, driver, devicename);
}
}
exit(0);
}
Attachment:
PWlib-video.gnumeric
Description: application/gnumeric