ZoneMinder Forums

Hi again guys,
My ZM box is up & running with one cam so far so good. Will be adding another 7 shortly.

My only issue is that the camera will only work when 'Capture Palette' is set to BGR24, RGB565, RGB555 & Grey. BGR32 will display an image OK but the colours are out of wack. RGB24 just shows a broken picture icon.
I have read in the standard docs that ZM only natively supports RGB24 & Grey. Any other palette settings will require more processing & thus degrade performance.

I have compiled ZM with: ./configure --with-webdir=/var/www/html/zm --with-cgidir=/var/www/cgi-bin --with-ffmpeg=/usr/local/share/ffmpeg CFLAGS="-g -O3 -march=prescott -mtune=prescott" CXXFLAGS="-g -O3 -march=prescott -mtune=prescott" --enable-mmap CPPFLAGS="-D__STDC_CONSTANT_MACROS"

To tune it to my P4 Prescott. I have also installed the libjpeg-turbo & ZM seems to be using it:

[root@zm1 ~]# lsof |grep libjpeg.so.62.0.0
httpd 2339 root mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
zmc 2526 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4643 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4644 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4645 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4646 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4647 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4648 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4649 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4650 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 28752 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
zmc 29060 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0

I have just found mastertheknife's excellent works here: http://www.zoneminder.com/forums/viewto ... ilit=BGR24

My question is is the above palette incompatibility expected due to me using libjpeg-turbo or is there something wrong. Maybe I didn't comple ZM properly agains the libjpeg-turbo libraries ??
There is also a comment by graphicw that the bt878a card don't support RGB24. But I think mastertheknife said he was using RGB24 with bt878a ? Or maybe that was with his patch ? I'm looking forward to trying that out - is it in the 1.25 beta ?

Anyway could someone clear this up for me either way - is this correct behaviour or not?


Thanks,

Mike.

Hello there

I'm also using a Kodicom 8800 clone and what you heard is perfectly correct - The BT878 (or the driver?) do not support RGB24. You can even confirm this by running: This should display all the capture palettes the device supports, and you will see RGB24 (RGB3) is not listed, but just BGR24 (BGR3): Attempts to use RGB24 will result in an "Invalid argument" error.

ZM only supports 8bit grayscale and RGB24 natively. ZM is converting any other format (e.g. BGR24) into RGB24.
This is one of the reasons i created the patch - to add native support for BGR24 in order to remove the performance penalty of converting BGR24 into RGB24.
Take a look at this zmc profiling log for example, you will see that the BGR->RGB conversion accounts for around 50% of zmc's cpu usage!: http://pastebin.com/3ZMfhmmA
In my attempt to add native support for BGR24, i faced a problem. libjpeg only supports grayscale and RGB24 input & output. Fortunately, libjpeg-turbo has colorspace extensions that add support for BGR24, RGBA, BGRA, ABGR, ARGB input&output (the last four formats are 32bit RGB formats)

About my patch, I'd like to see it in 1.25.0 and even contacted Phil about it. At this moment, i'm working on version 2 of the patch, which includes another SSE2 algorithm (for the alarmed pixels motion detection), support for JPEG\MJPEG capture palettes and some other tweaks\code cleanups. This is all still very far away though and will probably take me a month to plan, code and test.
Installation of the current version is very simple, its just like installing ZM from source with 2 additional steps, the first is patching the source and the second is running an SQL statement to modify the database.

mastertheknife.

mastertheknife wrote:Hello there

I'm also using a Kodicom 8800 clone and what you heard is perfectly correct - The BT878 (or the driver?) do not support RGB24. You can even confirm this by running:

Code: Select all

zmu -q -v -d /dev/video0

This should display all the capture palettes the device supports, and you will see RGB24 (RGB3) is not listed, but just BGR24 (BGR3):

