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

[Christophe Fergeau]

On Sat, Jul 30, 2011 at 08:26:04AM +0200, Hans de Goede wrote:
> Hmm, I assume you've tested this with odd sized images?

Yes I did. Now that you ask, I'm not sure I tested this with even sized
images since in my tests only odd sized images came up.

> The usual trick for odd sized images is to duplicate the last row /
> column to make them even sized. I could not find anything about
> this in the libjpeg documentation, so maybe libjpeg take cares
> about this itself?

I guess so since I didn't see anything about this either in libjpeg
documentation.

> 
> While on the subject of libjpeg, as this assert shows we should be
> defining our own jpeg error_exit handler, so that in case of
> an error we can simply drop the image update rather then kill
> the entire vm. This can be done by losing longjmp (ugly I know),
> see the init_libjpeg_cinfo function in:
> http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/lib/libv4lconvert/jpeg.c

Ok, I'll look into that.

> Also I think there are several opportunities for more optimization
> with our libjpeg code. The first is to not include and parse the headers
> each frame, this will save both bandwidth and CPU for parsing the
> huffman headers and generating lookup tables, see the
> "Abbreviated datastreams and multiple images" section in
> /usr/share/doc/libjpeg-turbo-devel-1.1.0/libjpeg.txt

Ok, will try to look :)

> 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? Moreover, are you
sure it will only result in a slight increase in bandwith use at comparable
quality?

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20110801/9e90611e/attachment.pgp>