Member Discussion
Is Using Multicast Important For Video Surveillance?
A number of installations use Unicast from the camera to storage or VMS. Is it because multicast isn't desired as a method of transport, or because it is deemed to complicated to use?
Lorraine, see our Multicasting Surveillance Tutorial and Multicasting Problem With VMS for two posts with more information.
Those should address your questions. If not, feel free to follow up.
Just a reminder for anyone that does not regularly read the comments. The Multicasting Surveillance Tutorial is really great but there is also some extremely useful information in the comments section. If you don't normally read the comments, make sure you read them for that one. You'll be glad you did.
thanks John. I have reviewed those posts and that is the reason I asked. The "Multicasting Problem with VMS" has a statement:
"They do not recommend feeding only a multicast stream from the device because of the difficulties encountered in troubleshooting multicast streams if there are problems."
Are you referring to difficulties in troubleshooting MC over the data network? and if so, is that the primary reason why people are avoiding MC? because the network makes it to difficult?
What you are referring to is a comment from Carl about a specific VMS he uses, not a general technology principle.
In terms of your original question:
"Is it because multicast isn't desired as a method of transport, or because it is deemed to complicated to use?"
It tends to be a combination of both - (1) for most, multicast makes no difference/benefit as only one or a few people want to watch the same camera at a given time and (2) it can be difficult, or at least take more advanced networking expertise, to manage.
Do you have a preferred VMS you are looking to use to multicast cameras?
I agree, the only time you would consider MC is if you are having throughput issues. And then as discussed above it depends on your system design. If you have multiple clients viewing streams in one location then it might be good. If your users are dispersed geographically then it might not be the best concept.
To answer your question on why MC over a network is diffucult is that a misconfigured MC network will flood your network with unwnanted traffic and end up doing more damage to what you are try to fix.
thanks for the insight. It would seem though, that if the network wasn't an issue at all, using MC would be the preferred method. If multicast was configured the same way as unicast, and didnt present additional challenges in the network, then why use unicast at all? it seems like the industy has designed around MC beause of the difficulty in configuring it on the network and has pushed the use of MC into the realm of specific use cases because of that. Anyway, thanks for the comments
Lorraine, that's misleading. At some level, yes, if multicasting was simply a switch on the camera or VMS, more people would certainly use it. The other issue would still be that it has minimal practical value in many, if the not the majority of applications where you rarely or ever have multiple people watching the same camera at the same time.
How would you reolve the issue of having multiple connection to a server for live viewing? 4 workstations in different offices with 19 cameras open 12 hours day?
If they are watching the same 19 cameras at 4 workstations simultaneously, it could be a problem, because that would be 76 unicast streams. That would add quite a lot to the throughput requirements of the server / recorder. The easy approach would simply be to 'beef up' the server/recorder with greater CPU to handle it.
One issue with a 'different offices' scenario is whether or not multicasting is supported on the networks between those offices.
Hi John
Currently there are 3 buildings connected with un managed Gigabit switches.... all these are connected directly to the server in unicast. There is a managed swithc at one of the locations but that is all. The server is hosted in the building where the "different offices" are requesting the video.
It may be possible to implement Multicast on the switches for the "office" in question.... not sure the Mainconsole from Nuuo supports it....
This probably sounds very naive, but what kind of application/organization would require having 4 people sitting in 4 different locations watching the same 19 cameras simultaneously?
Why is so much redundancy needed? Without any additional information, it seems like overkill.
One thing I must be mistaken about: Didn't at least half of the network bandwidth benefit of MC go out the window when everyone started using fast ethernet and other switching technologies that have private collision domains?
If the switch is routing each unicast on its own collision domain whats the advantage of using MC? I understand that the switch still has to process all the streams internally and the server has to generate them and the backhaul between the server and switch has to be able to carry them, but the LAN to the desktop itself shouldn't be impacted either way, no?
Hi Alain Bolduc
Yes it would seem you are correct.... although customers don't want excuses....
Hi Undisclosed (#0321091)
Situation is that the individual machines are running on 100% cpu with the cameras loaded... the idea would be that the multicast would broadcast the stream/vms like Wowza forwarding the streams as requested... the camera to the server is managable it's the requests from the clients that becomes an issue....
the entire camera network is subnetted ... the only addresses on the main network are for the NUUO NVR Mini and the Mainconsile. The Vivotek cameras being used do support multicast although the servers do not.
Is there any easy way for you to upgrade the machines or at least the CPU of the machines?
I am quite positive that will be a lot easier / less expensive than multicast 'enabling' that network.
If that's what the RFP calls for, who am I to judge.
About the machines running at 100%, it could also be the video cards need to be looked into. If those were upgraded, it could also help solve your CPU issue, as that would provide dedicated processing power and memory for those multiple video streams, offloading the CPU.
Possibly, will see how we go....
found these which in the interim which could resolve some of the issues and they support multicasting ...
Muxlab HDMI over IP Extender with PoE
500752 [Kit]
500752-Tx [Encoder], 500752-Rx [Decoder]
Does the anticipated use of Video Analytics have a role to play in the Multicast vs. Unicast decision for a 1000+ camera site?
Analytics use could involve ad hoc tag & trace search across say more than 100 cameras and also scenario based analytics dedicated to individual cameras.
It would impact multicast vs unicast only if analytics were eliminating large portion of your live video use. In other words, if somehow analytics guaranteed that you would not need to have simultaneous large numbers of live viewers for a single camera. That said, in emergencies, analytics or not, you most likely want to plan for many people watching the same cameras at once.
Btw, what is "ad hoc tag & trace search"? I have never heard or it and Google returns no relevant results.
Sorry by 'ad hoc tag & trace' - I was referring to a scenario where a security department may need to invoke a search for a suspect wearing say a red shirt and yellow cap across 100+ cameras for both live and (recently recorded) video.
Some Analytics allow you to specify the color and other attributes of the suspect, present you with suspect candidates based on your search criteria, then one you identify the actual suspect you then 'tag' this image for further searches based on the actual suspect.
Color searching is not going to be very accurate across multiple cameras and multiple days, e.g., Testing Color Analytics Performance
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Started by
Craig Bruce
|
13
|
about 3 hours by Undisclosed Manufacturer #1 |
|
Started by
Undisclosed Integrator #1
|
5
|
about 2 hours by John Honovich |
|
Started by
John Honovich
|
90
|
about 6 hours by Undisclosed Distributor #16 |
|
Started by
Donald Maye
|
4
|
about 5 hours by Carter Maslan |
|
Started by
Sean Patton
|
1
|
22 minutes by Sean Patton |