Skip to content

WestPoint · Networks and communications

The picture is jumpy, and it is not the camera's fault.

Design, build and commissioning of the network everything travels over: cabling, fibre, switches, power over the network cable itself, network separation and the link to the outside. Nobody looks at it until it fails, and it decides whether a video system works or stutters along.

A badly sized network does not throw an error.

It drops frames. And nobody connects dropped frames to the network.

The call almost always starts the same way: the pictures look odd. They jump, sometimes they freeze for two seconds, and when you go back over a recording there are gaps. Nobody has touched anything. The recorder is not complaining. The cameras are all switched on.

The camera gets changed, and it carries on. The recorder gets changed, and it carries on. You ring the firm that fitted the cameras and they say the cameras are fine, and they are right: the problem is on the path between the two, and that path has no red light to come on. When a network runs tight, what it does is drop packets — and a video packet that gets dropped is never asked for again.

That is the awkward thing about networks: they do not fail, they degrade. They hold up on commissioning day, with twenty cameras and nobody else working. They start running tight the month they are extended to forty, or at the hour the company backup starts, or on the hot day when a switch shut inside a cabinet reaches forty-five degrees. The picture pays the bill.

Video is not office traffic.

And company networks are sized for office traffic.

A person working generates bursts: they open an email, download a file and then ask for nothing for ten minutes. An office network is designed for that — plenty of peak capacity and empty almost all the time.

A camera does exactly the opposite. It starts sending on the day it is switched on and never stops: the same bit rate, every hour, every day, in the middle of the night and in August too. It has no pauses. And it is not one: it is all of them at once, in the same direction and towards the same place, which is the recorder.

That is where the calculation nobody does comes from. Forty cameras sending four megabits per second is one hundred and sixty megabits constantly arriving at a recorder's port. On a gigabit link it looks like there is room to spare, until twenty cameras get added, the quality of a few is raised to read number plates and three people start watching live — which is outbound traffic on top of the inbound.

And the bit rate is not the one on the datasheet. A camera looking at an empty corridor compresses well and uses little; the same camera looking at a car park with trees moving at night can use three times as much. A network is sized for the worst hour of the day, not for the average.

A logistics unit next to the port seen from the air with the roof removed. Inside, in one corner, a plant room with equipment cabinets and a screen; from there blue lines run along a ceiling tray to three cabinets spread across the floor, and from those, orange lines out to the cameras on the perimeter poles. A dashed line crosses the street to the building opposite. In the background, the quayside cranes.

Why cameras do not go on the office network.

Putting them there costs nothing on day one. What it costs comes afterwards, and it comes from two different places.

The first is the noise. On a flat network everything lives together with nobody in charge: the constant video from the cameras, the nightly backup, the update that downloads itself onto fifty computers and the management video call. Whoever arrives late loses, and the video arrives late several times a day.

The second is more serious. A camera is a small computer hung on a pole, often out in the street, with its own software and its own passwords — and quite often with the password it came with from the factory, because changing two hundred passwords is work and nobody sees it. On a flat network, whoever reaches that camera has reached the accounts. It does not take anyone sophisticated: a cable within arm's reach in a car park is enough.

Separating the two means putting the cameras on their own network, deciding what may talk to what and closing off the rest. The recorder talks to the cameras. The security workstation talks to the recorder. The cameras do not talk to each other, do not go out to the internet and cannot see a single company computer. What is not permitted does not happen.

We almost never start from scratch: there is already a network and someone in IT who runs it and does not want two hundred devices inside it. They are right, and that conversation goes well if we turn up with the calculation done of how much traffic we are going to add and of what we will never ask of their network. And if the network that exists is not up to it, that gets said before signing and not in the third month.

Power down the same cable.

Powering the camera over the network cable saves half the installation. It is also where we have most often found the problem somebody else could not find.

Each camera draws a certain amount of power, and the switch feeding them has a total to share between all its ports. That total almost never covers every port at once drawing the maximum, and it is written in a line of the datasheet that few people read. Twenty-four ports is not twenty-four large cameras, and you have to leave headroom: in two years somebody is going to add two cameras on the ports that were spare.

Consumption is also not what is on the label. A camera with a heater and a zoom motor draws a good deal more on a freezing night than on the May afternoon when everything was tested. And that produces one of the hardest faults to find: some cameras restart in the small hours and by morning they are perfect, so nobody sees anything odd when they look.

