#zoneminder

morning.

morning bhuddah

morny peeps

say ive a new h264 cam

escamp qd900wifi

fullly configurable in iceweasel

it's got mjpg streams ofc

but it has h264 which i can see in vlc as rstp://<ip>:554/12

but i cant see to get zm (1.2.5 older version) to see that

any pointers?

am i going to have to finally upgrade zm ?

hey jzaw

hey bhuddah :)

i've never used a zm so old.

you could do a test install first. before you upgrade everything.

nice morning here ... great contrasts on the cam

:)

yeah well this version works well (enough) on the usb mjpg streams so ... if it aint broke dont fix

11 usb cams ... finally going to replace them with decent-ish ip cams

as you know ive used zm for years now ... long before this current boost of dev that's been lovely to watch occuring

just havent had the chance / incentive to upgrade yet :)

i guess ill have to spin up a new VM :)

mhm

but if you can still delay upgrading it's probably worth waiting for the vidoestorage to finally get done :)

that will be the single most important upgrade in a lot of time.

ic0n: thanks for the merge

useful for cleaning up git branches http://railsware.com/blog/2014/08/11/git-housek...

Is there a long term plan to solve the connection limit issue? The video efforts would seem to not do so (but perhaps more firmly cement it as an issue)?

I read the multiple domain discussion (which could at least be a workaround, albiet only if a cooperative dns admin is involved), and the mention of websockets which might help with streamed stills but doesn't seem to be a video solution?

I don't think anyone is actively working on it, but I think the way that it will go is a persistent zms daemon listening on a different port for each monitor.

Does that get around the domain limit, just being on a different port? That sounds actually easy if so, much like the dns name trick but controllable in apache.

Though it may not play well with people running nat on home firewalls for outside access.

Unfortunately, using a different tcpip port for each monitor would be extremely firewall-unfriendly. Having to port forward for each camera would not be practical for many people. We should probably look at how other products and see how they do it.

My guess is that for video they combine the videos into one stream, at least that seems the most generic approach. For the current non-video feed I've been experimenting this morning with non-continuous jpg's, i.e.

have them pulled from the client rather than pushed as a stream. It won't be fast, but I just did 7 cameras at 5 fps with no issues in chrome (i.e. one of those cameras had to wait for the others).

But that doesn't address real video of course.

something about the jpgs this vivotek creates that zm doesn't like, causing it to crash that zmc

Yeah I agree, there are lots of methods we could look into. I could run a wireshark session on some of the products we use at my $dayjob and very quickly see how multiple streams are transmitted. I'm pretty sure they multiplex it into a single stream.

I also wonder if writing a browser plugin could get us around the limitation in the browser

Since the issue can currently be worked around in Firefox, this particular issue has not been a priority

That isn't to say we don't want to fix it.... always comes down to having time

Hey knnniggett: how goes your adventures in raspberrypi land? I was having trouble with mine, but fixed it yesterday by increasing the ram for video. I must have turned it down to free up ram for apps.

hmm, same camera and settings on another server work fine. Time to look at the libs

does zmc actually crash? We should be able to fix that.

Jul 29 15:10:40 dobby zmdc[3727]: INF ['zmc -m 60' crashed, signal 6]

the server has 20+ other cameras working fine, so it's an unusual problem. will keep worrying away at it

Crank up debug...

actually... shared memory, that's a though

somebody else rebuilt the server after a splat recently

!shared

If you haven't already changed the shared memory on the server, Zoneminder may not be able to handle images larger than 320x240. If the Source entry for your new monitor is coloured in red and no picture shows when you do the above, you will probably have to change the shared memory.

To fix for this session, paste the following into a root shell then restart zoneminder:

echo 134217728 >/proc/sys/kernel/shmall

echo 134217728 >/proc/sys/kernel/shmmax

(Note this will only persist until your next reboot. To make permanent, you will need to edit /etc/sysctl.conf - see FAQ for info (!faq))

knnniggett - yes, firefox works, but I've been experimenting with smaller devices like tablets (I want something to wall mount) and it is really tough to find anything that can do montage correctly.

One advantage of pull (it has some real disadvantages in terms of performance) is that it could be self limiting -- if it sees it is running faster than images arive it could slow down the rate of pull.

single image montage should be fairly easy to implement.

is there anything in html5 that will mux feeds together in a clever way?

digdilem: Not that I have seen. The closest is the websockets feature, which let's you set up an arbitrary stream to a server, but you would need to change zms (or make a new one) so it could be a websockets server.

:(

Then have something client side to demux the streams and feed it into a video tag (or something -- not sure if they are compatible at all). I think there's some

work out there for using memory objects to simulate files that are compatible with the video tag, however.

ic0n: have not returned to working on the pi since I went on vacation. I should fire mine back up and just let it run.

hello

When we get the h264 stuff merged in, I will have to look at local cameras providing h264 stream and just saving that.

also need the arm NEON asm support

[Got signal 7 (Bus error), crashing]

that's new

check zmc logs

I've seen bus error on the raspberry pi when you overdrive it.

ive seen it db updte failure

box is doing a lot, perhaps too much. would explain why two monitors, set up exactly the same - one works, one doesn't

added some monitoring to keep an eye

You know, this whole deep_storage thing... year/month/day/hour/minute/ but really there are only 265 days in a year. How about day of year/hour/minute/ or maybe YYYYMMDD/HH/Min

IJf it ain't broken, don't fix it? I know it is unweildy, but it works, right?

yeah.

how's the new house?

if for some reason h264 videostore fails, perhaps we should store jpgs regardless of the saevjpeg setting.

if i can get a 1080p mjpg stream in the browser

what might prevent zm from accepting that?

ram requirements?

by looking at the jpg info in the browser the image is 1920x1072 px in size

wouldnt that say so in logs?

you would think so.

will try again ... cant remember exactly what it said ... but not that

ah yes this points to memory ?

Shared data not initialised by capture daemon

means that zmc isn't running