jpeg SIMD (MMX) success!

[watou]

I was just looking at this document:

http://libjpeg-turbo.virtualgl.org/About/Performance

and it occurred to me that maybe certain video inputs use different JPEG code paths than other video inputs? In my case, my frames come from uvcvideo underlying V4L2, and maybe decompression is done in the driver with un-replaceable code?

Note that this is random speculation, but I'm grasping at straws. Does anyone here have deeper knowledge of cases where libjpeg[-turbo] is simply used differently with certain sources or configurations?

[knight-of-ni]

That's a good point about different jpeg code paths... If you are using a capture device with a V4L driver that natively supports the card's hardware capabilities, then I would tend to agree with your speculation.

You might want to send dcommander a message through the Sourceforge project website to see what his thoughts are. He has actively responded to a previous comment of mine.

For comparison, here is a system I'm running now that has significant cpu load reduction when using libjpeg-turbo:

• 64 bit CentOS 5.5
  Opteron 290 cpu's (i.e. has sse3 support)
  Zoneminder, libjpeg-turbo, & ffmpeg compiled from source
  Video devices are all IP based (i.e. no v4l2 devices)

As I hinted at earlier, I'm working on a repairing & upgrading a second system that will more closely match what you are trying to do. I apologize for my slowness, but I've got near back-to-back out of town trips beginning tonight, which spans over the next 1.5 weeks. I'll work on the Ubuntu machine when I can and then post my results with the libjpeg-turbo library.

In the meantime, have you have got something IP based that can stream video to zoneminder? That could help confirm or deny whether or not the v4l driver can affect things.

[knight-of-ni]

Alright, I had a moment of opportunity so I ran the same test described in the libjpeg-turbo readme file.

The following results were run on a freshly built 64bit Ubuntu 10.04 System which uses an Athlon 3300+ cpu:

Code: Select all

dvr@ubuntu-dvr:~$ export LD_LIBRARY_PATH=""
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m1.129s
user	0m0.720s
sys	0m0.050s
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m1.067s
user	0m0.770s
sys	0m0.050s
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m1.099s
user	0m0.750s
sys	0m0.050s
dvr@ubuntu-dvr:~$ export LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m0.741s
user	0m0.440s
sys	0m0.100s
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m0.723s
user	0m0.430s
sys	0m0.090s
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m0.734s
user	0m0.390s
sys	0m0.100s
dvr@ubuntu-dvr:~$ 

For consistency, I ran the test three times w/o libjpeg-turbo and three times with libjpeg-turbo.

Averaging each set of real time values and then dividing gives about a ~67% increase in performance when using the libjpeg-turbo library (if I did my math right).

Note that I compiled my own libjpej-turbo .deb package from source for these tests. I'll run the test again using one of the prebuilt .deb packages from the project website.

[watou]

Thanks for showing how much faster libjpeg-turbo can be at compression. Obviously, any uncompressed frames that ZM has to write (to disk or a stream) will benefit nicely from using libjpeg-turbo over libjpeg.

But I think that it could also help in decompressing raw frames from JPEG (i.e., working in the other direction). For configurations that use network cameras on modect sources, I imagine ZM has to decompress every frame in order to do its analysis, which, without a hardware assist of some sort, could be a real dog.

In my setup I have V4L-based webcams, which I think deliver uncompressed frames into ZM, thereby sidestepping a performance hit that network-based cameras would incur.

Is this a correct understanding?

[knight-of-ni]

After removing the custom .deb package, I downloaded and installed libjpeg-turbo_1.0.0_amd64.deb from the Sourceforge project website. Here are the results:

Code: Select all

dvr@ubuntu-dvr:~$ export LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m0.726s
user	0m0.410s
sys	0m0.030s
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m0.701s
user	0m0.420s
sys	0m0.060s
dvr@ubuntu-dvr:~$ time cjpeg test.bmp > test_2.jpg

real	0m0.707s
user	0m0.390s
sys	0m0.130s
dvr@ubuntu-dvr:~$ 

As you can see I get about the same improvement.
Let me know if you want me to run any other tests.

[watou]

Let me know if you want me to run any other tests.

Can you test decompression (as opposed to compression) using the two different libraries?

[knight-of-ni]

Yes, I sure can.
Here are my results using djpeg, rather than cjpeg:

Code: Select all

dvr@ubuntu-dvr:~$ export LD_LIBRARY_PATH=""
dvr@ubuntu-dvr:~$ time djpeg test.jpg > test_2.bmp

