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

[Guilhem Tardy <guilhem_tardy yahoo com>]

>  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/