Code: Select all

  Formats:
    8 bpp, gray (GREY)
    8 bpp, dithered color (HI24)
    15 bpp RGB, le (RGBO)
    15 bpp RGB, be (RGBQ)
    16 bpp RGB, le (RGBP)
    16 bpp RGB, be (RGBR)
    24 bpp RGB, le (BGR3)
    32 bpp RGB, le (BGR4)
    32 bpp RGB, be (RGB4)
    4:2:2, packed, YUYV (YUYV)
    4:2:2, packed, YUYV (YUYV)
    4:2:2, packed, UYVY (UYVY)
    4:2:2, planar, Y-Cb-Cr (422P)
    4:2:0, planar, Y-Cb-Cr (YU12)
    4:2:0, planar, Y-Cr-Cb (YV12)
    4:1:1, planar, Y-Cb-Cr (411P)
    4:1:0, planar, Y-Cb-Cr (YUV9)
    4:1:0, planar, Y-Cr-Cb (YVU9)

Attempts to use RGB24 will result in an "Invalid argument" error.

ZM only supports 8bit grayscale and RGB24 natively. ZM is converting any other format (e.g. BGR24) into RGB24.
This is one of the reasons i created the patch - to add native support for BGR24 in order to remove the performance penalty of converting BGR24 into RGB24.
Take a look at this zmc profiling log for example, you will see that the BGR->RGB conversion accounts for around 50% of zmc's cpu usage!: http://pastebin.com/3ZMfhmmA
In my attempt to add native support for BGR24, i faced a problem. libjpeg only supports grayscale and RGB24 input & output. Fortunately, libjpeg-turbo has colorspace extensions that add support for BGR24, RGBA, BGRA, ABGR, ARGB input&output (the last four formats are 32bit RGB formats)

About my patch, I'd like to see it in 1.25.0 and even contacted Phil about it. At this moment, i'm working on version 2 of the patch, which includes another SSE2 algorithm (for the alarmed pixels motion detection), support for JPEG\MJPEG capture palettes and some other tweaks\code cleanups. This is all still very far away though and will probably take me a month to plan, code and test.
Installation of the current version is very simple, its just like installing ZM from source with 2 additional steps, the first is patching the source and the second is running an SQL statement to modify the database.

mastertheknife.

Hi Kfir,
Ahh right that clears that up then. I guess it must be the driver as this document http://www.conexant.com/servlets/Downlo ... 16&revid=1 seems to suggest that the Fusion 878A chips do support RGB24. Funny the doc makes no mention of BGR24 - or BGR anything?
Interestingly at the top of that document it also says: "Selectable pixel density: 8, 16, 24, and 32 bits per pixel". I wonder, as if my maths is correct 16 bits is 2 bytes which will fit 8 times into the 16 byte XMM registers you spoke about. I dunno, I suppose to take advantage of using 16bit colour would mean hacking about with the bt878 driver or maybe the Kodicom card is not acutually electrically designed to be allow selecting 16bit pixel density ? - am I correct in this line of thought ??

I will try your patch out later today hopefully. Makes total sense to use the MMX & SSE2 extensions to speed things up.

Oh one last thing - what does 'autoreconf' do ? You mention it as an optional step: "Rebuild the configure script and the makefiles to be fully compatible with your machine". Does this imply it does the same as 'CFLAGS="-g -O3 -march=prescott -mtune=prescott" CXXFLAGS="-g -O3 -march=prescott -mtune=prescott" ' that I used to optimise ZM to my P4 Prescott core ?

Thanks again,

Mike.

m1ke wrote: Hi Kfir,
Ahh right that clears that up then. I guess it must be the driver as this document http://www.conexant.com/servlets/Downlo ... 16&revid=1 seems to suggest that the Fusion 878A chips do support RGB24. Funny the doc makes no mention of BGR24 - or BGR anything?
Interestingly at the top of that document it also says: "Selectable pixel density: 8, 16, 24, and 32 bits per pixel". I wonder, as if my maths is correct 16 bits is 2 bytes which will fit 8 times into the 16 byte XMM registers you spoke about. I dunno, I suppose to take advantage of using 16bit colour would mean hacking about with the bt878 driver or maybe the Kodicom card is not acutually electrically designed to be allow selecting 16bit pixel density ? - am I correct in this line of thought ??

I will try your patch out later today hopefully. Makes total sense to use the MMX & SSE2 extensions to speed things up.

