Subscriber Discussion

Streaming A Camera To Multiple Vmses?

UI
Undisclosed Integrator #1
Feb 06, 2015

We have several cameras in our office for demo pruposes. I would like to record them all to two seperate systems for showing to clients. I know there is the obvious issue of two different systems sending configurations to the camera (frame rate, resolution, etc.), but I think we can manage that. Are there any issues with streaming or recording these to two different systems?

(1)
JH
John Honovich
Feb 06, 2015
IPVM

You might run into a few weird issues.

This could overload the camera and cause frame rate to drop or other quality issues. This is especially a concern with low end cameras and speciality cameras (like the Arecont multi-imagers that are processor constrained to begin with).

Additionally, if 2 VMSes are simultaneously connected to a camera, they might change low level settings of the camera that could impact the other VMS.

(1)
GC
Greg Cortina
Feb 07, 2015

This comes up often so I'll chime in. In the good old days of analog, your only concern was properly terminating.

Let's talk about IP because the assumption is if it can provide multple streams then it should be no problem. Not a good assumption.

If you pull RTSP video streams from the camera, and it's capable of it there should be no problem but you will have no control over the camera. This doesn't work well for PTZ's.

If you connect via ONVIF / SDK / API / CGI then you will likely have an issue because MOST (not all) VMS or NVR products actually query the camera at the time you add it and after that. They will typically load the values in their database for the camera at that time. A prime example would be NVR/DVR's that use NTP for time regulation and update the camera routinely.

Anyway....you have VMS #1 setting parameters at 30IPS - 1080p - 6MBPS using the CGI or SDK commands.

Meanwhile VMS #2 is connecting using ONVIF Profile S and sets the camera at 15IPS - 720p - 8.1MBPS and happens to not time sync correctly.

You end up trying to level a 3 legged stool if you know what I mean.

I'm not saying there isn't a way, it's just not as easy as it seems.

(2)
(2)
(1)
U
Undisclosed #2
Feb 07, 2015
IPVMU Certified

I've been messing around also with multi-streaming/recording and agree there is some strange, idiosyncratic behavior, probably involving camera-side race conditions. This makes it extremely difficult to predict how stable a configuration actually is.

Everything seems fine but then connect to the cameras in a different order and everything can go haywire. Sometimes it seems it's actually better to have two dissimilar VMSes or NVRs, because of they way they interact.

In your example, Greg, can you explain more about what the undesired behavior is? Does the frame-rate change on both cameras to 15 FPS or does the time on the camera get set wrong, or something else?

BTW -Unlike a four-legged stool, a three-legged stool never wobbles, even on uneven surfaces. ;)

(1)
(1)
GC
Greg Cortina
Feb 07, 2015
But hard to lwvel...... Some deep integrations change settings that are not normally visible to the end user / tech / web page. Loss of stream, inability to reconnect, inability to view or find recorded video, incompatible encoding parameters because one assumes the default is set, secondary or tertiary stream changes unintendedly and a host of other ghosts. For a local demo it wouldn't be uncommon to have one system connected using ONVIF or the CGi while streaming a second using just RTSP. Other than a lack of control and programming in most cases it would work. An exception would be any camera using client side dewarp I would imagine. Which product gets the camera first could matter. So now you do a camera reset or reboot? More fun than any single tech deserves, especially just before an important demo.
(2)
Avatar
Marc Pichaud
Feb 07, 2015

My experience: whith several VMS/NVR, it's most of the time a mess

Most VMS push their settings to cameras: Resolutions, Fps, Compression and sometimes CBR or VBR, but also ... PTZ Home positions...and also Private masking or motion areas

So 2 VMS will try to push their own settings and will spend time to stop, set, restart streams when detecting an other system changed their owns.

Very few brands, like Axis accept that several VMS create their own profiles (with different profils names) , so can remote monitor independant settings from the same cameras.

Let's add that camera also saturate when you ask too many streams, and as most VMS monitor 2 streams per camera (Rec/view)... it's becoming easy to saturate camera CPU

Very few IP cameras got a CPU indicator (Bosch only from what I know at the time being)

(1)
CA
Christopher Akesson
Feb 08, 2015
Good day. I have tried this many times in the past and it's always a mess. I can't speak for other systems but one easy way to demo VMS is with simulator cameras. That way you can use good recorded clips of camera positions that might be a it more exciting than an office corridor. However not all VMS have this possibility and yes I work for a VMS company.
BE
Bob Ehlers
Feb 08, 2015

What are you trying to show with the two vms? If camera control is not part of your need, and your vms supports it, just use an rtsp url for the video stream only without control. Again, if the camera can support two full rate/resolution streams you should be good. And then there is multicast...if supported.

We are seeing and more need for multicast viewing. Particularly in traffic where the video is shared with many users. VLC as a client.

Just some simple thoughts

WC
Wagner Cunha
Feb 09, 2015

In theory, you can use VLC to act as a proxy: receive the stream from the camera (rtsp only) and serve it to multiple VMSes. In the VMS, you gonna need to use the "RTSP Generic driver", if available. Note that you won't be able to use PTZ this way.

Avatar
Marc Pichaud
Feb 09, 2015

yo, neither local dewarping, neither dry contact, audio out... all TCP unicast commands

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions