[GnomeMeeting-devel-list] Towards a new video driver support in pwlib

[PUYDT Julien <julien puydt laposte net>]

Hi,

== Forewords ==

nice subjet, eh? The reason it doesn't begin with a "[PATCH]" and end
with an attachment is because I don't have that much free time to work
on it... but since the idea seems nice, I thought I could at least share
it, and hope someone more talented and less occupied would take care of
it, at least partly. It was already a little too long to come up with
this...

== Current situation ==

* pwlib knows 3 types of video drivers under Linux: V4L, AVC and DC;
* pwlib probably doesn't support both AVC and DC;
* to have a gm+AVC or gm+DC, one has to recompile both pwlib and
gnomemeeting, which makes it quite impractical to have packages with or
without the various IEEE1394 drivers.

== Possible situation ==

* the same drivers could be supported;
* supporting AVC&DC simultaneously, even on the same device filename
(the explanation makes this filename point clearer);
* gm wouldn't have to know at compile-time which drivers are supported
by pwlib, ie: supporting a new driver would only mean another pwlib
package;

== How to do that? ==

The current situation is:
* a PVideoInputDevice class, that really is a V4L driver;
* a PVideo1394AvcInputDevice class, that really is a IEE1394AVC driver;
* a PVideo1394DcInputDevice class, that really is a IEE1394DC driver;
gnomemeeting hence has to know which class it will use before creating
its videograbber: there are #ifdef'd tests, doing grabber = new
PVideoWhateverInputDevice, depending on some magic guessing, based upon
the device filename (that is where AVC&DC can have problems
cooperating).

What I have in mind would be a single PVideoLnxInputDevice (inheriting
from the [mostly] virtual PVideoInputDevice)(notice: that means a little
source incompatibility with existing apps, but since it simplifies their
life, that seems reasonable).

Within the declaration of that class, there would be:
* an added enum { NONE, V4L, IEEE1394AVC, IEEE1394DC} driver;
* #ifdefined declaration of driver-specific functions, like OpenV4l,
OpenAvc, and OpenDc.

Those driver-specific functions would be defined in files like
driver_v4l.cxx, etc, that would only be conditionnally included in the
build (just like video4avc1394.cxx at the moment). Most of them would
only be the current functions renamed with a driver suffix (OpenV4l
instead of Open, for example). The essential exception would be the
GetInputDeviceNames functions; they will be renamed, but, wouldn't give
back the list of device filename as currently, but a modified version,
with an added prefix. For example,  GetInputDeviceNamesAVC would give as
a list "[IEEE1394AVC]/dev/raw1394", and GetInputDeviceNamesDC 
"[IEEE1394DC]/dev/raw1394"; since the same filename can really be
either, the user would have to choose the right one, and the class would
know the difference: we have two drivers on the same de

Within the definition of the class, there would be functions like:
* GetInputDeviceNames, with #ifdefined parts calling the driver-specific
GetInputDeviceNamesV4l, etc functions, modified as described;
* Open, would look at the prefix of the deviceName, and accordingly set
driver to for example IEEE1394AVC, strip the prefix and call OpenAvc;
* the other functions would have a switch(driver) { case V4L: ... case
IEEE1394AVC: ... } (with cases #ifdefined);

The idea is that before the Open, only functions generic to the
PVideoInputDevice are called anyway, and those hence don't care about
the specific driver. After the Open, we know which driver we use, and a
switch makes sure we call the right driver-specific function.

Basically, I put all drivers in the same class, since it is not possible
to dynamically change the class at runtime -- especially since we know
the precise type only when Open is called!

== Using it in gnomemeeting ==

Simple:
grabber = new PVideoLnxInputDevice;
get the list of devices as usual, let the user choose as usual, then
grabber.Open(...) as usual.
and, of course, remove all this #ifdefs, that really don't belong in
gnomemeeting: the pwlib is supposed to take care of the devices, let's
let it take care of it!


Let's discuss!

Snark