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
pgpV1mzkQPlEk.pgp
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
