[GnomeMeeting-list] Re: how to support another capture card? (WAS: experience with theV4L1 compatibility of V4L2)

[Bill Dirks <bdirks pacbell net>]

The Winnov driver will only capture a single field (limitation of the
driver). The maximum width the card can capture is 640 pixels. The
maximum height is either 240 pixels or 288 pixels depending on whether
it is set to NTSC or PAL mode.

The max capture size is reported as 640x288 always. It's possible to
have the driver report 640x240 or 640x288 depending on the current state
of the hardware, but then it could be wrong if the hardware state
changes. I'd rather be wrong too big than too small, as too small could
cause a buffer overrun.

The software must always query the hardware after a format change. Any
number of device factors or driver factors may affect the actual
available modes and settings. Something like a set-format is only a
request, and device state after is the nearest supported format.

Bill.


Guilhem Tardy wrote:
> 
> >  openh323 is constained on frame size by the video codec it uses: H261
> > openh323 video code must generate a frame that is: 352x288 or 176x144.
> 
> I am adding H263 capability (although the actual codec will be up to others to
> provide). Still, I would be happy with only the sizes you listed above.
> 
> > We have found in developing code that some grabbers will not provide the
> > 176x144 frame size requested.
> >
> > Consequently, the library tries to grab a different frame size, and then
> > convert the frame size into something the codec can use.
> 
> I found the library handling of frame sizes awkward. I have a misbehaving
> Winnov Videum card and V4L2 driver, which advertises 640x288 as maximum
> resolution while it is capable of only 640x240. This wouldn't be a problem if
> VideoInputDevice::Open() in video4linux.cxx didn't set the internal variables
> frameWidth and frameHeight to the maximum resolution while not actually setting
> the card to that resolution (and verify the hardware frame size). IMHO, the
> asynchronism between the internal variables and the state of the card is a
> design flaw, which in my case resulted in the card being unusable. The reason
> being that SetColourFormat() also attempts to set a frame size converter for an
> unsupported frame size (640x288).
> 
> I did finally get the Videum card working with this:
> when VerifyHardwareFrameSize() in video4linux.cxx finds that the frame width
> and/or height don't match, it now saves the actual value in the internal
> variables. Plus, I added a line in the table of possible conversions in
> videoio.cxx: { 352, 288, 352, 240 }
> 
> Somehow, it works and that's all I need now. I would like to revisit all of
> this sometime, but I am in a real tight schedule right now.
> 
> > Providing the appropriate frame size should be done in the library.
> 
> I totally agree with you on this (and never intended to perform such a function
> in the application).
> 
> > However, take this to another level.
> >
> > Suppose there are 10 libraries out there that grab video, and present it
> > for applications to use.
> > Those 10 libraries all contain framesize/format converters.
> > Thus, 10 framesize/format converters have been written.
> >    not good.
> >
> > Do it once, do it right. Do  the framesize/format conversion in
> > the kernel. Is this what v4l2 does?
> 
> I haven't seen anything like this in v4l2, but some driver may do it. For
> instance, the Videum driver already does some colour conversions. Doing frame
> size conversion in a driver would be obviously wrong, but at the v4l2 level...
> it is an interesting suggestion. Anyone?
> 
> Guilhem.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/