And then there is the cable. A network cable that looks the same but is copper-clad aluminium carries the data and does not carry the power: it heats up, loses voltage along the way and the camera at the end of the run comes up short. There is no way to see it by looking, and it is one of the first things we check when an installation restarts on its own.

What gets decided in the network project.

Six decisions. None of them can be changed cheaply once the cable is in.

  • How far the copper reaches. A run works well up to about a hundred metres, and those hundred metres include what goes up the pole and what loops around inside the cabinet, which is always more than the drawing says. Past that you do not stretch it: an intermediate cabinet, or fibre.
  • When fibre is called for. Between buildings, always: as well as the distance, fibre does not carry electricity, and two buildings joined by copper also share their storms and their earth differences. A distant lightning strike has taken out more switches by that route than by any other. Inside a building, for the long distances and for the run joining cabinets, which is the one carrying everybody's traffic.
  • Which switches. A managed one lets you separate networks, see how much traffic goes through each port, shut a port down remotely and put the video ahead of the backup when it will not all fit — though priority does not create capacity: if the network is short, it only chooses who gets left out. An unmanaged one is a box that distributes and tells you nothing: the day there is a problem, there is nowhere to start looking.
  • What happens if a cable is cut. With everything hanging off a single route, cutting the run out of the cabinet leaves the whole branch blind. Closing the path into a ring, with two possible routes, means the network reassembles itself almost before anyone notices. Not everywhere: where going blind for an afternoon costs money.
  • How the addresses are handed out. Each camera with its own, always the same, written down and documented. When they are handed out automatically, one power cut is enough for two cameras to swap places: the images keep arriving, but what the recorder is saving as the loading bay is the changing room. It gets discovered months later, while looking for something else.
  • The link to the street. Watching the cameras from outside or alerting a receiving centre uses the upload side of the connection, which in almost every contract is the small one: a hundred megs down and ten up is ten for the video. And you have to decide how it is watched from outside — an encrypted tunnel into the camera network, not a camera published on the internet with its factory password.

What we do not do.

We do not put cameras on the company network to save ourselves a switch. There are small installations where sharing it is reasonable if the traffic is properly separated; what we do not do is do it for price and not say so.

We do not size on the average. A network calculated on the cameras' average bit rate works on average. The things that matter happen at night, in the rain, with everything moving and with someone watching live.

We do not leave a network undocumented. A cabinet with forty identical unlabelled cables turns every ten-minute fault into a two-hour fault, and that gets paid for over years.

And we are not the cheapest. The difference between a network that holds up and one that looks like it holds up is in material nobody sees and in calculation with no units, and both can be taken out of a quotation without anyone noticing until much later.

How you check it yourself.

Five things, with no technical knowledge, on the installation you already have.

  • Open the cabinet where the camera switch is and feel the air. If it is closed, hot and dusty, there is a problem there waiting for the first hot day — and a switch that roasts does not warn you, it restarts.
  • Ask whether the cameras are on a network separate from the computers. If nobody knows for certain, they are not.
  • Ask for the list of which camera has which address and which port of which switch it is plugged into. If it does not exist, every fault is going to start by building it.
  • Watch a recording from the busiest hour and one from the small hours at the same place, one after the other. If the busy-hour one is jumpy and the other is not, it is not the camera.
  • Ask what happens if the cable to the building next door is cut. The answer has to be a sentence, not a facial expression.

The twenty brands we build networks with.

And one thing up front, because in networks it is the one that matters most: there is almost always already an IT team with its own judgement and its own brand. Turning up and imposing ours is the fastest way to stall a project — we adapt to the network that is there, and when it genuinely will not do, we explain why.

What people ask about the network.

The ones that come up most. There are 28 on this subject, and the other 22 are in the question index.

All the questions, by subject
Why did the office network start playing up when we fitted cameras?

Because video is nothing like anything that was on that network before. A person working generates bursts: they open an email, download a file and then ask for nothing for ten minutes. An office network is sized for that, plenty of peak capacity and empty almost all the time. A camera does exactly the opposite: it starts sending on the day it is switched on and never stops, the same bit rate, every hour, in the middle of the night and in August too.

And it is not one. It is all of them at once, in the same direction and towards the same place, which is the recorder. That is where the path narrows, and where a network that looked more than adequate starts discarding packets.

