Il n’existe pas de nombre fixe et fiable de flux vidéo qu’un serveur NVR domestique peut gérer dans tous les cas. Un serveur qui enregistre huit flux compressés peut être moins sollicité qu’un autre qui décode et analyse quatre flux haute résolution. Le dimensionnement doit prendre en compte trois charges distinctes — la bande passante d’enregistrement, le décodage vidéo et la détection d’objets — puis être vérifié en fonction de la durée de conservation et du nombre de caméras susceptibles d’être actives simultanément.
Répartissez chaque caméra entre les charges d’enregistrement, de visualisation et de détection
Une caméra peut générer plusieurs charges de travail, même s’il s’agit physiquement d’un seul appareil. Le NVR peut stocker un flux principal de haute qualité, décoder un sous-flux de résolution inférieure pour la détection et rediffuser un autre flux pour la visualisation en direct. Considérer ces trois tâches comme un seul « canal caméra » masque le travail réellement effectué par le serveur.
Axis explique pourquoi l’efficacité des codecs de vidéosurveillance modifie les besoins en bande passante et en stockage. H.264, H.265 et les codecs plus récents peuvent fournir des débits très différents pour une qualité visuelle similaire. Le nombre de flux, sans indication du codec et du débit binaire, ne suffit donc pas pour dimensionner le système.
Le guide de ZimaSpace consacré à la création d’un serveur NVR local définit clairement l’architecture : flux de caméra, chemin réseau, environnement d’exécution de l’application, stockage des enregistrements et accès distant sont des éléments distincts du système.
Créez une feuille de calcul avec une ligne par caméra et des colonnes indiquant la résolution d’enregistrement, le débit d’enregistrement, la résolution de détection, le nombre d’images par seconde pour la détection, les besoins en visualisation en direct et la disponibilité d’un décodage matériel. Cette feuille sera plus utile que toute affirmation selon laquelle un processeur donné prend en charge un nombre universel de caméras.
Les flux destinés uniquement à l’enregistrement posent généralement un problème de stockage et de réseau
Si le NVR écrit les flux déjà encodés par les caméras sans les décoder ni les réencoder, la charge du processeur peut rester relativement faible. Les principales limites deviennent alors le débit réseau global, les écritures soutenues sur les disques, la surcharge du système de fichiers et la concurrence éventuelle entre la lecture ou l’exportation et les enregistrements entrants.
Le guide actuel de Reolink sur les résolutions montre comment la résolution et la compression modifient les besoins de stockage des caméras. Un flux haute résolution n’a pas un débit fixe : la complexité de la scène et les choix d’encodage jouent également un rôle.
Mesurez le débit global au lieu de multiplier le nombre de caméras par une valeur générique. Additionnez le débit maximal attendu de tous les flux enregistrés en continu, puis prévoyez une marge pour la lecture, les exports, les vignettes, les opérations de base de données et les pointes temporaires. Le réseau et le stockage doivent rester largement en dessous de la saturation pendant ces tâches combinées.
Un processeur modeste peut donc enregistrer de nombreux flux si le serveur se contente principalement de recevoir et d’écrire des vidéos compressées. La situation change lorsque le NVR doit décoder chaque flux, redimensionner les images, générer des aperçus, transcoder les flux destinés aux clients ou effectuer une analyse vidéo continue.
Le décodage matériel modifie la limite de caméras avant même la détection par IA
Le décodage vidéo peut mobiliser une part importante du processeur généraliste lorsque plusieurs flux haute résolution sont traités par logiciel. Un processeur graphique intégré ou un autre moteur vidéo matériel peut supprimer une grande partie de cette charge de décodage. C’est pourquoi deux serveurs dotés d’un nombre similaire de cœurs peuvent prendre en charge des charges NVR très différentes.
Un test de Tom’s Hardware consacré à une plateforme Intel N100 avec circuit graphique intégré présente une catégorie matérielle couramment utilisée dans les serveurs domestiques basse consommation : quatre cœurs de processeur, un iGPU et un stockage local rapide. Le point important est le moteur multimédia, et non les performances en jeu.
La détection d’objets constitue un chemin distinct du décodage. Un accélérateur peut traiter efficacement l’inférence, tandis que le serveur doit toujours recevoir et décoder les images avant de les transmettre au détecteur. Ne supposez pas que l’ajout d’un Coral, d’un GPU ou d’un autre dispositif d’IA élimine tous les goulots d’étranglement liés au processeur et au traitement vidéo.
Pour un test d’achat, désactivez d’abord la détection et mesurez l’enregistrement ainsi que le décodage. Activez ensuite la détection au nombre d’images par seconde prévu et surveillez l’utilisation du processeur, du GPU et de l’accélérateur, les images perdues et la latence de détection. Vous pourrez ainsi identifier précisément la limite matérielle qui nécessite une mise à niveau.
La durée de conservation peut imposer un serveur plus grand avant même les besoins de calcul
Un NVR domestique peut disposer d’une large marge de traitement et rester un mauvais choix s’il ne peut pas conserver la durée d’enregistrement souhaitée. La vidéo continue est une charge d’écriture soutenue, et la capacité requise augmente directement avec le débit global et la durée d’enregistrement.
L’analyse de Backblaze sur le stockage de vidéosurveillance explique comment le nombre de caméras, le débit binaire et la durée de conservation déterminent les besoins en stockage. Ces variables doivent être calculées avant de choisir le nombre de baies ou de supposer qu’un petit disque d’enregistrement suffira.
Le guide d’achat de ZimaSpace consacré à l’isolation des enregistrements de caméras ajoute une question de fiabilité : une charge NVR ne doit pas pouvoir priver les services domotiques essentiels de ressources lorsque le stockage est plein ou que l’analyse connaît des pointes d’activité.
Si une configuration à deux disques atteint trop rapidement la limite de conservation, l’ajout de baies peut être justifié même lorsque l’utilisation du processeur reste faible. Il s’agit d’une mise à niveau de la capacité de stockage, et non d’une preuve que la plateforme de traitement des caméras nécessite davantage de puissance de calcul.
Testez l’activité simultanée, pas une scène vide
L’analyse des caméras est irrégulière, car toutes les vues ne contiennent pas simultanément des mouvements ou des objets. Un test nocturne dans un environnement calme peut masquer la charge qui apparaît lorsque les membres de la famille arrivent, que des voitures circulent dans l’allée, que des animaux traversent plusieurs zones et que des vues en direct sont ouvertes en même temps.
Les tests de StorageReview sur les NVR ont montré que plusieurs enregistrements de caméras simultanés peuvent être gérés confortablement lorsque le chemin d’enregistrement dispose d’un débit soutenu suffisant, tout en conservant une marge pour la lecture et l’accès réseau. La leçon à retenir est de tester l’état combiné, et non l’état au repos.
Créez une scène correspondant au pire cas en ouvrant le tableau de bord en direct, en déclenchant des mouvements dans plusieurs zones, en exécutant la détection d’objets et en exportant ou en lisant des séquences récentes, tout en continuant à enregistrer toutes les caméras. Surveillez la latence de décodage, la latence d’inférence, les images perdues, la profondeur de file d’attente des disques et l’utilisation du réseau.
Si le système reste stable, l’ajout d’une caméra supplémentaire devient une décision de capacité mesurable. Si une ressource partagée est déjà proche de la saturation, mettez d’abord cette ressource à niveau au lieu de remplacer l’ensemble du NVR en vous basant uniquement sur le nombre de caméras.
Adaptez le NVR au matériel Zima selon l’échelle d’enregistrement et la charge d’analyse
Pour un NVR domestique modeste, où un petit nombre de caméras sont enregistrées localement et où l’analyse reste limitée, ZimaBoard 2 1664 constitue le modèle ZimaBoard 2 le plus adapté, car sa mémoire supplémentaire offre davantage de marge aux logiciels de caméra, aux bases de données et aux conteneurs associés. Son port PCIe peut également être réservé à un accélérateur si la détection locale fait partie du projet.
N’attribuez pas un nombre fixe de caméras à la carte sans tester les flux réels. La résolution, le codec, le débit binaire, le chemin de décodage et le nombre d’images par seconde de la détection peuvent modifier trop fortement la charge pour permettre une évaluation universelle. Utilisez la feuille de calcul et le test de charge combinée décrits plus haut comme critères de validation.
Passez à ZimaCube 2 lorsque la durée de conservation, le nombre de baies, l’enregistrement simultané plus intensif ou les besoins de stockage plus importants du foyer constituent une raison distincte de choisir un NAS à plusieurs baies. Choisissez le Creator Pack uniquement lorsqu’un calcul GPU dédié répond à un besoin réel d’analyse, et non simplement parce que le mot « IA » apparaît dans le logiciel NVR.
Le meilleur achat pour un NVR est le plus petit système qui réussit le test de caméras réaliste le plus exigeant, tout en conservant une marge de stockage, de réseau et de calcul. Le nombre de caméras n’est qu’une étiquette ; le pipeline de flux constitue la véritable charge de travail.
FAQ
Faut-il compter une caméra 4K comme quatre caméras 1080p ?
Non. Le nombre de pixels ne suffit pas à déterminer la charge du serveur. Le débit binaire, le codec, la fréquence d’images, la conception du sous-flux, le décodage matériel et la résolution d’analyse jouent tous un rôle. Traitez chaque caméra comme un ensemble mesuré de flux d’enregistrement et de détection, plutôt que de convertir la résolution en un nombre fixe de caméras équivalentes.
Un accélérateur d’IA augmente-t-il le nombre de caméras que je peux enregistrer ?
Pas automatiquement. Un accélérateur peut augmenter la capacité de détection d’objets, mais l’enregistrement dépend toujours du débit réseau et du débit d’écriture du stockage, tandis que le décodage vidéo peut encore dépendre du processeur ou du circuit graphique intégré. Il augmente la limite uniquement lorsque l’inférence constitue l’étape limitante.
Guide d'achat
Plus à lire

Comment traduire les caractéristiques du processeur, de la RAM et des IOPS en performances Plex
Un guide d’achat pour convertir les mesures de charge de travail de Plex en exigences minimales en matière de processeur, de RAM, de stockage...

Comment présélectionner des serveurs domestiques pour Plex à l’aide de critères pondérés
Une matrice d’achat Plex reproductible qui sépare les critères obligatoires des préférences et met en évidence les incertitudes avant l’achat.

Quel cycle de support et de mise à niveau un serveur Plex doit-il offrir ?
Une méthode d’évaluation réussite ou échec pour l’achat, couvrant la prise en charge des serveurs Plex, l’historique des mises à jour, la compatibilité, la...

