Sharing Video Streams Between Two Agencies

I have an existing installation of analog cameras where each analog camera is currently connected to Encoder A for one agency and Encoder B for another agency. Very simple, Very clean, no worries about interconnecting networks or either VMS creating conflicts with the other. As we look to migrate from analog to IP, I am looking for an equally simple architecture.

I would like to know of any experience with using a multi stream camera to feed two seperate VMS systems. My initial discussions with the two major VMS providers is to not configure a system where two different VMS systems are pulling streams from the same camera.

Thanks for any input!


John, good question / topic.

VMS companies generally do not like the idea of other VMSes taking streams from the same camera. It could cause performance issues, changes in settings and other difficult to troubleshoot issues. That's not guaranteed, but it is certainly a real risk.

There's PSIM, but that's the antithesis of 'very simple, very clean'...

I currently have an OnSSI and Milestone system both running. Each is sharing the same Axis camera and pulling different streams and I haven't had any issues.

Adam, thanks. It definitely can be done and we have done this (on purpose as well as inadvertently many times, with many VMS systems). Sometimes, it works fine. Other times, weird problems do arise.

I am not opposed to doing this, especially since most alternatives of having video go to multiple VMSes is far going is far more expensive / risky. It just has some concerns itself, especially since most VMS vendors will object and possibly blame this setup as causing problems if there is a service issue.

I am looking for an equally simple architecture.

The logical equivalent network architecture would be multicasting, though your equipment would have to support it and your mileage may vary...

Multicast or not, the VMSs will still potentially be fighting for control of camera settings. It's a separate issue.

Multicasting has enough risks with just 1 VMS...

Background: Multicasting Surveillance Tutorial and What VMSes Support Multicasting?

Multicasting has enough risks with just 1 VMS...

And not enough rewards... But here we have 2 VMSes, so 2X benefit. (With 4 VMSes its a nobrainer! :)

Not to mention the fact that because we are talking about camera side multicasting to just two static servers, this could minimize one of the main hurdles of typical multicasting: the design, setup and installation of special switches/routers and dynamic multicast routes, since you are only multicasting to two fixed hosts...

Here's an, albeit rudimentary, proof of concept paper documenting how a working system was setup using ONSSI and Genetec. Their conclusion was that its viable as long as one doesn't need both systems to control PTZ's, etc. I'm not saying its definitely the way to go, but since I don't see any perfect solutions out there its worth looking at. And as Ethan says the camera control issue is separate and one to contend with in either a multistreaming or multicasting environment...

Is it not possible for each agency to also set up a remote client to the other agency's VMS?

We have the same cameras being recorded by Milestone and an Exacq. This works out rather well, as Milestone is setup for server side motion, while exacq is set for camera side motion detection, And Milestone uses PC time for the database, whereas Exacq ueses camera time. Some are PTZ models and control is normal across the two.

Keep in mind though frame rates when multi streaming are sometimes lowered, and some older IP cameras I have seen, can only have 1 stream of each type, 1 H.264 / 1MJPEG / or 1 MPEG4

Although the agency on side B should just stick to a client. If its a simplicity thing for network purposes, utilize a dual nic server and put a connection from each agency into it. If its for redundancy use a NVR platform with High Availability, Milestone/Exacq all the big names have this option.

Thanks to everyone for the feedback. It appears that the camera manufacturers have not provided the administration tools to control the administration of individual streams. Ideally, a stream could be desginated to VMS A and a second stream dedicated to VMS B with no abiltiy for either VMS to take control of the other's stream. Even designating one VMS as the "Master" would be helpful.

Without documented support from the VMS manufacturers involved, proceeding with multstream is too risky for these particular agencies. Maybe a niche will develop for products like the Samsung 1280H analog camera coupled with an encoder to deliver 1080P? This would at least allow moving into HD cameras.

The network isolation topic and seeking cooperation between IT administrators is seperate issue. It will be difficult to provide an architecture as clean as seperate encoders to each network.

Interesting concepts to approach this at the Dual NIC Server, client, or PSIM level. With two of the largest VMS solutions in play, there may be some chance that a PSIM won't crash and burn over time.

Somedays I miss my distribution amplifiers! Thanks again to the IPVM communtiy for your thoughts.

A clean way to do this would be to have VMS A control all the cameras at A, and have VMS B control all the cameras in zone B. And then to get the two VMS systems into interworking.

I have done this in a large deployment some years ago, where the public hand spent money into specifying a CCTV routing protocol. All from old analogue, but has moved on to digital in the last years. This was in London, and the protocol is the de-facto city standard (TV network protocol / TVNP). Large networks with multiple hops and re-routes, thousands of cameras, multiple VMS.

The concept is that VMS A has setup a trunk of lines to B so that B can push feeds to A.
And A is able to request camera XYZ from that system at B (actually from any system in the mesh, addressed with node number / camera number). The protocol allows push and pull, and it does PTZ arbitration as well.

When ONVIF came into life I checked if such a use case would fit into there as well.
But looks like that protocol is implemented for "Camera to VMS" and "VMS to DVR", nothing else.

And yes, VMS vendors do not like the idea of interwork - unless they are forced to.

Such an approach rather fits to large deployments, anything seen there for heterogenous networks?

best regards, Wolfgang

Wolfgang, thanks for your feedback:

"The concept is that VMS A has setup a trunk of lines to B so that B can push feeds to A.

And A is able to request camera XYZ from that system at B (actually from any system in the mesh, addressed with node number / camera number). The protocol allows push and pull, and it does PTZ arbitration as well.

When ONVIF came into life I checked if such a use case would fit into there as well.
But looks like that protocol is implemented for "Camera to VMS" and "VMS to DVR", nothing else."

Typically, VMSes work hard against allowing that process (i.e., sending out / responding to requests from other VMSes). It happens but typically VMSes will not allow direct competitors to do so (see: Recorders Integrating with Other Recorders).

To your point about ONVIF, yes, ONVIF today (Profile S) is aimed at connecting cameras to recorders. The upcoming Profile G is meant to support recorders connecting to other recorders. I added a new discussion on ONVIF Profile G support.