LOCAL Video JPEG compression is too high using Logitech Quickcam Pro9000

Hi again,

I should have made myself a bit clearer. The squiggle artefacts on the edges are on the edges of the object in the image, such as the edge of my face, or the rims of my spectacles, or any other straight lines in the image such as my shirt collar or the edge of a table etc etc

I am pretty sure this is an Ekiga/uvc driver issue since when using luvcview on the webcam the compression artefacts are NOT noticeable, i.e. it does NOT show the same problem.

will@box:~$ luvcview
luvcview version 0.2.1
Video driver: x11
A window manager is available
video /dev/video0

will@box:~$ luvcview -L
luvcview version 0.2.1
Video driver: x11
A window manager is available
video /dev/video0
/dev/video0 does not support read i/o
{ pixelformat = 'MJPG', description = 'MJPEG' }
{ discrete: width = 160, height = 120 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 176, height = 144 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 320, height = 240 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 352, height = 288 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 640, height = 480 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 800, height = 600 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 960, height = 720 }
        Time interval between frame: 1/15, 1/10, 1/5,
{ pixelformat = 'YUYV', description = 'Uncompressed' }
{ discrete: width = 160, height = 120 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 176, height = 144 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 320, height = 240 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 352, height = 288 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 640, height = 480 }
        Time interval between frame: 1/30, 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 800, height = 600 }
        Time interval between frame: 1/25, 1/20, 1/15, 1/10, 1/5,
{ discrete: width = 960, height = 720 }
        Time interval between frame: 1/10, 1/5,
{ discrete: width = 1600, height = 1200 }
        Time interval between frame: 1/5,
will@box:~$

I'm not sure which width x height resolution Ekiga is using, it would be nice to know what is was and to have the width by height resolution displayed in Ekiga.
And to be able to configure the spatial resolution from within Ekiga would be fantastic. :)

Thanks

The attached PNG image (captured with Ekiga's Save Current Image feature) shows the squiggles I am referring too.

Hi,

Ekiga 2.0.x use by default a video resolution width = 176, height = 144. The picture you attached is taken from this resolution with a zoom factor x2.

To compare it, you should do the same with luvcview; require a 176x144 output and zoom it by 2.

There is an hidden trick to get a higher resolution in Ekiga:
open gconf-editor and turn the key "/apps/ekiga/devices/video/size" to "1" which will give you a 352x288 resolution.

The reason why this key is hidden is the codec compression used by ekiga 2.x is not good for compression (H.261); it will use a lot more bandwidth.

The upcoming next release (Ekiga 3.0) will add several more video codecs, including the great H.264 from the x264 project, and allow higher resolutions in Ekiga (at least up to 640x480). The team expect a release before the end of march 2008. This mean it will not be in the next Ubuntu release 8.04, probably in the 8.10.

Here is the roadmap: http://wiki.ekiga.org/index.php/Roadmap_to_3.00

Regards,
Yannick

Thanks Yannick.
You are quite right, when I run luvcview -s 176x144 I see the exact same amount of JPEG compression as I do in Ekiga (and zooming in x2 makes it more noticeable still,
just like in Ekiga.)
So, it's just a UVC thing then, or rather, I assume that it's just the level of JPEG compression that is being applied by the web camera's hardware and out of my control. Fair enough.

So, I assume that the Quickcam Pro900 does indeed apply stronger JPEG compression than the Quickcam Pro5000. Is that correct? (I guess it must be as Ekiga always uses a resolution of 176x144, and the Pro5000 image looks fines for that.)

Finally, thank you very much indeed for the tip about the hidden setting in gconf-editor. That's made the local image look MUCH better! Thanks :)
(Ironically I did look in gconf-editor before, but I did not notice that the size referred to QCIF and CIF, I stupidly assumed it referred to the ZOOM setting Ekiga. Doh!)

Finally, when I make a call to someone else, the CIF image viewed reverts to a QCIF image for the duration of the call. This was for both local and remote images. I guess Ekiga drops down to the lower resolution if the remote user is on the lower resolution.

I assume if we both use CIF resolution then Ekiga will remain at CIF resolution during the call too. Is that correct?

Thanks again.

Hi,

Thanks for reporting.

I don't know if the pro9000 apply stronger compression. This is something to ask the UVC driver developers...

I've no clue why Ekiga reverts to QCIF while in a call, you have to try.

Regards,
Yannick

Thanks for the prompt reply.

I might be wrong about Ekiga reverting to QCIF in a call. The image does look better now than it did yesterday. Both myself and the remote party have set the image size to CIF and I _think_ it is staying at CIF after all, though I'm sure something changes when I go into a call.

I'm looking forward to Ekiga v.3.0 :)

Thanks and kind regards.

Will
--

Hi

I am using CIF sized images now, so the compression level is bearable.

As discussed, I guess the compression level is the realm of the uvc webcam driver code and that team.
Perhaps also the compression level is FIXED in the camera hardware anyway.

Looking forward to increase spatial resolution images in the future in Ekiga.

Will
--

Hi WIll,
the JPEG compression level may be set via a V4L2 command. RIght now it is not set by ptlib, so it will switch to the cams default I suppose. Unfortunately I do not have a JPEG cam... Do you think you could comile a patched version of ptlib, opal and ekiga? On
wiki.ekiga.net
you should find all the info you need...

About switching to QCIf, this is mostly due to connecting to some other peer not supporting anything better...
Matthias

Thanks for reporting. Is this still an issue with current ekiga version 3.2.0?

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future.