A video packet that gets discarded is never asked for again. That is why the symptom is not an error message but jumpy images and gaps in the recording that nobody connects to the network.

Networks: why video saturates them

What exactly happens to an ordinary network when you plug cameras into it?

It degrades instead of failing, which is what makes it hard to diagnose. It holds up on commissioning day, with twenty cameras and nobody else working. It starts running tight the month they are extended to forty, or at the hour the company backup starts, or on the hot day when a switch shut inside a cabinet reaches forty-five degrees.

Meanwhile no red light comes on. The recorder is not complaining, the cameras are all switched on and nobody has touched anything. The camera gets changed and nothing changes; the recorder gets changed and nothing changes, because the problem is on the path between the two.

The quickest way to confirm it without instruments is to watch a recording from the busiest hour and one from the small hours at the same place, one after the other. If the busy-hour one is jumpy and the other is not, it is not the camera.

Networks: why video saturates them

How much bandwidth does a camera use?

It depends on four things, and it is calculated before buying anything: the resolution, the frames per second, the codec it compresses with and —the one that matters most and gets looked at least— what is in front of it. With those four you estimate; with the camera installed you measure, which is the only thing that counts.

An example, and it is only an example: a four-megapixel camera at twelve frames per second compressing in H.265, looking at an indoor corridor almost nobody walks down, might sit around three megabits per second. The same camera pointing at a car park with trees moving at night can go to three times that, because the compressor has to redraw far more of the image. The figure for your installation is neither of those two: it is whatever comes out of your scene.

Datasheets give a theoretical maximum or an average laboratory figure, and you cannot size a network with either. You size for the worst hour of the day, which is at night, in the rain, with everything moving and with someone watching live.

Networks: how they are sized for video Cameras: resolution and what each one uses

How do you calculate the bandwidth for the whole installation?

You add up the peak bit rate of each camera —not the average— and look at where that total has to pass. The calculation is done section by section, not once: the uplink of each access switch, the link between cabinets, the port everything arrives at on the recorder and the route out to the internet if it is watched from outside.

An example with example numbers: forty cameras at a peak of four megabits per second is one hundred and sixty megabits constantly arriving at the recorder's port. On a gigabit link it looks like there is room to spare, until twenty cameras get added, the quality of a few is raised to read number plates and three people start watching live, which is outbound traffic on top of the inbound.

The classic mistake is in the middle section: a twenty-four-port gigabit switch with a single gigabit link back to the main cabinet can receive far more than it can send out. With computers you do not notice, because nobody works at the same time. With cameras you do. And on top of all that you leave headroom for the cameras that are going to arrive, because they always do.

Networks: how they are sized for video Engineering: sizing before buying

What changes between H.264 and H.265?

H.265 compresses a good deal better: with the same image and the same scene it can sit around half the bit rate of H.264. How much it really drops depends on what is being recorded and on how the camera is configured, so it is an estimate for the project, not a promise for the contract.

What costs is decompressing. A mosaic of sixteen cameras in H.265 asks more of the viewing workstation and of the server than H.264 does, and there are older recorders and clients that simply will not play it. That is why the codec is not chosen by looking at the camera alone: it is chosen by looking at the whole chain.

And almost every manufacturer has its own smart compression on top, which drops the bit rate a lot on still scenes and almost not at all on busy ones. It helps, but it is worth checking that the recorder understands it and that it does not ruin the image exactly when something happens, which is when you need it.

Networks: how they are sized for video Cameras: compression and image quality

Why do two cameras of the same model use different amounts?

Because of the scene. A video compressor mainly stores what changes from one image to the next: if nothing changes, it generates almost no data; if everything changes, it generates a great deal. A camera looking at a closed door and one looking at a car park with trees are the same device doing two jobs that are nothing alike.

Two surprising things follow. The first is that outdoor cameras are almost always the expensive ones in bit rate. The second is that the peak comes at night: in low light the sensor puts grain into the image, and grain is change, so the compressor treats it as movement and swells. Rain, snow and leaves in the wind do the same.

That is why a network calculated on the cameras' average bit rate works on average, and the things that matter do not happen on average.

Networks: why video saturates them Cameras: what changes with the scene

Get started

Are the pictures jumpy?

Tell us how many cameras there are, where they run, what switches are installed and what time of day the problem shows. With that we can tell you whether what is missing is network or something else. If it is something else, we will tell you that too.