Re: [GnomeMeeting-list] video failure with ovfx2

[Derek Smithies <derek indranet co nz>]

Hi,
  
I take offense at this comment:

> GnomeMeeting author: "GM works with other cameras, it must be a driver bug"
> Driver author: "Driver works with other apps, it must be a GM bug"
> Me: "I don't care, I'll fix the bug myself, I just want it to work"

The driver author is wrong.

If the driver works with some apps, one has proof the driver 
 may correctly implemenet some of the v4l spec.

You see, apps use only some of the V4L spec.
Apps will contain workarounds for driver inadequacies.

One does not have proof the driver implements (correctly) the entire v4l 
spec.

Explain this to me driver author:
Why does GnomeMeeting work with some cameras, and not others?

Noone has shown where GnomeMeeting differs from  the V4L standard.

Since GnomeMeeting is the one constant thing, and has yet to be shown
where it differs from the V4L standard, I conclude it is driver
deficiencies.

You will note from an inspection of 
./pwlib/src/ptlib/unix/video4linux.cxx
comments like:

  // Some drivers always return success for CSPICT, and can't
  // read the current palette back in CGPICT.  We can't do much
  // more than just check to see if there is a preferred palette,
  // and fail if the request isn't the preferred palette.
                                                                                
 This is what I have found from hours of tedious debugging. Does this not 
read like, "driver author did not do a full and proper job?????"


Apologies for starting a flame war. However, I am sick and tired of 
driver writers who believe (incorrectly) that their code is 
correct. Sigh, am I being arrogant in thinking GM is correct in its use of 
V4l code ? Maybe. But, lets move on  to the goal of working, correct, 
code.

Derek.
===============================================================


On Sun, 24 Aug 2003, Dan Egnor wrote:

> > > By default, when I start gnomemeeting (0.98) it claims at start that
> > > it cannot set the video frame size.  After debugging the code (the
> > > PTLib/OpenH323 makefiles sure are icky!), I found that if I swap the
> > > order of initialization so that it sets the frame size after setting
> > > e.g. the color conversion, that gets past that error.  This is such a
> > > simple and obvious error that I presume it's been fixed in CVS by now.
> 
> > That's a bug of the driver, not of GnomeMeeting or pwlib... However,
> > 0.98 has a different order of initialisation, I'll revert it to the old
> > order in CVS, but again, you are running a buggy driver.
> 
> PVideoDevice::SetFrameSizeConverter() includes the following code, near
> the top:
> 
>   if (!converter)
>     converter = PColourConverter::Create(colourFormat, colourFormat, width, heig
> ht);
>   if (!converter) {
>     PTRACE(1, "PVidDev\tSetFrameSizeConverter Colour converter creation failed")
> ;
>     return FALSE;
>   }
> 
> If the color format has not been initialized at that point -- which it 
> hasn't, in the gnomemeeting code -- then colourFormat will be an empty
> string, and PColourConverter::Create() will attempt to look up a conversion
> from "" to "", and since it has no such conversion registered, it will
> return NULL.
> 
> What I wonder is: how can that order of initialization work with any
> driver?  It seems guaranteed to fail in libpt before even touching the
> driver, but surely it doesn't.  Why did you change the order of 
> initialization at all?  And why not just use PVideoInput::OpenFull(),
> which initializes everything at once in the correct order?
> 
> > Other apps are not using the same size, color palettes and such. If your
> > driver has been tested with xawtv only, it is highly possible it only
> > works with applications based on xawtv's code.
> > Given the fact that pwlib works with other cameras and drivers, I would
> > suggest you to report them bugs so that they can fix the driver.
> 
> GnomeMeeting author: "GM works with other cameras, it must be a driver bug"
> Driver author: "Driver works with other apps, it must be a GM bug"
> Me: "I don't care, I'll fix the bug myself, I just want it to work"
> 
> If you can think of another app that's not Xawtv-based, I'll be happy to
> try it.  So far I've been unable to find a v4l app besides GM that doesn't
> work.  Maybe another app that uses pwlib for video grabbing?  Know any?
> 
> The driver only supports a single size and colour palette, anyway, as far
> as I know; anything else is done by conversion (in GM's case, in the pwlib
> layer).  Anyway, I guess I'll dig into the pwlib capture code.
> 
> Dan Egnor
> _______________________________________________
> GnomeMeeting-list mailing list
> GnomeMeeting-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
> 
> 
> 

-- 
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek indranet co nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/