real	0m0.760s
user	0m0.420s
sys	0m0.120s
dvr@ubuntu-dvr:~$ time djpeg test.jpg > test_2.bmp

real	0m0.697s
user	0m0.320s
sys	0m0.120s
dvr@ubuntu-dvr:~$ time djpeg test.jpg > test_2.bmp

real	0m0.703s
user	0m0.410s
sys	0m0.100s
dvr@ubuntu-dvr:~$ export LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64
dvr@ubuntu-dvr:~$ time djpeg test.jpg > test_2.bmp

real	0m0.456s
user	0m0.150s
sys	0m0.110s
dvr@ubuntu-dvr:~$ time djpeg test.jpg > test_2.bmp

real	0m0.467s
user	0m0.190s
sys	0m0.090s
dvr@ubuntu-dvr:~$ time djpeg test.jpg > test_2.bmp

real	0m0.437s
user	0m0.170s
sys	0m0.140s
dvr@ubuntu-dvr:~$ 

[watou]

Thank you!

Huge improvement for people whose cameras push compressed frames into ZM for analysis.

Anyone know if this applies to Video4Linux-based cameras?

[bobbozzo]

Thank you!

Huge improvement for people whose cameras push compressed frames into ZM for analysis.

Anyone know if this applies to Video4Linux-based cameras?

VFL cameras don't create JPEGs, but ZM will still create JPEGs when recording or when streaming to a browser, so it will help in those cases.

To anyone not sure that the new libraries are being used, you can export the library path in /etc/profile


Bob

[knight-of-ni]

Understand that exporting your library path in /etc/profile will override the libjpeg library for the entire system, not just Zoneminder.

The libjpeg-turbo library is not 100% compatible with everything (yet?), which is why the documentation recommends exporting the library for one application at a time.

I found out for myself a while back that my 64bit CentOS system acted strangely with the entire system running on the libjpeg-turbo library. Your mileage may vary.

[Pyrrhic]

Dear Colleagues:

I too have faced speed issues (running Ubuntu 10.10 Desktop, dual core processors, Pico2000 type cards). David's library find dropped my CPU usage from 100% to the 30s, some other tweaks dropped them lower. I have also found that using Chrome, not FireFox makes a very big difference in responsiveness for the console and for single cam viewing.

Best,

P.

[redxiii]

i found a PPA for ubuntu to use. i like to use those since it will keep the software updated. https://launchpad.net/~ikoinoba/+archive/ppa/

after installing libjpeg-turbo_1.1.0-0~ppa1_amd64.deb i notice that it didn't use the lib64 directory, so i added

export LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib:$LD_LIBRARY_PATH

to the /etc/init.d/zoneminder startup script, underneath the `command="$ZM_PATH_BIN/zmpkg.pl"` line

i verified zoneminder is using the turbo libraries:

Code: Select all

$ sudo lsof |grep libjpeg.so.62.0.0
zmc       7851   www-data  mem       REG              252,2   305264    3407877 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
zma       7853   www-data  mem       REG              252,2   305264    3407877 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
zmc       7855   www-data  mem       REG              252,2   305264    3407877 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
zma       7857   www-data  mem       REG              252,2   305264    3407877 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
nph-zms   8111   www-data  mem       REG              252,2   305264    3407877 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
nph-zms   8112   www-data  mem       REG              252,2   305264    3407877 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
$ 

load, i'm not sure has been reduced. maybe because it was already low to begin with? about 1.5 on quad core with only 2 monitors so far. on the same machine we have a montage open 24/7 for the two streams. should there be a noticeable reduction still?

[ridwan]

hi, all..

i have a few camera used to monitor, and it's controlled by zoneminder application, but the zoneminder application service occasionally do not work properly or failed to start the services, any suggestion what should i do?

[redxiii]

you should start a new topic for that, this topic is specifically regarding libjpegturbo libraries

[keda]

I tried the guides above installing libjpeg-turbo and it seems to have installed just fine. The problem is that I cannot get ZM to use the new library even with the export LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib:$LD_LIBRARY_PATH command in /etc/init.d/zoneminder or running it before executing ZM.

An sudo lsof |grep libjpeg gives me this(yes I am running Rasp Pi):
zmc 16934 www-data mem REG 179,2 209436 32358 /usr/lib/arm-linux-gnueabihf/libjpeg.so.8.4.0
zma 16939 www-data mem REG 179,2 209436 32358 /usr/lib/arm-linux-gnueabihf/libjpeg.so.8.4.0

How can I get Zoneminder to use the libjpeg-turbo libs?

Thanks,
Keda