Without this part, analysing the video is a demonstration. Not a system.

A normal processor does few things at a time, very fast and in order. A graphics card does thousands of small operations at the same time. Looking at an image is exactly that: the same calculation repeated over every piece of the frame, over and over, thirty times a second and on every camera. That is why the same work that drowns a processor is done by a card without it noticing.

In a security installation that turns into something very concrete: you can analyse all the video at all hours, instead of analysing for a while or on a few cameras. It is the difference between a system that raises an alert when something happens and a demonstration that works with four cameras on the day of the visit and falls over when the fifth is switched on.

Video arrives compressed. Before anybody can look at it —a person or a program— it has to be decompressed: turning the stream into frames. That is done by that dedicated block on the card, it is very regular work and it can be calculated fairly well: it depends on how many cameras, at what resolution, at how many images per second and with what kind of compression.

Analysing is what comes afterwards and it is another world: passing every frame, or one in every few, through a model that decides what is in the image. That cost does not depend on the camera, it depends on WHAT is being asked. Counting how many people cross a line is cheap. Reading a number plate is dearer, because you have to find the plate and then read it. Recognising whether a person is wearing a hard hat and a high-visibility vest is more. And asking the system to describe a scene or to answer a question about what it sees is another order of magnitude.

The two jobs compete for the same card and they run out in different ways: one can run out of decoding block while it still has calculation to spare, and the other the other way round. That is why a number of the kind «this card takes so many cameras» means nothing without saying what is being analysed on each one.

The way to do it properly is to fit a card, the analytics software that is going to be used and the real video from that installation —not a demonstration video—, switch the cameras on in groups and watch three things: how much the decoding block is being used, how much the calculation is, and how much of the card's memory is occupied. You go up until one of the three falls short, and that is the limit of that card for that case.

Two warnings of the kind that only turn up by doing it. The first: the limit usually arrives through the card's memory before it arrives through speed, because every loaded model takes its own room and so does every open stream. The second: you have to test with the difficult scene and not the quiet one. A car park at four in the morning costs nothing; the same car park at the end of a shift, with forty people and twelve cars in the image, costs three times as much. The sizing is done with the worst moment of the day, because that is the moment when it has to work.

And there is an earlier decision that saves more than any card: not everything has to be analysed. Out of sixty cameras perhaps twenty deserve permanent analysis, fifteen only at night and the rest none. Deciding that with the client in the room halves the equipment and improves the result, because what is analysed is analysed properly.

It draws power, and a fair amount. The first thing is to add up: the card's consumption goes on top of the server's, and you have to check that the power supplies are still redundant with everything fitted —that is, that if one burns out, the other on its own can carry the lot—. If not, the redundancy was on paper and not in the machine. On top of that, some cards ask for their own power connectors, and that depends on the chassis and the power supply, not on the card.

And everything it draws comes out as heat. Many server cards do not have a fan of their own: they are cooled by the air the chassis pushes through them, which is why they cannot be put in just any box. If the airflow is not what the card expects, it does not break: it lowers its own performance so as not to burn, and the system runs at half speed without giving any error. It is one of the hardest faults to diagnose if you are not suspecting it. And all that heat goes on top of the cabinet's, which is another sum that has to be redone.

Almost no video project starts with analytics. What happens instead is that two years later somebody asks whether the system can raise an alert about something specific, and then the answer depends on decisions taken at the beginning without thinking about this: whether the chassis has a free slot of the right size, whether the power supply can take it, whether the air gets there, whether there is a free unit in the cabinet and whether the power backup has margin.

Reserving all of that on day one costs a small difference in the quotation. Not reserving it means changing the server, and changing the recording server means a shutdown, a migration of the configuration and a risk. That is why we always ask the question, even if the answer is not for now.

IRIS Neural is the video management system with artificial intelligence made by Infinity Neural, the other company in the group. That is to say: it is not a brand we are integrators of, it is in-house. We say so because recommending it without telling you that would be advertising dressed up as technical judgement.

It is relevant here because IRIS runs on these cards, and because sizing an installation with IRIS is exactly the conversation on this page: which cameras get analysed, what is asked of them, how many cards are needed for that and what power and what air the cabinet asks for. With the difference that there, it being our own product, we can take the measurement with the client's video before they buy anything.

If there is no analytics and none is planned, no. One of these cards in a server that only records is money, heat and consumption in exchange for nothing: it is no use for recording, because recording is writing to a drive. What does make sense in that case is leaving the space prepared, which costs next to nothing.

And we would not fit one to train models on an installation. Training and running are two very different jobs: training asks for far more equipment and is done once, somewhere else. What goes into a security installation is the running, which is the part that has to work every day. If somebody proposes training on the recording server, it is worth asking why.

The day-to-day is simple and any IT department does it: watching the temperature, the consumption and the use of the card, and getting that into the alerting system they already have. A card that starts losing performance through heat shows up on that graph months before anybody complains.

The agreement you need is about the driver. Here the version is not chosen by IT out of habit and it is not updated because a new one exists: it is set by the analytics software, which usually requires a particular range. Updating the driver without checking is the most repeated cause of analytics that used to work failing to start on a Monday. It is tested on one machine before the others are touched.