Several enhancments for LinuxMCE security and smart home functionality

[sergeyksv]

Not sure where is the proper place to discuss this issue so I'll write here. So, we have managed to build some specific system based on LinuxMCE. This system is an advanced eight cam - four terminals doorphone system and EIB management console. We have very specific requirements which doesn't require media functionality of LinuxMCE but extensively use its security and smart home controlling abilities. Built system consists of single server and four terminals. Three terminals (orbiters) are the floor doorphone EIB managing consoles and one is guard console. Every terminal is able to show up to eight cams with 25 fps per cam from analog security cameras digitized on server. Terminal also used to control three door locks and EIB devices. Each terminal has it own phone line configured using Asterisk. There are also two doorphone panels connected as phones to Asterisk through our own adapter. During implementation of this system we solve several bugs, rewrite EIB device plug-in and implement new device for video input through Video4L. Here is the brief list of changes:

1. Implemented new device to grab video from Video4L compatible devices. Current implementation of motion wrapper was EXTEMLY slow while we have requirement to show video with 25 FPS per channel. Device is optimized for simultanionius access from several orbiters with effort to take as low CPU time as possible and serve as much orbiters as possible. Device never wait frame from video device but has cached image obtained in background so it serves orbiter(s) request very quickly. It can be able to configure broadcast frames and write flv video with configured frame rate and size. So, the quad Q6600 CPU can easily to digitize 8 cams with full PAL size and 25 FPS. There also tiny web app to view video archives with videos creeated by these devices with browser playback (as this is flash video) and searching. The 1TB raid that we use for system stores 24 hours video for eight cams with history for 30 days.

2. Modify the orbiter code to support more than one core CPU with effort to show more than four cams per screen with good frame rate for all cams. Threads are used to extract JPEG frames and resize them. So on dual core CPU we able to show about 160 frames per second (eight cams each 12-15 FPS). With quad core eight cams with 25 FPS each. All these doesn't break orbiter functionality.

3. Home where the system is used has about 300 eib devices and current implementation was found very buggy for this purpose (however good source to start). We rewrite it and now it perfectly works.

4. We found and fix bug with core wich add 40 ms delay into large datapackets. With this bug even we have fast device for video digitizing broadcasting ability of server with good image quality was limited heavly. Now core able to provide data for 4 terminals, i.e. 640 fps without serious CPU load and with pretty high stability.

We make other modifications but they are rather custom and not think need to be shared. We willing to publish somehow these enhancments but I want to be sure that they reach its destination. I.e. they will be somehow integrated into LinuxMCE in case they will be found useful. So I search the person(s) who will be able to assist me with this. Once we start (one year ago) we found entire build process and even proper location for latest code very confusing and I not want to spend lot of time investigating this issue again.

[hari]

wow, very cool. Thank you very much for willing to contribute back. Do you use irc? Visit #linuxmce-devel on freenode. We'll assist in integrating this properly.

br, Hari

[tricky_dicky]

I second Hari, that is very cool. Well done guys.

Always interesting to read how people take a product and customize it for their own purpose. Sounds like you did some real low level coding and improvements.

Which door phones did you use?

Rich

[sergeyksv]

We use analog doorphone panels maid in Ukraine (http://www.domofon.ru/default.asp?alias=duplex_request_blocks&itemID=276&itemType=card) through custom maid adapter (just audio level compensation). For the Asterisk its appears as phone which is picked up when somebody makes a call. Similar product is http://www.homephone.com/products/28bf/28bf.htm, though is is more complex as it emulates call from telephone station.
However this part was easy, the hard part is 8 cams full PAL 25 fps display. Probably this is paranoya but the customer willing to see all eight cams when somebody uses doorbell. Anyway this part of LinuxMCE was very slow even for one cam (~10 FPS max).

[elspic]

I'm definitely interested in your improvements to motion. 8 cams at 25fps is pretty cool. -elspic

[jondecker76]

Yes, all of you changes sound like they would be excellent improvements to LinuxMCE! Any number of us on IRC freenode linuxmce-devel would be willing to help you get your changes in. You may also visit svn.linuxmce.org and submit a patch in a trac ticket. Thank you very much for your efforts and willingness to share!

[tricky_dicky]

That's great, thank you.

I would also love to see that many cameras working at 25fps, impressive work indeed.

What hardware is this system running on?

Rich

[sergeyksv]

Ok, as I will have few hours of free time I will come to mentioned IRC channel. Right now we have our own svn tree of linuxmce code which was splitted from official sources of version 710 with several patches from other svn trees we found on that time (official code has a few bugs, with fixes found in svn trees right after release date). The primary concern for me is not the pataches against code but rather database synchronization which required for example for new device.
As for server hardware this is Q6600 CPU, 4 GB RAM (actually ram is not an issue at all), 150 GB 10K RPM WD Raptor for system and orbiter filesystems, 2x1TB 7.2K RPM joined as 1 TB RAID 1 for video. Server has also additional COM ports for EIB and our own controllers and Digium telephony adapter.
For video capture we initially use 2xPCI 4XBT878 no name adapters. But later found that with full PAL size and 25 FPS PCI can handle not more than 4xBT878 chips in theory because of PCI throughput limitation. In practice even with just four cams (chips) and the minimal possible color resolution (YUV420) on different mainboards the system might work or not work as the PCI usage was on edge. So this adapters was replaced to PCI-E version PV-981 (http://store.bluecherry.net/4_port_video_capture_card_120FPS_Real_time_p/pv-981.htm) and they work pretty fine and stable. Up to this date server work about four months without rebooting.

[jhammond]

I'd love to see your motion patches and stability patches especially as I'm using one of the bluecherry cards myself and would definitely like to have a little improvement in that area.

Can we get  sergeyksv's stuff posted somewhere, Trac maybe?

[schaferj]

sergeyksv,

These are terrific improvements and thank you very much for giving back to the community.

joseph

[PlatypusPedersen]

Exellent enhancements, very nice of you to share them, kudos.
I'm very curious how these improvements are moving along into 8.10.

[elspic]

I was wondering the same thing today. Hopefully at least some of them have made it in.
-elspic

[Marie.O]

I have not seen any patches arriving in trac.

sergeyksv,

would you mind providing those patches, as well as device templates (using the devicetemplate exporter) as trac tickets, so we could integrate them into the LinuxMCE codebase.

Thank you.

[colinjones]

He hasn't been on the forums since April 17, so I have emailed him directly asking if he can drop by.