DW Or Milestone? Live View ~90 Cameras

In reply to Undisclosed #2

Not that it is applicable here, as this project has 90 cameras (currently).The "128 camera limit on the server side" refereed to in the post has been removed as evidenced by our new X- Rack servers support of "200 cameras." The only remaining limiting factor is in the case of fail over, the max number of cameras remains 128 per server. Of course, fail over and multi-server are standard - meaning they do not require a premium license.

The client supports 64 cameras per tab. Multiple instances of the client can be run simultaneously on a single workstation. Making 45 cameras per monitor on a single multi-monitor workstation possible.

Depending on the resolution and frame rate requirements one or two recording servers would be needed.

Meaning its possible to support the application with a single server and single workstation.

Reactions:

(1)

Undisclosed #3

why does the customer want to display all the cameras at once on a wall TV/monitor?

for show?

Reactions:

Undisclosed Integrator #1

They feel like if there is an active event, they can follow the activity/subject easily. The TV's are going in a work room, so they won't even be viewed 95% of the time. Plus I feel like the size of the room is going to make the TV's too big, you will be right on them. I have to review the new design/blueprint of the room, as it is being completely remodeled. Right now, its just a shell.

90% of me says it's a bad idea, the other 10% says "The client wants what the client wants"

When I tried to explain, I was stopped dead in my tracks and told oh no we have another property like that, etc.

okie dokie then

Reactions:

Undisclosed #3

In reply to Undisclosed Integrator #1

sure...

Related image

As long as what the customer wants has no negative impact on the security system, I would put monitors on ceilings if they wanted that. :)

Reactions:

Patrick Kelly

In reply to Undisclosed Integrator #1

Some Event Rules and map overlay Layouts make following active events easier. We can provide some sample video and/or evaluation license to assists in you in your explanation.

The new Layout as an Action in v4 will make this even easier.

Reactions:

(3)

Shannon Davis

IPVMU Certified

Milestone may be more expensive but their video wall is really good. With that being said that is an expensive option as well but would do exactly what the customer wants.

Reactions:

Patrick Kelly

In reply to Shannon Davis

DW Spectrum offers a pretty good video wall solution, of course the DW Spectrum client offers multi-monitor capability standard. Doing exactly what the customer wants (displaying 45 cameras on two monitors) without the need for a video wall license.

But when DW Spectrum Video Wall Licenses are used (1 operator by 2 monitors per license) As shown below, on the eight monitors on the wall which are connected to two Blackjack Clients running in video wall mode, with 4 Video Wall licenses activated on the system. This allows any of the operators on the desk (or beyond ) to push layouts and images on to the wall for all to see.

Reactions:

(3)

Shannon Davis

In reply to Patrick Kelly

IPVMU Certified

Not that familiar with DW Spectrum. Good to know. I agree with the why do they want to be able to track a situation across all 89 cameras. With that many the images will be fairly small no matter the size of the monitor and therefore hard to track. This is one part that is still hard to get the customer to realize.

Reactions:

Undisclosed Manufacturer #4

In reply to Shannon Davis

It's not just "how many cameras" the application will let the user display, it more like "how many camera streams (total-bitrate) can the client application decode at once?". Follow that up with, "what computing resources can the client application use to decompress the video?".

Milestone's hardware acceleration automatically offloads decompression tasks to the Quick Sync GPU (if present), and also to one or more NVidia cards (if present) to reduce load on the CPU(s) which simply means more decompression can take place with potentially lower cost.

DW say's it also offers this but must be turned on, is experimental, and might cause flickering. May want to test before committing, as the savings could easily be eaten up by needing beefy client servers.

If you are going to brute force the decompression of 90 streams through CPU only, you are going to need some pretty expensive dual-XEON workstations.

Reactions:

(1)

Shannon Davis

In reply to Undisclosed Manufacturer #4

IPVMU Certified

I completely understand what it takes to do what the customer wants but sometimes they just won't listen or even care. They will say do what it takes. This is one advantage of Milestone using the GPU for this. You would also want to size the streams for the correct resolution of the tile on the monitors as well which helps minimize the horsepower required.

Reactions:

Undisclosed Distributor #5

Nice feature but old in Milestone Smart client is the ‘Update on motion’ possibility.

so everything is grayed out until there’s motion. Then the camera (or camera’s)with motion is displayed live.

This function has a great impact on cpu use when the site is not that busy.

Offcourse the hardware acceleration with a good Nvidia card will help the cpu a lot :-)

Reactions:

(1)

Undisclosed #2

In reply to Undisclosed Distributor #5

IPVMU Certified

This function has a great impact on cpu use when the site is not that busy.

Even if it requires server-side motion detection to be enabled when it wasn’t before?

Reactions:

Undisclosed Manufacturer #4

I think he meant it has a great 'positive' impact on the CPU when using the feature, meaning lower CPU use.

Reactions:

Undisclosed #2

In reply to Undisclosed Manufacturer #4

IPVMU Certified

I think he meant it has a great 'positive' impact on the CPU...

i agree he does. But I’m unsure that it always would be positive overall to the system.

Consider the case when you have some number of cameras that are being recorded all the time by the server and being displayed all the time by a dedicated client. Without any VMD being used anywhere.

Let’s say, in that case, that the server cpu is at x and the client cpu is at y.

Then if the system is changed to “Update on Motion” for all the cameras then either the server or the client has to start doing motion detection,(assuming camera side VMD is not available).

If the server itself is not displaying any of the cameras on its console, then two additional, cpu intensive, steps must take place for each camera stream:

1) decode the h.26x

2) look for motion

then when there is no motion found the server then can pause the stream.

So after the change the server cpu would be x+? and the client would be y-?.

Basically what I’m saying is that if you are not using motion detection already, changing to update on motion might lessen the cpu on the client but increase the cpu on the server, perhaps significantly.

Maybe Josh from Milestone will stumble across this thread and blow up my theory :)

Reactions:

Josh Hendricks

In reply to Undisclosed #2

Milestone Systems

Basically what I’m saying is that if you are not using motion detection already, changing to update on motion might lessen the cpu on the client but increase the cpu on the server, perhaps significantly.

The "Update on motion" feature in the client will cause Smart Client to wait for a "Motion" signal from the Recording Server before rendering video, and the Recording Server will only send that signal if the server-side motion detection plugin is enabled. So if you've disabled server-side motion detection and enabled the Update on Motion feature, you'll never see live video in the client as it'll be waiting for a signal which will never arrive.

If you enable motion detection for the purpose of the Update on Motion feature, then yes there will be some added processing server-side, but not nearly as much as the client needs for rendering that same video since by default, the server is only doing motion detection on key frames. So you take a smaller hit on CPU server-side for a potentially significant savings client-side.

It's a great point to consider for sure, but it's also pretty rare that I see someone has server-side motion detection disabled - even if they're recording always. The motion metadata is useful for smart search and it seems like most people build out servers with enough overhead that they're not worried about saving compute by disabling server-side motion detection.

Reactions:

(1)

Undisclosed #2

In reply to Josh Hendricks

IPVMU Certified

If you enable motion detection for the purpose of the Update on Motion feature, then yes there will be some added processing server-side, but not nearly as much as the client needs for rendering that same video since by default, the server is only doing motion detection on key frames. So you take a smaller hit on CPU server-side for a potentially significant savings client-side.

Joshua, thanks for the response, and sorry for calling you Josh, if you don’t go by it:)

A few things I would say about your analysis:

1) In the scenario I gave, it’s not just motion detection that the camera would have to do, but also decoding of h.26x before VMD could occur. Correct me if I’m wrong, but on a server without motion detection and no local display of cameras, the streams could simply be laid directly to disk without further processing. Surely the overhead of decoding + VMD has some cost...

2) Server side decoding and VMD must take place 24/7 on all cameras that are “Update on Motion”, even when not being displayed on a client at a given moment.

3) Server side cpu constraints affect all clients, but client side constraints only affect that workstation.

One other thing I’m curious about is how does the key frame only VMD work with the popular variable length GOP CODECs, like Zipstream and h.264+?

Thanks!

Reactions:

Jared Tarter

In reply to Undisclosed #2

Milestone Systems

If you have dynamic GOP enabled in a Smart Codec device, or have a custom setting on the GOP that is longer than a second, then it is recommended to disable the keyframe only setting for our motion detection (it is just a check box). You can then set how often you want it detecting motion. Setting it to 1000ms would get you the same detection rate as the keyframe only setting in a default scenario because our drivers are set to 1 keyframe a second by default.

Reactions:

Undisclosed #3

In reply to Jared Tarter

"our drivers are set to 1 keyframe a second by default."

how does the cameras internal key frame interval setting effect Xprotect's default setting for VMD?

is '1 key frame per second' an 'accepted' (or at least normal) industry standard, or do other VMS's use different settings - and if so, why?

Reactions:

Jared Tarter

In reply to Undisclosed #3

Milestone Systems

Our drivers make the setting change on the camera so that we tell the camera to send us 1 keyframe per second by default. If you change that setting in our software then we will make that change on the camera.

I'm not certain how other VMS's do it as far as their standard settings but I would be interested in knowing.

Reactions:

Undisclosed #2

IPVMU Certified

In reply to Jared Tarter

Setting it to 1000ms would get you the same detection rate as the keyframe only setting in a default scenario because our drivers are set to 1 keyframe a second by default.

Though wouldn’t setting it to 1000ms be more cpu intensive because it would have to process/integrate a number of p-frames + the last key frame, instead of just the key frame?

Reactions:

(1)

John Bazyk