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

["Yann Klis" <yklis kaliasys com>]

Little OT maybe...

Just a little question about the openh323 source code, as you seem to
understand the thing globally.

Is the network code (H.323 part) really and clearly separated from the other
parts (video device accessing for example) ?

I ask this question to know how it would be difficult to develop H.323
gstreamer sink and source elements. I'm not trying to launch another troll on
this subject, but many people ask for some funny things like PowerPoint (or
OpenOffice) viewing synchronously while videoconferencing. A generic and
elegant (according to me) solution to this may be to develop Gstreamer H.323
sink and source elements, and a powerpoint decoder element (a jpeg decoder
element already exists too).

Just thoughts for the moment...

++

yk

On 24 Jul 2003 14:38:37 +0200, PUYDT Julien wrote
> 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
> 
> _______________________________________________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list



--
Open WebMail Project (http://openwebmail.org)