Oh one last thing - what does 'autoreconf' do ? You mention it as an optional step: "Rebuild the configure script and the makefiles to be fully compatible with your machine". Does this imply it does the same as 'CFLAGS="-g -O3 -march=prescott -mtune=prescott" CXXFLAGS="-g -O3 -march=prescott -mtune=prescott" ' that I used to optimise ZM to my P4 Prescott core ?

Thanks again,

Mike.

Hi,
You are probably correct. The BT878 definitely supports RGB24, its just missing in the driver for some reason. By the way, the reason you don't see BGR mentioned is because byte swapping is used to control the subpixel order:

[3] RW 0 WSWAP_ODD WordSwap Odd Field. A value of 1 enables word swapping of data entering the FIFO. W2[31:16] is swapped with W0[15:0].
[2] RW 0 WSWAP_EVEN WordSwap Even Field. A value of 1 enables word swapping of data entering the FIFO. W2[31:16] is swapped with W0[15:0].
[1] RW 0 BSWAP_ODD ByteSwap Odd Field. A value of 1 enables byte swapping of data entering the FIFO. B3[31:24] is swapped with B2[23:16], and B1[15:8] is swapped with B0[7:0].
[0] RW 0 BSWAP_EVEN ByteSwap Even Field. A value of 1 enables byte swapping of data entering the FIFO. B3[31:24] swapped

Regarding 16bit RGB. This is lower quality and has too many formats, e.g. 4-4-4, 4-5-4, 5-4-4, 5-5-5 (how many bits for each channel (red\green\blue)) and just doesn't worth the time. 4 RGB32 pixels or 16 grayscale pixels fit nicely into an XMM register.
Although in theory SSE2 code should be much faster because it works on more data at given time, its usually just 2-4x faster and this is mostly because SSE instructions usually take up more processor cycles than normal instructions. e.g. the x86\x86-64 instruction add takes about 1 processor cycle, but paddd (SSE add) takes 4-6 processor cycles.

About the autoreconf, this just rebuilds the ./configure script and the makefiles. Not really required to run it but it does no harm. It doesn't call ./configure for you with the parameters you supplied (e.g. the CFLAGS), thats something you do. It just creates the configure script for you.

mastertheknife

Hi,

After reading docs, i went ahead and added RGB24 support to the driver, recompiled it and reloaded it. After setting ZM to RGB24 and firing up ZM, i realized why RGB24 is not available in the driver.

The document assumes big-endian, but our processors are little endian, which is why RGB24 for example, is actually BGR24 on our systems.
To get RGB24, we need to activate the word swapping and byte swapping features.
So:
B-G-R-B (the last B is the beginning of the next pixel)
After word swap becomes:
R-B-B-G
After byte swap becomes:
B-R-G-B
Which is clearly not what we want:
R-G-B-R

But for a format like RGB32 (which is BGR32 on our processors because its little-endian), to get RGB32 on little endian processor, those swap features work well:
So:
B-G-R-A
After the word swap becomes:
R-A-B-G
After the byte swap becomes:
A-R-G-B
Which is the format that V4L2 RGB32 mode wants.


The bt878 simply doesn't have any way to change BGR24 into RGB24 (or vice versa) that produces the expected result.

mastertheknife.

Hi Kfir,
Just tried to make ZM after applying your patch. When I do 'make' I get :

zm_mem_utils.h: In function âvoid* zm_mallocaligned(unsigned int, size_t)â:
zm_mem_utils.h:29: warning: dereferencing type-punned pointer will break strict-aliasing rules
zm_ffmpeg_camera.cpp: In member function âvirtual int FfmpegCamera::Capture(Image&)â:
zm_ffmpeg_camera.cpp:219: error: âSWS_CPU_CAPS_SSE2â was not declared in this scope
make[2]: *** [zm_ffmpeg_camera.o] Error 1
make[2]: Leaving directory `/root/ZoneMinder-1.24.4/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/ZoneMinder-1.24.4'
make: *** [all] Error 2

This is my config command:
./configure --with-webdir=/var/www/html/zm --with-cgidir=/var/www/cgi-bin --with-ffmpeg=/usr/local/share/ffmpeg CFLAGS="-g -O3 -march=prescott -mtune=prescott" CXXFLAGS="-g -O3 -march=prescott -mtune=prescott" --enable-mmap --enable-debug=yes --enable-crashtrace=yes CPPFLAGS="-D__STDC_CONSTANT_MACROS -msse2"

What have I done wrong ?

I did do the mysql command before I ran make - but that shouldn't make any difference I guess.
'ALTER TABLE `Monitors` ADD `Colours` TINYINT UNSIGNED NOT NULL DEFAULT '1' AFTER `Height`; '


Thanks,

Mike.

Hi,

You didn't do anything wrong, its all good. That error comes from swscale which is a part of ffmpeg.
Its strange that its not defined, but a quick workaround is to add this to the bottom of zm_ffmpeg.h, before the last #endif.
mastertheknife.

mastertheknife wrote:Hi,

You didn't do anything wrong, its all good. That error comes from swscale which is a part of ffmpeg.
Its strange that its not defined, but a quick workaround is to add this to the bottom of zm_ffmpeg.h, before the last #endif.

Code: Select all

#define SWS_CPU_CAPS_SSE2 0x02000000

mastertheknife.

Ok, make went OK & make install worked ok too. I stopped ZM first before doing make install & restarted - I got this:

[root@zm1 ZoneMinder-1.24.4]# service zm start
Starting ZoneMinder: No option 'ZM_LOCAL_BGR_INVERT' found, removing at /usr/lib/perl5/site_perl/5.8.8/ZoneMinder/ConfigAdmin.pm line 89.
No option 'ZM_Y_IMAGE_DELTAS' found, removing at /usr/lib/perl5/site_perl/5.8.8/ZoneMinder/ConfigAdmin.pm line 89.

A further restart & no further messages.

After that though RGB24, BGR24, RGB32, BGR32, 24 or 32 bit colour - none of these work just a blank (white) page - not even a broken pic symbol.
The only colour settings that seem to work OK are RGB555, RGB565 & some of the others with a * next to them - using 24 bit colour target.

How come none of the native palettes work?

Cheers,

Mike.

Hi, those perl warnings are perfectly normal and gone after the first time.

RGB24 - doesnt work on the bt878.
BGR24, RGB32 and BGR32 - all of these require libjpeg-turbo now (because they don't convert into RGB24 anymore)
All others - convert into the target colourspace, which is by default RGB24 for 24bit, RGB32 for 32bit and is 8bit grayscale for grayscale.
Are you sure libjpeg-turbo is loaded and not libjpeg?
Also make sure to compile against libjpeg-turbo's header files (libjpeg.h) and not standard libjpeg header files.
if libjpeg-turbo doesn't fix it, please paste the errors from the system log.

mastertheknife.

mastertheknife wrote:Hi, those perl warnings are perfectly normal and gone after the first time.

RGB24 - doesnt work on the bt878.
BGR24, RGB32 and BGR32 - all of these require libjpeg-turbo now (because they don't convert into RGB24 anymore)
All others - convert into the target colourspace, which is by default RGB24 for 24bit, RGB32 for 32bit and is 8bit grayscale for grayscale.
Are you sure libjpeg-turbo is loaded and not libjpeg?
Also make sure to compile against libjpeg-turbo's header files (libjpeg.h) and not standard libjpeg header files.
if libjpeg-turbo doesn't fix it, please paste the errors from the system log.

mastertheknife.

Hi again,
How can I make sure I build against libjpeg-turbo ? If I do 'lsof |grep libjpeg.so.62.0.0' & it is using libjpeg-turbo I guess this means I have built against libjpeg-turbo ?
I've not got access to the box to test for now but will have shortly.
Also how do I make sure I compile against libjpeg-turbo's header files (libjpeg.h) and not standard libjpeg header files ?

I'm not used to building stuff from source...

Thanks,

Mike.

Hi,

What are the errors in the system log?
If its something like "Bogus input colorspace" - libjpeg-turbo is not loaded and standard libjpeg is loaded instead.
If its something like "libjpeg-turbo is required for blah blah" - ZM wasn't compiled against libjpeg.h from libjpeg-turbo. In that case, i think adding the include path to the CPPFLAGS should do it, e.g. -I/opt/libjpeg-turbo/include

mastertheknife.

mastertheknife wrote:Hi,

What are the errors in the system log?
If its something like "Bogus input colorspace" - libjpeg-turbo is not loaded and standard libjpeg is loaded instead.
If its something like "libjpeg-turbo is required for blah blah" - ZM wasn't compiled against libjpeg.h from libjpeg-turbo. In that case, i think adding the include path to the CPPFLAGS should do it, e.g. -I/opt/libjpeg-turbo/include

mastertheknife.

Right got access again now.
So the below would mean that I didn't comple ZM against 'libjpeg.h'.

[root@zm1 zm]# less zmdc.log
Jun 28 13:11:36 zm1 zms[13420]: ERR [libjpeg-turbo is required for JPEG encoding directly from RGB32 source]
Jun 28 13:11:36 zm1 zms[13420]: ERR [Unable to send stream frame: Resource temporarily unavailable]
Jun 28 13:11:36 zm1 zms[13420]: ERR [libjpeg-turbo is required for JPEG encoding directly from RGB32 source]
Jun 28 13:11:36 zm1 zms[13420]: ERR [Terminating, last frame sent time 1309263096.906540 secs more than maximum of 10.000000]

And the below would mean that libjpeg-turbo is loaded & being used by ZM :

[root@zm1 include]# lsof |grep libjpeg.so.62.0.0
httpd 2339 root mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4643 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4644 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4645 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4646 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4647 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4648 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4649 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 4650 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 10817 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
zmc 10867 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
zmc 13405 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 28752 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0
httpd 29749 apache mem REG 8,3 269028 74973204 /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0

Right ... So I just need to:

#service zm stop
cd to zm source dir,
#autoconf - do I need to do this again ?
./configure --with-webdir=/var/www/html/zm --with-cgidir=/var/www/cgi-bin --with-ffmpeg=/usr/local/share/ffmpeg CFLAGS="-g -O3 -march=prescott -mtune=prescott" CXXFLAGS="-g -O3 -march=prescott -mtune=prescott" --enable-mmap --enable-debug=yes --enable-crashtrace=yes CPPFLAGS="-D__STDC_CONSTANT_MACROS -msse2 -I/opt/libjpeg-turbo/include"

#make
#make install
#service zm start

Test & see if it works ...

Am I correct ?

Many thanks,

Mike.

Yes. Need to run that ./configure line, assuming the correct path for libjpeg-turbo's header files is /opt/libjpeg-turbo/include.

mastertheknife.

mastertheknife wrote:Yes, assuming the correct path for libjpeg-turbo's header files is /opt/libjpeg-turbo/include.

mastertheknife.

Hi Kfir,
OK it's working now

I used the configure command I posted above with the -I/opt/libjpeg-turbo/include appended to CPPFLAGS.

RGB32/BGR32 with 32 bit colour is working just fine as are most of the other settings apart from RGB24 of course. What colour settings should be most efficient on my Kondicom 8800 clone ? I know you have the same card. By default it was set to BGR32 / 32 bit colour - can I assume this is the most efficient setting on my Prescott P4 (which doesn't have SSE3 support, just MMX, SSE & SSE2).

Also in future - how would I go about updating ZM to the latest version ? - what commands would I need to run to uninstall the patch & associated changes? Or how would I update the patch to your newer versions as they appear (to avoid conflicts & things breaking) ? Just thinking about future maintenance really.

Thanks again,

Mike.

Seems so far for my Prescott P4 that BGR24 with 24 bit colour is best as it uses slightly less CPU & RAM than BGR/RGB32 & 32bit colour.

Not sure if it's just me but perhaps the picture looks better now. Will like to see it in the night when the IR lights fire up - there was a small bit of coloured 'buzz' arround the edges of objects. Now its running native BGR24 intresting to see if thats still there.

How do I enable ZM_CPU_EXTENSIONS, ZM_CPU_EXTENSIONS & disable COLOUR_JPEG_FILES ? I can't find these options in the 'options' menu. Do I place these in /usr/local/etc/zm.conf & restart zm or something ??

Mike.