[Spice-devel] libjpeg performance

[Izik Eidus]

On Mon, 12 Apr 2010 22:36:03 +0200
Alexander Larsson <alexl at redhat.com> wrote:

> On Mon, 2010-04-12 at 20:57 +0200, Alexander Larsson wrote:
> > I did some simple testing of the new mjpeg encoder.
> > Showing the youtube "will it blend - ipad" video i got quite better
> > compression (24k per frame average as opposed to 35k before), but the
> > code used a bit more cpu (9.8 msec per frame where it was 4.2 before). I
> > made a simple change in the libjpeg code to make it a bit faster, but we
> > might still be able to tweak this a bit in favour of performance rather
> > than compression if thats what we want.

Hi,

One of our competitive benchmarks we have is - showing how many guests
can run on the server and playing movies

Just a small thing before I go below, I guess you tested it on windows xp
now in windows xp video stuff was easy - we got the bitmap with strech
operation on it, meaning that if we played 320x240 original video on full
screen, we had to compress just 320x240.

However, due to "imprvoments" in windows 7, the windows media player
wont give us anymore 320x240 bitmap, but instead it will give us
1240x1024 bitmap size..., just the amount of copying this bitmap
30 times a sec into the server is huge, and then compress it is even
worse. 

So the trade off here is very interesting, 35k -> 24k is very good
result when looking at compression raito, however this whole video
streaming doesn`t look to me like it going to work anyway into anyone
in WAN.., but i will be glad if some user here will say he does use it
on wan?

The main focus of the video streaming was not to kill the lan network
when having like 50 guests on the same server...

(Btw what worry me with all this video is, that all our comptitors
 are using directX video accelration and they don`t have to decode
 this stuff again)

> 
> I just tried http://libjpeg-turbo.virtualgl.org/ which is a drop in
> replacement for libjpeg, and it bumped our performance to ~2.7 msec per
> frame (i.e. 55% faster than ffmpeg), while still keeping the better
> compression (of course the compression can be tuned by changing the
> quality setting). 

This is great results, I searched libjpeg turbo at fedora and didn`t find it,
is it a new thing and we better wait a while (at least untill fedora insert
it to the package base) before we use it?

Anyway this libjpeg stuff look promising to me, the only problem that i can think
about is that on other than x86 clients (i did see some of them) we won`t have this stuff
but again, we are anyway not having there desiarble performence yet...

> 
> By using libjpeg-turbo specific extensions (JCS_EXT_XBGR) we can get
> even better performance since we can avoid a type conversion. Didn't try
> this though.
> 


Thanks for testing this stuff