Re: [GnomeMeeting-list] Unlimiting Bandwidth?

["Jeffrey C. Ollie" <jeff ollie clive ia us>]

On Tue, 2003-05-20 at 03:13, Damien Sandras wrote:
> 
> Yes I noticed the image was rather big (probably CIF * 2 = 352x288 * 2)
> which is too big if you don't use hardware acceleration. If you want a
> bigger image, I suggest you to switch to fullscreen, provided that your
> video hardware config supports YUV overlays (if not, 0.97.0-CVS is using
> RGB24).

I'm using a nVidia GeForce2 MX 400 with the binary XFree86 drivers from
nVidia.  xvinfo confirms that YUV overlays are supported.  My camera is
a Logitech QuickCam Pro 4000.  Is there some way of determining for sure
that YUV overlays are being used?  During a call XFree86 is using up a
lot of CPU too.  Here's the output from "-d 6" that relates to the video
grabber:

>   0:06.138      GMVideoGrabber:41d3f008 PVidDev SetFrameSize to 1x1
>   0:06.326      GMVideoGrabber:41d3f008 PVidDev SetColourFormatConverter, want YUV420P trying YUV420P
>   0:06.406      GMVideoGrabber:41d3f008 PVideoInputDevice        SetFrameSize 640x480 Initiated.
>   0:06.411      GMVideoGrabber:41d3f008 PVideoInputDevice:       GetFrameSizeLimits. 160x120 -- 640x480
>   0:06.654      GMVideoGrabber:41d3f008 PVidDev SetColourFormatConverter set camera to native YUV420P
>   0:06.659      GMVideoGrabber:41d3f008 PColCnv PColourConverter constructed: YUV420P->YUV420P 640x480
>   0:06.663      GMVideoGrabber:41d3f008 PColCnv SetSrcFrameSize Succeeded, YUV420P 640x480, 460800 bytes.
>   0:06.685      GMVideoGrabber:41d3f008 PColCnv SetDstFrameSize Succeeded, YUV420P 640x480, 460800 bytes.
>   0:06.690      GMVideoGrabber:41d3f008 PColCnv SetFrameSize: 640x480 OK
>   0:06.777      GMVideoGrabber:41d3f008 PVideoInputDevice        SetFrameSize 640x480 Initiated.
>   0:06.781      GMVideoGrabber:41d3f008 PVideoInputDevice:       GetFrameSizeLimits. 160x120 -- 640x480
>   0:06.785      GMVideoGrabber:41d3f008 PColCnv SetSrcFrameSize Succeeded, YUV420P 640x480, 460800 bytes.
>   0:06.790      GMVideoGrabber:41d3f008 PColCnv SetDstFrameSize Succeeded, YUV420P 640x480, 460800 bytes.
>   0:06.795      GMVideoGrabber:41d3f008 PVidDev SetColourFormatConverter succeeded for converted YUV420P camera using YUV420P
>   0:06.804      GMVideoGrabber:41d3f008 PVideoInputDevice        SetFrameSize 352x288 Initiated.
>   0:06.808      GMVideoGrabber:41d3f008 PVideoInputDevice:       GetFrameSizeLimits. 160x120 -- 640x480
>   0:06.813      GMVideoGrabber:41d3f008 PColCnv SetSrcFrameSize Succeeded, YUV420P 352x288, 152064 bytes.
>   0:06.818      GMVideoGrabber:41d3f008 PColCnv SetDstFrameSize Succeeded, YUV420P 352x288, 152064 bytes.
>   0:06.822      GMVideoGrabber:41d3f008 PVidDev SetFrameSize to 352x288
>   0:06.982      GMVideoGrabber:41d3f008 PVidDev SetFrameSize to 352x288

> There is also an "enable bilinear filtering" in the preferences that
> could be disabled if your CPU suffers too much.

Yes, this definitely stresses the CPU.  Is this implemented in GM or in
OpenH323?  Too bad I don't know x86 assembler or I'd try rewriting
subroutines like these to see if there would be performance benefit.

I also noticed that reducing the size of the transmitted video from
large to small had a significant effect on CPU usage.

> > compiling PWLib/OpenH323/GnomeMeeting?  I'm currently running binaries
> > compiled with "-O2 -g -mcpu=i686 -march=i686" (the defaults you get when
> > compiling with RPM).  I'm recompiling now with "-O3 -fomit-frame-pointer
> > -fstrength-reduce -frerun-cse-after-loop -funroll-loops -mcpu=i686
> > -march=i686" to see if it helps.
> 
> I'm using standard flags, no optimisation, but if you can contribute
> flags that optimize things dramatically, please contribute them.

The above flags don't seem to make a dramatic difference, but they don't
seem to have hurt either.

Jeff