[Spice-devel] [PATCH] mjpeg: fix libjpeg assertion

[Hans de Goede]

Hi,

On 08/01/2011 10:51 AM, Christophe Fergeau wrote:
> On Sat, Jul 30, 2011 at 08:26:04AM +0200, Hans de Goede wrote:

<snip snip>

>> The second is to define a new jpeg-rgb format where we use jpeg
>> compression straight on rgb, rather then first converting it
>> to yuv colorspace (this happens inside libjpeg, but can be
>> overridden) this will lead to a slight increase in bandwidth
>> usage, but also a great drop in cpu usage.
>
> Would this still be standard jpeg, or would this mean we invented our own
> spice-jpeg? In other words, if we change the server to do this, will the
> client be able to handle this using standard libjpeg calls, or will it need
> to be modified to be able to handle this jpeg-rgb format?

The client will need changes too. The client might need changes for the
abbreviated image stuff too, but it might work out of the box too. I'm not
sure if currently one libjpeg decompression object gets re-used or a new
one gets created each time. If there is a new one each time then the
client will need changes for the abbreviated stuff too.

> Moreover, are you
> sure it will only result in a slight increase in bandwith use at comparable
> quality?

A good question, thinking more about this, I'm likely wrong wrt the bandwidth
usage. The uncompressed data is 6 bytes / 4 pixels in YUV420 mode (YUV color
space U and V sampled once every 2x2 pixels) and 12 bytes / 4 pixels in
RGB24 mode, so switching our RGB24 data directly to libjpeg rather then
first converting it to YUV420 likely will lead to approx double bandwidth
usage :(

The reason I think that doing some different form of image compression
is potentially a good idea is because when doing high res video our CPU
usage currently is too high (it becomes the bottle neck), esp. with
flash videos.

Regards,

Hans