Multicasting Surveillance Tutorial

By IPVM Team, Published Jan 04, 2018, 12:15pm EST

Network bandwidth can be a concern for some surveillance systems. While improvements in video codecs, such as smart codecs for H.264 and H.265, have reduced bandwidth needs significantly, large systems still encounter issues with large amounts of video data and viewers. In this note, we look at the basics of multicast networks, a frequently-mentioned means of reducing bandwidth, where they will save bandwidth and where they will not.

Inside we explain:

  • The Basics of Multicast
  • Use in Surveillance
  • Unicast / Mulitcast Combinations
  • Network Support
  • VMS Suppport
  • Quiz Yourself: 5 Question Quiz to measure knowledge of Multicast for Surveillance

This is one of many tutorials on networking for surveillance. Others include: Wireless Networking for Video SurveillanceNetwork Addressing for Video SurveillanceBandwidth Guide for Video Surveillance, Remote Network Access for Video SurveillanceNetwork Monitoring / SNMP for Video Surveillance, and more.

The ******

** ***** ** ********** multicast's *** ** ************ applications, ***** ****** ********** the ******. ** **** typical ******* ************, ******* transmission ** ****. ** this ******, *** ****** device, **** ** ** IP ******, ********* ** many ****** ** *** video **** ** *** requested ** ************. *** main ******** ** **** is ************. ** *** camera ** *** ** a * **** ****** size, *** *******, **** clients ********** ***** **** utilize * **** ** bandwidth. **** ***** *********** unicast ************ **** *** sender (***) ** ***** recipients (*****):

Unicast Transmission

** ********* ************, *******, there ** ** ****** connection ******* *** ****** and ***********(*). ************, **** as ************ *******, *** joined ** * ********* group, ***** ******** * single **** ** *** video ****** ***** ** replicated ** **** ******. So **** ******* ********** a * **** ****** will **** *** * Mbps ** *********, ******* of *** * **** used ** * ******* network. *** ********* ***** illustrates ********* ************ **** the ****** (***) ** three ********** (*****):

Multicast Transmission

Use ** ************

********* ** ***** ***** as * ****-**** ********** in *** ************ ******. This ** ****** *** the ****. ** ******* with * ******* ****** of ************, **** ** one ********* ****** *** one ** *** ******* clients, ********* **** **** little *********. ****, ** will *********** **** *** bandwidth ** * ******, but ** **** ***** this ** **********, ** the ******* ** ****** a ********** ** ******* systems. ** ***** ***** recording *** ******* *** separate *******, *** ** the ******, *** ** the ******, ** ********* will ** *****, ** each ****** ** **** being **** ** *** destination.

*******, ** ****** ***********, where * ****** ****** of ******* *** ****** by * ***** ****** of *******, ********* *** be ********. ** ********* or ********* ******* *******, for *******, **** * dozen ******* *** ** connected **/*, **** ********** occasional *****. ****** ***** may ***** ****** ******** events, ** ****. 

Unicast/Multicast ************

** **** *****, *** systems *** ** ******* of ****** ** * unicast ****** *** **-********* it ** ********* ** clients. **** *** ** useful **** ***** ******* connected *** ***** **** don't ******* *********, **** as **** ******** ***** or *** ***********. ** this ****, *** *** server ***** * ****** connection ** *** ****** and ***** *** ****** out ** ********* ** a ******, ******** *********. In ***** *****, **** as * ****** ********** through * *** ***** does *** ******* *********, the *** *** ******** video **** ********* ******* as * ******* ******. These ******** *** ********* limited ** **********-***** ****, however.

Network *******

********* ** ********* *** ********** ** ***** D, **** ** ******* range ** ***.*.*.* **  *** ********* ***** illustrates ********* ************* ** an ** ****** ****** ****** capabilities *** ************* ******* may **** ** ************.

Multicast Configuration on IP Camera

********* ******** ******* **** all ********** ******* **** (Internet ***** ********** ********), which ******* *** ******* and ******* ** ********* groups. **** ** ********* by ****, ** *** all ******* ******** *****. The ***** ***** ***** a ***** ****** *** the ******** ** ***** Multicast *** **** *** and ******* *****

Multicast Configuration on Managed Switch

*** ******** ** ****** manufacturers ******* ********* *********, as ****. *** ******* is *******, *******, ** shown *****.

********* ******** ** *** complexity ** ************ *** troubleshooting. ******* ******** *** be ****** ******** ** those **** ***** ******* experience, ** *** **** concerns *** *** ****** and *********** *********. **** technicians **** ** ****** IP ********** ******* *** client ********. **** *****, performed ** *** ******, is ****** ****** *** scope ** **** ***-***** techs' ********, *******. *************** ** also ** ****** ** simple ** ******** * single ****** ******* *** destination *******, *** ** the ******** ** ********* groups, ***** *** ********* separately. ******* **** **** the ****** ** "****** parts" ******** (*******, *******, servers, *** ********), *** with ***** *** ********* implementation *** ********* ******, and ********* ** **** left ** *********** ** techs.

VMS *******

**** ***** ****** ************* now ******* ********* *********, ******* some ** *** ***** VMS ********* ** ***. * quick ***** ** *** players ***** *** ********* multicast ******* **** ****:

**** *****, ***** ********* is ******* ** ****** and *** ****** ** a ****** ** ********** components, ** ******** ****** checking ******** ********* ********** on *** **** *** easy ** ** ** deploy ********* **** **** preferred ***.

Test **** *********

***** **** ** **** * * question ****

Comments (64)

The report says Avigilon doesn't support Multicast but there is settings to enable Multicast in the cameras. This allows redundant recording to multiple servers.


"VMS Support

As mentioned, not every manufacturer supports multicast. Most major camera manufacturers now support multicast streaming, however some of the major VMS providers do not."

This is noted more than once in the OP.

So Avigilon supports multicasting on the camera to server side when you want to record to multiple servers. They may not support multicasting to the clients but multicasting is supported on the recording side.


"They may not support multicasting to the clients but multicasting is supported on the recording side."


BFD... multicasting is a solution deployed when the same video streams are being requested by multiple clients simultaneously.

The ability to record duplicate streams to two different recorders is a redundancy solution, not a 'delivering multiple simultaneous client requests for video' solution... 

So if you have multiple servers recording streams from the same cameras how is that different then multiple clients requesting streaming from the same camera?  Clients only stream when people are looking at the camera but if the cameras are recording to multiple servers simultaneous this camera would be sending multiple streams 24/7 


You have 3 servers setup to simultaneously record the same cameras.  If each stream is 4Mbps and you're using unicast that would be a total of 12Mbps from the camera to the server correct?   If you setup multicast then you would only see 4Mbps from the camera right?   

I agree with you in your assessment that the ability to simultaneously record the same camera stream to multiple recorders might be a good thing.... and there are other VMSs in that same list that can do this.

But this string is a tutorial on the benefits (and lack thereof) for deploying multicast in surveillance applications.

Redundant recording might require a multicast environment (including level 3 switches to accommodate the required redundancy) - but multicasting, at least in regards to how the OP is trying to educate readers in its common use cases - is a 'multiple simultaneous client request' solution.

Agreed... So does Avigilon support or not support Multicasting? 

Redundant Recording that requires a physical topology that supports multicasting (level 3 switches) to work is not multicasting per se - it's something else that needs the physical configuration to work.... at least that's my take on it.

I'd love to hear what actual networking guru's have to say on this subject.

My understanding of multicasting is it is a one to many transmission.  It works the same way if you have clients receiving the stream or multiple recorders receiving the stream.  So I am not sure I agree with you that redundant recorders which are receiving a single multicast transition from a camera would not be considered multicasting.  

My understanding of multicasting is it is a one to many transmission.

That may be your understanding but the conventional application of multicasting (even from 20 years ago) was primarily for client viewing (IPTV, video conferencing, etc.). Ergo, when most talk about multicasting the implication is that clients can use multicasting. When essentially everyone else but Avigilon talks about supporting multicasting, they mean to clients so, at the very least, Avigilon needs to be clearly separated into a different application apart from the typical use case others are supporting.

I am completely fine with Avigilon being in a different category and that makes sence. But to say they don't support multicasting at all is not true.  

Hi Michael - if you've been successful using multicast with Avigilon 8MP cameras, really appreciate your letting me know on this new thread Avigilon 455 Error From 8MP RTSP Stream; Will Multicast Solve The Problem?

we use this for multiple monitors and clients with out the cost of upgrades to get the same solution. 

Able to get this solution with multiple servers, multiple modules , and low cost 

when the end user does not want to spend an extra 5-15 k on upgrades , you figure out how to make existing work. 


c'mon Michael.... 

Redundant recording is something that is so rarely used (primarily because there are lots of other redundancy solutions that are much more easily deployed) as to not even be worth mentioning.

And recording the same stream to 3 different recorders is as close to 'never needed' as to be the exactly the same thing statistically.

Multicasting is rarely used in surveillance applications because there is no real need in 99+% of installs.... but when there is a need, it is a multiple, and simultaneous, client stream request solution. 


Simple Answer.

Avigilon cameras can multicast.

Avigilon VMS cannot.


"VMS Support

Most major camera manufacturers now support multicast streaming"


"Simple Answer.

Avigilon cameras can multicast"

big whoop.


...that we can agree and move on :)

...but multicasting, at least in regards to how the OP is trying to educate readers in its common use cases - is a 'multiple simultaneous client request' solution.

Used without a VMS, cameras that support multi-casting would support ‘multiple simultaneous client requests’.  For instance multiple PVMs showing the live stream of the front entrance.

If the recording server is transcoding the live streams and delivering them to clients, multicast capability of the VMS might come into play. I believe Milestone and Salient does this.

If the clients are pulling live streams directly from the cameras, and toggling between different resolution profiles the camera is encoding, then multicasting from the VMS would not come into play. I think you typically see this architecture when using a manufacturers eco system, (same brand VMS and cameras) requires a tight/proprietary integration.

I'm struggling to imagine a scenario where multicasting recorded surveillance video would be necessary.

Avigilon's HDSM marketing video makes it appear there is two profiles sent to the recording server, which then negotiates which profile to pass to client. So if this is accurate; the clients are pulling live streams from the recording server, Avigilon can't multicast, then multiple clients would multiply the bandwidth between recording server and clients. My hunch is the clients actually pull live streams from cameras, negotiating the profile directly. In this scenario, multicasting capability of the VMS would be unnecessary. 

Maybe someone from Avigilon could clarify, because the rep in my area had no idea.

"My hunch is the clients actually pull live streams from cameras, negotiating the profile directly."

Your hunch is wrong.

I don't know of any VMS solution that delivers camera streams from cameras to clients.  Cameras (even those that can multi-stream) are generally not designed to stream to anything other than recorders.

Genetec can redirect video directly from cameras to clients. It can also multicast from the server to the client, as others do. They talk about it in a recorded webinar here (though it's a fairly basic explanation). 

ISS appears to support this as well, but I'm much less familiar with them. 

I stand corrected - multicasting from the camera to the client is specifically supported in your examples...  Thanks for that info Ethan.


In what real-world situation would you want your cameras to stream directly to your client?

I'm not sure that I can think of any specifically - but maybe others have had this need.

But if so, why not let the VMS recorder (or combination of recorder and transcoder) do the heavy-lifting instead of the camera?  I'm genuinely curious.

Note:  I only made it about 4 minutes into that webinar video before I had to fight nodding off... if that dude talks about the reasons why this feature might be needed by anyone, it is deeper into that recording than I could make it.

In what real-world situation would you want your cameras to stream directly to your client?

For the same reasons you want to multicast from the server to the client, reduced bandwidth.

But if so, why not let the VMS recorder (or combination of recorder and transcoder) do the heavy-lifting instead of the camera? I'm genuinely curious.

There is no ‘heavy lifting’ really for the camera, aside from trivial multicast group administration, which as noted most cameras already have built-in.

But there is less load on the VMS, and a lower latency path to the client than a VMS based multicast.

To your point though, I see no evidence that Avigilon actually does this (like Genetec), and many people saying it is just for redundant recording, including the venerated Alex K.

"For the same reasons you want to multicast from the server to the client, reduced bandwidth."

This assumes that the camera is not being recorded, no?

i.e. if the camera is streaming to the recorder - and then also has to stream directly to a client, then there is no reduced bandwidth from the camera, but instead, increased bandwidth.

I will grant that maybe a physical topology could dictate the need for a camera to stream directly to the client (instead of just sending one stream to the recorder) - but I have never heard of anyone requiring this function, nor the logic they used to come to this conclusion.

This assumes that the camera is not being recorded, no?

i.e. if the camera is streaming to the recorder - and then also has to stream directly to a client...

No, both the recorder and the clients could read the same single multi-cast stream.

Record full resolution profile, use lower resolution for live views at client without putting that demand on the headend hardware.

Any scenario where you don't record everything. A federated system where you only want to look at a small fraction of a site.


A practical example would be casinos.  They have tons of cameras and unicast is not possible, so they need multicast to watch and record.  Some times many people could be watching the same stream and they watch the live streams, with recordings as evidence or review.

False. There are clients that can circumvent, and even operate without server. 

My hunch in regards to Avigilon was wrong if I understand their white paper. The cameras send three streams to the recording server, it then chooses which stream to send to client. 

They would need multicast support in their VMS to take advantage of saving bandwidth to multiple clients.

But if you are creating, transmitting, and recording 3 camera streams to the server, isn't that self defeating? There is typically, exponentially more cameras than clients.



I suspect this architecture was orignally designed to alleviate the demand on decoding hardware so all those MPs don't overwhelm the client machine. They market it as bandwidth savings.

When you send a stream, unless there is something about the properties of the video that need to be different, in multicast, you only send one.  So to answer, I am not sure why they would send more than one multicast unless the frames, etc. are different per stream.  Unless they are unicast streams.  Then it would be per device and viewer.

With Avigilon HDSM, the camera encodes 3 streams at different resolutions, and transmits them all simultaneously to the recording server. The cameras are not multicasting.

from camera to server example

1 x 16mp stream

1 x 2mp stream

1 x CIF stream

You are conflating multi-stream encoding capabilities (Avigilon's HDSM, FLIR's Adaptive Streaming) with multicast functionality.

Maybe you should sign up for an IPVM course....

Maybe you should sign up for an IPVM course....

You are conflating multi-stream encoding marketing with magic.

Tried this one , found with legacy issues , easyier to split signal, set motion in place, limit thru put and set up black out areas or not used areas of the cameras so as not to record what is not needed. 

found that when using a higher rated mpxl camera we had to divide output , use variable recording , create event recording and set up black out areas , then we were able to achieve stability 

Motion Events , trigger Events and Change parameters of camera , experiments with what would work , takes lot of time to figure out details 

or we could have just changed out cameras , probly easier 

but would not have had on hand experience to see actual work. 

"However, in larger deployments, where a larger number of cameras are viewed by a large number of clients, multicast may be critical. In municipal or corporate command centers, for example, half a dozen clients may be connected 24/7, with additional occasional users. Client usage may spike during critical events, as well."

That bolded sentence is a really big deal, imo - and I don't think most appreciate the significance.

It is a universal truth that in 'most' surveillance applications, multicasting is an unused - and unneeded - option.  Why?  Because there are very few real world security applications where there are large numbers of simultaneous client connections required.

Are there large security applications that require multicasting to facilitate simultaneous client machine requests for video?  absolutely.

But what about those applications that see no value in multicasting for day to day operations - ignoring the aforementioned potential spike?  When the excrement hits the fan, the 'day to day' solution can fail miserably to provide the needed data to a distributed response team. 



We worked on a campus design a few years ago.  The consultant (and perhaps the client's IT department) would not allow multi-casting, stating that the odds were that multiple clients would most likely not need to observe the same camera(s) simultaneously.

We brought forth the same argument, as noted by Undisclosed #1, that, in the event of an active shooter or other emergency situation, all eyes would be on the nearest cameras, possibly resulting in poor or no images to some.  The argument was rejected, and they have been lucky so far.

Likely their network guy doesn't understand Multicast in their network design either, this happens all the time.  I have seen networks fail turning it on.  But that fear should not replace your argument, it's a good one.  They should implement.

As mentioned, not every manufacturer supports multicast.

As a multi-cast consumer or multi-cast producer or both?

So four viewers requesting a 2 Mbps stream will only use 2 Mbps of bandwidth, instead of the 8 Mbps used in a unicast network.

Though that is completely true only if the four viewers also plug into the same physical switch.  If some viewers are on different switches that can negate the gain.

For instance, consider 4 different 2Mbps camera streams being distributed to 4 viewers with each viewer on their own switch.

Each switch will see 8Mbps of traffic, regardless of whether it is configured as multicast or unicast.

No, I don't think so:


I am no networking wizard - but I believe that the level 3 switch (deployed as above where the recorder streams ONCE to the switch) takes the load off the recorder to deliver simultaneous client-requested streams.

Am I wrong, networking wizard IPVM members?

I said when “each viewer is on their own switch”.

You would be correct if each camera had only a user on their respective switch for single viewing.  Sounds like a lot of hardware for a small design.  Otherwise if you have a single camera on a switch and uplinked to the 4 different users, you have the camera switch still using 8Mbps in unicast.

You would be correct if each camera had only a user on their respective switch for single viewing.

Right.  That’s what I clearly said, no?  “Each viewer is on their own switch.”  Though, to be clear, each viewer is viewing a quad of all four cameras.

Sounds like a lot of hardware for a small design.

So Walter, I didn’t mention it but this network is used for all sorts of non-surveillence tasks.  Like e-mail and Word and Photoshop etc.  

In fact, if it makes it easier to imagine, each floor has its own switch, each floor has its own reception area.  Each reception area needs a view of the four ground floor exits and entrances.

Not that hard to imagine, is it?

The different areas need to share the same camera feed so your uplink bandwidth will multiple on simultaneous unicast viewing.  Your camera link will also experience this bandwidth and the camera processor goes up (the cameras have a limit in quality stream and the number of them).  With multicast, I could have all users on your network viewing the feed while the camera never breaks a sweat.  Your L3 switch CPU is panicking instead, haha.

1. R1 is watching C1 and C2, R2 is watching C1 and C2

2. R1 is on floor 1, R2 is on floor 2

3. R1 is on switch 1, R2 is on switch 2

4. C1 and C2 are on switch 1

B = Bandwidth usage for a single stream

a. C1 and C2 are experiencing 2B each

b. switch 1 is experiencing 2B to R1 but 4B total from two ports C1 and C2 (each 2B)

c. uplink to R2 is experiencing 2B

i. multicast would only see 1B from each C1 and C2

ii. R1's port would see 2B, one from each camera

iii. switch 1 would only see 2B total from C1 and C2

iv. uplink would see 2B

If one other user on R2 adds themselves, in multicast, nothing changes except a new port to send the stream down.

In the unicast mode, uplink takes a hit +xB, the C1 and C2 take a hit and total data on the switch takes a hit.

Unicast would be linear, multicast would be level off.  As stated earlier, CPU (other than network design with multicast) would be your next major concern.


Your camera link will also experience this bandwidth and the camera processor goes up (the cameras have a limit in quality stream and the number of them).

Not with, as often are employed in such situations, VMSes.  These machines are designed with multiple viewers in mind.   Of course they are ultimately limited as well, but nothing like cameras are.  Furthermore I addressed this already here and here.

I stand by my statement and it’s specific conclusion for the use case I defined, to wit:

Each switch will see 8Mbps of traffic, regardless of whether it is configured as multicast or unicast.

If you agree with my statement I am more than happy to engage regarding related issues, but I’m not sure that this qualifies.

Yes, you are right that multicasting reduces the work that the stream producer (VMS or camera) does whether there is one switch or four downstream.

However I am speaking specifically to the articles bandwidth consumption claim.

It negates the gain for each individual switch, because yes, that client is still pulling 8 Mbps. But for the source to the first switch, it's still a 75% reduction in bitrate, no? 

But for the source to the first switch, it's still a 75% reduction in bitrate, no?

Yes, the traffic on the cable between the device’s outbound NIC and the first switch’s inbound port would be reduced as you say.

This is why it doesn’t make sense to multicast over the Internet.  


It would be great to see a table that identifies the capabilities of each manufacturer that supports multicast. As I understand it some only support server to client, some are capable of camera directly to client bypassing servers all together and as Michael pointed out there are others as well. 

We are planning on expanding that table to be more specific. We need to confirm some capabilities and will update.

Ethan, take your time with the table, as someone that is very familiar with many of these VMS platforms, it hard to get the truth/facts from sales people and marketing information. 

For example, based upon the Avigilon discussion at the beginning of this, if a consultant or potential customer asked Avigilon if they supported multicast - they would jump to say yes!, but from the above it is clear that that would not be a truly honest answer - because the point of the question for most would have been - do you support MC from the camera for viewing? 

We use to deal with this with ONSSI years ago.  Did the ONSSI VMS back then support MC, yes they would say.  But God is in the details I would say, they did but only on their most expensive version (which wasn't theirs) and only from the server - not the camera.

The point of MC is to be able to engineer a solution and know it will work i.e. that your customer will be able to have their system work as promised. 

For example a server based system with x amount of cameras that is recording and delivering video to clients works today but all of a sudden there is a crisis so 20 people log in to see x-amount of cameras, the server is simultaneously processing video motion/detection and through programming - cameras are now recording at 30 frames per second - boom, the server crashes.

Now if MC was enabled - those 20 clients trying to see video on a properly set-up network would have no impact to the server.

What is the impact of firewalls om multicast? Are there special considerations in that regard?

42 comments already, I have to weed through these comments.  But:

1.)  Level 3 switches do not exist but LAYER 3 switches do.  Routers can also perform the necessary function.  No, a L3 switch is NOT a router, some may interchange them but there are differences.

2.) Multicast works at Layer 2 and Layer 3.  IGMP Snooping is run at the L2 level to listen for requests and broadcasters.  At L3, they run PIM, it gets the job done but it's UGLY in larger designs.  WATCH your CPU levels on your L3 switch!  [Warning: Self-Promotion] Really if you get to this level, please call us (Dijkstra Solutions), if done wrong you can melt down networks.

3.) Software can have the function to listen and/or send multicast.  If it can listen then it can view OR record a stream independently of others.  If it can send then it will either send to other (multiple) viewers or recorders.

4.) Check if the software also supports IPv6 Multicast.  For large deployments, this can be very important, although there are work-arounds.

I have been told that some switches perform the multi-casting function better than others, based on whether there is a dedicated processor for the IGMP snooping, or just a software process.  Evidently, large video (data) streams can tax the switch.  Is this true?

I have been told that some switches perform the multi-casting function better than others, based on whether there is a dedicated processor for the IGMP snooping, or just a software process. Evidently, large video (data) streams can tax the switch. Is this true?

Yes, I think there is a distinct advantage in having your IGMP snoop enabled switch to have a dedicated ASIC for that purpose, assuming you intend a heavy multicasting deployment.


Consider that normally a layer 2 switch deals with frames, fast and efficiently.  However adding IGMP snoop is a whole ‘nother thing, as now the switch has to rise to the L3 level of constructing packets out of frames and deciphering multicast instructions.

They’re two mostly independent functions which are served well by paralellization.  If your IGMP gets bogged down, it will affect the switch in general by discarding packets, or as a fallback just multicast to all ports.


IGMP is L2 and usually not the problem, it's L3 and PIM.

PIM is really just ancient and as legacy as spanning tree.  IGMP simply listens for people wanting content or sending content and notifies others.  PIM knows how to send it across VLAN or broadcast networks.

99% of the time PIM is the problem, not IGMP.

Most switches will not have bandwidth issues these days, that is not a 100% rule, on a really busy switch, that is where the bigger vendors can do much better typically.  However, these days it not usually about bandwidth as per design requirement (vs. as required because of a vendor's architecture).

The reason why I say it that way, is because, for example, Cisco Nexus.  They have a FEX switch which is an extension from it's spine.  It needs a master switch connection.  In this design I could kill uplinks because of bandwidth saturation (all switching is done on the master switch, not the FEX.  The FEX are just ports...which is kind of dumb).

I hope I didn't over answer the question too much.

I hope I didn't over answer the question too much.

So is your answer to the question then, “No, not usually.”?

Size matters, lower scale, no doesn't matter. What size environment are we talking about?  IGMP though is not about size of the frame but rather about the number of messages.  Different manufacturers also matter though too.  From what I understand, Pelco, for example, is the most multicast intensive by default.  That will add more challenge to your registrations.  I would also say IGMP is more of a memory challenge than CPU (80/20 rule), typically.  This may not be the case in say, a casino, where all ports on the switch are carrying 2-4 feeds/groups.

Boys ... this is the best comment stream in a year for me ....  I am learning a ton! Keep it technical and respectful and keep it going !!


Article should have covered  type of multicast in details i.e how is  the support for audio video metadata for VMS/ Camera

Enough surprise to surprise.
From Japan.

Mitsubishi NVR and camera are pure multicast in Japan.
It was far from every standard.
We are the oldest Genetec distributor in the world. (2001 nDVR OEM by Genetec)
We have built a lot of multicast systems.
Wide area network camera stream is Unicast.
WiFi also Unicast by TCP.
Redirected to Multicast with Omnicast server.
This was a necessity item.
The general all-multicast construction itself does not change much from Unicast.

The difficult one is the L3 / L2 switch.
Maximum multicast group management is 300 cameras in 256 L2.
I do disturbing action.

Unstable even 1000 cameras to 1024 compatible switches.
If you change the manufacturer of the switch, immediate OK

Happy new year.

We Actually have has this set up in place for over 9 years and found many quarks in the process 

Mainly when we change or add solutions or upgrade cameras to newer versions 

added or changed network switch's and Poe switchs

The old with the New creates issues, all solvable , but requires lots of time to troubleshoot and think thru process's  

Started with 3 server's ( EV ) 

40 cameras all 1.3 mpxl ,all ACTI,  split between 3 nvrs with 4 different monitor out puts and multiple view stations or clients to review data and history

as we add new and replace the old it creates its own set of issues and needed upgrades  

very challenging 

splitting the out puts of cameras , changing from Jpeg, To Mpeg outputs, adjusting from variable to fixed out puts and changing from constant to variable record rates 

found that many of the cameras would not play well together and we added 

Vivotech, Panasonic, Arecont, Hikvision to the mix. 

Always challenging to see what , why, how to fix issues created by change or upgrade. 

Still have a few Analog HD or 480 line cameras that still work 

some to factory spec's and some being creative to fix quarky issues , not to spec 

But that s how we keep thing s up so as to go to 3-5 mpxl and still keep the old in place. 

still on Cat 5 e and still running thru high grade Switchs for maximum continuity only now with 65 cameras instead of 25 as in beginning 




Read this IPVM report for free.

This article is part of IPVM's 6,810 reports, 914 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now
Loading Related Reports