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

[Alon Levy]

On Mon, Aug 01, 2011 at 03:14:12PM +0200, Hans de Goede wrote:
> 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 :(
> 

Isn't the image sent compressed? i.e. size(jpeg_compress(as_rgb(image))) /
size(jpeg_compress(as_yuv(image))) != (12/4) / (6/4)

I'm not really familiar with jpeg compression, I know it's something with truncated
cosine coefficient series, so the point is that the type of the saved data is not
YUV420 nor RGB24.

Not even sure if the compression will be better or worse - I imagine an all red
image will be much better compressed starting from RGB24.

> 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
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel