[Spice-devel] libjpeg performance

[Alexander Larsson]

On Tue, 2010-04-13 at 08:04 +0300, Izik Eidus wrote:
> 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.

Yes, this was an XP guest. Not full screen though, it was just an
in-window youtube video, as i was just comparing relative not absolute
performance.

> 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. 

Yeah, thats kinda sucky.

> 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?

There is a "quality" knob in the jpeg encoder which we can set from 0 to
100 which affects quality and final size. I just set it to 70, but we
can tweak it if we want higher quality for WAN work, etc.

> (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)

Yes, obviously we have to do this at some point.

> > 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?

I don't really know, we'll have to look into 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...

Client side shouldn't be as much problem. We only do one client per
client, and decompression is cheaper than compression.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's an oversexed zombie barbarian who hangs with the wrong crowd. She's an 
artistic punk queen of the dead with a birthmark shaped like Liberty's torch. 
They fight crime!