Re: [GnomeMeeting-list] IBM Ultraport II Cam and gnomemeeting 0.85.1, RH 7.3, kernel 2.4.18-3

[Kurt Stephens <ks kurtstephens com>]

Damien Sandras wrote:
> On Mon, Jul 01, 2002 at 12:25:36PM -0500, Kurt Stephens wrote:
>
> > Not to be a pain in the ... but gnomemeeting should handle any device 
> > image size.  Or is there something about V4L that I dont understand?  Is 
>
>
> The H.323 protocol specifies that if a H323 software is able to do video
> (ie Netmeeting, GnomeMeeting, ...), it has to support the QCIF size.
> QCIF size is 176x144, it is not an obligation to support other sizes.
> GnomeMeeting also supports 352x288 (ie CIF size). Netmeeting also supports
> QCIF and CIF.
>
>
> > it policy that videodev clients specify the image size they want and the 
> > device driver must resample?  What if someone wants to use a HW NTSC 
>
>
> No, the device driver should not resample. But if the device driver doesn't
> support 176x144 as video size, it should report an error and not say "it is
> ok" but send a broken picture. The Philips Vesta Pro Scan for example only 
> supports 160x1?? but works in 176x144 with a black border. In that case,
> GnomeMeeting can ask to the driver to send the 160x size, and send QCIF
> as requested by H.323. But your driver has a bug, apparently.
>
>
> > frame grabber at 640x480 with gnomemeeting?  Does the restriction of 
> > 176x144 or 352x288 lie in the H.261 protocol?
> >
> > I tend to think that device drivers should be as dumb as possible.  I'd 
> > be willing to contribute wherever help is needed, but I've never hacked 
> > linux kernel code.  Put the image scaling code in reusable library 
> > instead, that could be embedded later in drivers that *absolutely* need 
> > it or other apps that have nothing to do with /dev/video.  Less code in 
> > the kernel makes the kernel smaller and more reliable.  I vaguely 
> > remember someone open-sourcing some image scaling routines, used in OGLE.
>
>
> I agree. Even if image scaling is not implemented, you can add a black border,
> or simply cut parts of the image. That is what would happen if your driver
> had no bug.

Isn't the driver returning the frames in the resolution as supported by 
 the camera?  Or is the driver misreporting the dimensions of the 
frames from the ioctl() call?  Not supporting an application-specific 
(H.261) format does not necessarly make the driver buggy, unless that is 
part of the V4L specification (i.e. a set of lowest common denominator 
formats must be supported for a V4L device).

Making the application handle more device formats makes the application 
work with more drivers.  If I add scaling or padding code to 
gnomemeeting would it allow it to use more devices.  If I add scaling or 
padding code to ultracam.c, it only adds functionality to that device. 
Or does V4L2 handle this issue?

BTW: gcqcam-0.9 does not work with this driver either; I wonder if it 
makes the same assumptions about frame dimensions?  It opens the device 
but does not seem to honor the format that the device supports and/or 
reports; I get the same type of bogus display.

I'm trying to figure out where my effort is best directed.

> > One less reason to run VMWARE is always a good thing.
> >
> > Yours,
> > Kurt Stephens
>
>
>
> Damien

Kurt Stephens