Request: modifiy dynamic linking to link to libjpeg-mmx

[talllmc]

Phil,

I finally got your system installed. Depending on the word of a large global corporation, I might a job to install a zoneminder site (20 monitors), which I am going to intergrate with a MMS altert interface I have been writing, if not, well I can't see myself involved heavily with zoneminder in the future.. If I get the job I'll also take it futher by making a gentoo livecd with some other security related features.

In testing I found that zoneminder runs quiet well when linked to the CVS version of libjpeg-mmx. The default configuraiton is to link to libjpeg.so, but it can be easily changed to link to libjpeg-mmx.so http://mjpeg.sourceforege.net/

You have to compile against different headers (those found in /usr/include/libjpeg-mmx/). Other such as netbpm tools are not compatible with the older fork of this jpeg library/ (my netpbm tools are statically linked and I have libjpeg.so removed from my system!!!)

I noticed my CPU load dropped by half when using libjpeg-mmx!

When capturing 3 fps greyscale total CPU utilization is reduced to about 8% (all zm daemons) on a Pentium III Celeron (Medecino) 466Mhz. Normally it's about 20-30% with about half of the 640x480 image affected by zones.

Please make a configure time option to allow users to also link against this library in the next release. I'm supprised it worked well without any code changes because it's not meant to be a drop in replacement for libjpeg.so

Cheers,

Luke

[zoneminder]

Hi Luke,

I'm not sure who Paul is but I'll answer this one!

I hadn't even heard of libjpeg-mmx until you mentioned it. I'll add it to my to-do list so it can become a configuration option in a future version. Perhaps it would be helpful to other users if you could post exactly what you had to do to use it in the current versions.

Cheers

Phil

[talllmc]

Phil, (sorry got your name right this time!)

libjpeg-mmx.so is a gentoo package and a debian package I beleive too.

I don't know how up to date the fork from libjpeg is but I beleive it was done way back in 98 and I don't know how much they update it. I do know that the capture daemons at least worked with it, not to sure about zmu, I was getting segfault problems, but I couldn't attribute it directly to libjpeg-mmx, rather I think something in zm-1.20.0 was causing the problem (as apposed to zm-1.20.1 pre-release).

On my system I couldn't get the build scripts to link to libjpeg-mmx.so, instead they kept linking to libjpeg even at compile time. Libjpeg comes with a ldscript libjpeg-mmx.la which makes ldconfig create a link from libjpeg-mmx.so.0.68 to libjpeg.so.0.68.... so I just deleted libjpeg from my system for a short time, and recompiled zoneminder to use include's from /usr/include/jpeg-mmx - and IT WORKED! without libjeg (vanilla) on my system, I was getting events saved!

I had to roll it back to a normal configuration because many other applcations needed the old libjpeg - such as netpbm - used by zoneminder for thumbnails. Though netbpm compiles cleanly against libjpeg-mmx, but reported errors at runtime about errors in the library. It takes ages to display 100 thumbnails - so if anyone want's to port netpbm to use jpeg-mmx, that could be a subproject of zoneminder (and make it's way into the /contrib directory) in future releases.

I'll have another crack at getting zoneminder to link to libjpeg-mmx.so. I'll have to RTFM about the dynamic linker & C, and the configure script will need to make some compile time defines, which will include the code on what to link to.

We'll try this as a patch first and if nobody has problems, include it in a release down the track.

I understand that you software reads the image in RAW form, where the image comparison is done, then only create's JPEGs when saving frames.

So the only benefit of this patch (when completed) would to increase the maximum FPS the system can record at (or reduce CPU utilization) when recording frames. The motion detection code would run continue at the same speed right?

Also because the LML-33 (zoran) board captures in MJPEG, does it mean people who use them will have higher CPU utilization when doing motion detection, but less when saving JPEGs? (motion detection code has to decompress JPEGs, those compressed frames are saved in memory too then if motion is detected, those frames are saved directly to disk)...

So if this patch works you will use a little less memory and a fraction more CPU than with a zoran chip while recording to get the same job done! And less cpu for motion detection! Don't think the guys and Linux media labs will like to hear that

I haven't tested it on AMD64 architecture yet, but I will as well. There assembly code is different. Also with mplayer that supports AMD64 assembly now, I observed cpu utilization while watching a full screen DVD go from 60% to 14%. I'll let you know how much my maximum FPS goes up in my next post regarding with libjpeg-mmx. (on a very slow 466% Celeron).

Cheers,

Luke

[zoneminder]

I have been trying to link against libjpeg-mmx to check what, if any, improvement there might be. Unfortunately whilst I can get it working for regular video cameras (via bttv) I cannot get it to function with remote IP cameras that supply their images as jpegs in the first place. It barfs in decompress_onepass. Consequently I can't actually check this library out properly.

I'm concerned I've done something a bit wrong so if anyone has had any success with libjpeg-mmx I'd be interested in a step-by-step account of how you got it to work, including which version you acquired in the first place.

Phil