J'ai vu trop de caméras PTZ planter sous pression. La cause profonde ? Pas assez de RAM pour gérer ce que le système doit réellement faire en même temps.
La capacité de la RAM contrôle directement la stabilité d'une caméra PTZ lorsque plusieurs utilisateurs, NVR et fonctions d'IA tirent des flux vidéo en même temps. Plus de RAM signifie des tampons d'images plus grands, plus d'espace pour les connexions réseau et une meilleure résistance aux pics de latence, aux pertes d'images et aux plantages système lors d'un accès simultané.
Capacité de la RAM et accès multi-flux simultané dans les caméras PTZ
Dans cet article, je vais expliquer exactement comment La RAM dans les caméras de sécurité embarquées 1 fonctionne à l'intérieur d'une caméra PTZ lors d'un accès multi-flux. Je couvrirai les scénarios de plantage réels, la mécanique des tampons, les exigences de mémoire de l'IA et ce que vous devriez tester avant de passer une commande en gros. Si vous vous approvisionnez en caméras PTZ en provenance de Chine et que vos projets impliquent plusieurs NVR ou des spectateurs distants, c'est l'article que vous devez lire avant votre prochain achat.
Table des matières
Ma caméra va-t-elle planter si cinq utilisateurs essaient de regarder le flux 4K simultanément ?
J'ai reçu cette question exacte d'un intégrateur de systèmes au Texas l'année dernière. Il avait trois NVR et deux applications mobiles qui tiraient d'une seule caméra. La caméra continuait de se déconnecter toutes les quelques heures.
Oui, cela peut planter. Chaque spectateur simultané a besoin de son propre tampon réseau dans la RAM. Si la caméra n'a que 256 Mo de DDR, cinq connexions 4K simultanées peuvent remplir complètement la mémoire, provoquant l'effondrement de la pile réseau et le redémarrage de la caméra.
Plantage de caméra PTZ lors du streaming 4K simultané
Que se passe-t-il à l'intérieur de la caméra lorsque cinq utilisateurs se connectent ?
Chaque fois qu'un utilisateur ouvre une vue en direct, la caméra crée une nouvelle session TCP ou UDP. Chaque session a besoin de mémoire pour les données du socket, le réassemblage des paquets et une file d'attente d'envoi. Pensez-y comme à l'ouverture de cinq onglets de navigateur sur un vieil ordinateur portable : à un moment donné, le système se bloque tout simplement.
Voici ce que la caméra doit gérer en même temps :
- Encodage du flux principal (4K, H.265, 8–12 Mbps)
- Encodage du sous-flux (D1 ou 720p, 512 Kbps–2 Mbps)
- Cinq tampons d'envoi séparés, un pour chaque spectateur
- Traitement ISP (balance des blancs, réduction du bruit, WDR)
- Gestion du protocole RTSP/ONVIF pour chaque session
Comment la RAM est utilisée par connexion
| Composant | Utilisation approximative de la RAM par connexion | Notes |
|---|---|---|
| Tampon de socket TCP/RTSP | 2–8 Mo | Dépend des paramètres de l'OS |
| File d'attente d'envoi d'images | 10–30 Mo | Plus élevé pour le flux principal 4K |
| Surcharge de protocole (ONVIF, RTMP) | 1–3 Mo | Chaque protocole ajoute sa propre couche |
| Total par connexion | ~15–40 Mo | 5 utilisateurs = 75–200 Mo juste pour le réseau |
Sur une caméra avec seulement 256 Mo de DDR totale, ces cinq connexions seules pouvaient consommer 60 à 80 % de la mémoire disponible. Il ne reste presque rien pour l'encodage, l'ISP ou le noyau Linux lui-même. Le résultat est que le tueur OOM du noyau Linux 2 termine les processus pour survivre. Parfois, il tue le service de streaming. Parfois, il tue tout le système et redémarre.
Pourquoi le crash se produit souvent au pire moment
Le crash ne se produit généralement pas immédiatement. Il se produit lorsqu'il y a un pic. Une voiture traverse la scène, le débit binaire passe de 6 Mbps à 12 Mbps, et soudain, les cinq tampons d'envoi ont besoin du double d'espace. C'est le moment où la caméra manque de RAM et abandonne une ou plusieurs connexions, ou redémarre complètement.
Je dis toujours à mes clients : si votre projet nécessite plus de trois spectateurs simultanés, n'acceptez rien de moins que 512 Mo de DDR. Pour cinq ou plus, exigez 1 Go. La différence de coût sur la carte mère est faible. Le coût d'une intervention sur site distant pour redémarrer une caméra morte ne l'est pas.
2 Go de RAM offrent-ils une réponse PTZ plus fluide qu'un modèle standard de 512 Mo ?
J'ai effectué des comparaisons côte à côte dans notre laboratoire de Shenzhen. La différence de réponse PTZ est réelle, mais il ne s'agit pas seulement de la taille de la RAM, mais aussi de ce qui se bat pour cette RAM en même temps.
Une caméra avec 2 Go de RAM offre un contrôle PTZ sensiblement plus fluide sous forte charge car le système dispose d'une marge de mémoire suffisante pour que les commandes de contrôle moteur, l'encodage vidéo et le streaming réseau s'exécutent sans se disputer le même espace tampon limité.
Comparaison de la réponse PTZ entre les modèles 512 Mo et 2 Go de RAM
Pourquoi le contrôle PTZ semble lent sur les caméras à faible quantité de RAM
Lorsque vous envoyez une commande de panoramique ou d'inclinaison depuis votre joystick ou votre VMS, cette commande voyage sur le réseau, est analysée par le firmware de la caméra, puis déclenche le contrôleur moteur. Toute cette chaîne s'exécute en RAM. Sur une caméra qui utilise déjà 90 % de sa mémoire pour le streaming vidéo et l'IA, la commande PTZ doit attendre son tour. Vous appuyez sur “panoramique à gauche”, et la caméra répond une demi-seconde plus tard. En sécurité, une demi-seconde peut signifier perdre la trace d'un suspect.
Le véritable goulot d'étranglement : la contention de mémoire
Le problème n'est pas que le contrôle PTZ nécessite beaucoup de RAM en soi. Ce n'est pas le cas. Le problème est la contention de mémoire. Lorsque le bus DDR est occupé à déplacer de grandes images vidéo 4K entre l'ISP, l'encodeur et la pile réseau, les petits paquets de données de contrôle PTZ restent bloqués en attendant leur tour. Plus de RAM totale signifie que le système peut conserver des régions de mémoire séparées pour différentes tâches. Le contrôleur moteur obtient son propre espace. Le pipeline vidéo obtient son propre espace. Ils arrêtent de se marcher sur les pieds.
Pour une compréhension plus approfondie, lisez cette explication de la bande passante et de la contention de la mémoire DDR 3.
Ce que j'ai observé lors de nos tests en laboratoire
Nous avons effectué un test simple. Nous avions un modèle de 512 Mo et un modèle de 1 Go de la même famille SoC. Les deux diffusaient un flux principal 4K plus un sous-flux 720p. Les deux avaient une détection humaine de base en cours d'exécution. Nous avons envoyé des commandes continues de tour de préréglage PTZ tout en surveillant la latence de réponse.
- Le modèle de 512 Mo avait un temps de réponse moyen de 320 ms, avec des pics allant jusqu'à 800 ms lors de scènes à mouvement rapide.
- Le modèle de 1 Go a atteint une moyenne de 110 ms, avec des pics ne dépassant jamais 200 ms.
La leçon à retenir est claire. Si votre projet implique un suivi PTZ actif — en particulier avec le suivi automatique par IA — vous avez besoin de suffisamment de RAM pour que les commandes du moteur ne soient jamais ralenties.
Comment le tampon mémoire empêche-t-il la perte d'images lors d'un enregistrement à haut débit ?
J'ai regardé des enregistrements de chantiers où le moment le plus important — une effraction, une collision de véhicule — était le moment exact où la vidéo se transformait en un mur de pixels verts. C'est une perte d'images, et cela est presque toujours lié à la gestion du tampon.
Le tampon mémoire agit comme un amortisseur entre la sortie de l'encodeur et la vitesse d'écriture sur le réseau ou le stockage. Lorsque le débit binaire augmente lors de scènes complexes, un tampon RAM plus grand conserve ces images supplémentaires dans une file d'attente au lieu de les abandonner, évitant ainsi les artefacts d'écran vert et les images figées qui ruinent les séquences critiques.
Tampon mémoire empêchant la perte d'images lors d'un enregistrement à haut débit binaire
Comment fonctionne réellement le tampon d'images
À l'intérieur de la caméra, l'encodeur produit des images vidéo compressées à un débit variable. Dans une scène calme — un parking la nuit — le débit binaire peut se situer à 2 Mbps. Mais lorsqu'un camion passe, que les phares balaient l'image, que la pluie commence à tomber ou qu'une foule apparaît, le débit binaire peut passer à 10–15 Mbps en moins d'une seconde.
Le port réseau ne peut transmettre les données qu'à une vitesse fixe. Si l'encodeur produit soudainement plus de données que le réseau ne peut en envoyer, ces données supplémentaires doivent aller quelque part. Elles vont dans le tampon RAM. Si le tampon est suffisamment grand, les données attendent en toute sécurité jusqu'à ce que le réseau rattrape son retard. Si le tampon est trop petit, les images les plus anciennes sont écrasées ou les images les plus récentes sont jetées. Dans les deux cas, vous perdez des séquences.
Les mathématiques derrière la taille du tampon
Voici un aperçu simplifié de ce qui se passe lors d'un pic de débit binaire :
| Scénario | Pic de débit binaire | Vitesse du réseau | Tampon nécessaire pour un pic de 2 secondes |
|---|---|---|---|
| 1080p, scène calme | 4 Mbps → 8 Mbps | 100 Mbps (largement suffisant) | ~2 Mo |
| 4K, mouvement modéré | 8 Mbps → 20 Mbps | 100 Mbps (toujours OK) | ~5 Mo |
| 4K, scène complexe + pluie | 10 Mbps → 35 Mbps | 100 Mbps (le réseau est correct, mais la sortie de l'encodeur est en rafale) | ~9 Mo |
| 4K + 2 flux secondaires + IA | 15 Mbps → 40 Mbps au total | Réseau encombré ou Wi-Fi | ~15–25 Mo |
Ces chiffres sont par flux, par connexion. Multipliez par le nombre de spectateurs simultanés, et vous comprendrez pourquoi 256 Mo de RAM totale s'épuisent rapidement.
Pourquoi la “ gestion intelligente du tampon ” est aussi importante que la taille brute
Même avec suffisamment de RAM, le firmware doit bien la gérer. Un firmware mal écrit peut allouer un tampon fixe de 4 Mo par flux et ne jamais le redimensionner. Un firmware bien conçu ajuste dynamiquement la taille des tampons en fonction du débit binaire actuel et des conditions réseau. Chez Loyalty-Secu, notre firmware basé sur Linux utilise une allocation de tampon adaptative. Lorsqu'une augmentation du débit binaire est détectée, le système emprunte temporairement de la mémoire inutilisée à des tâches de priorité inférieure. C'est pourquoi nos caméras réussissent des tests de résistance de 72 heures sans aucune image perdue, même en 4K 30 ips avec trois spectateurs simultanés.
La RAM peut-elle gérer des métadonnées d'IA complexes tout en diffusant une vidéo 4K à 30 ips ?
On me pose cette question de plus en plus souvent, car chaque projet veut maintenant de l'IA : détection humaine, classification de véhicules, franchissement de ligne, capture de visages. La question n'est pas de savoir si l'IA fonctionne. La question est de savoir si elle fonctionne en même temps que tout le reste.
Oui, mais seulement si la caméra dispose de suffisamment de RAM pour contenir simultanément les poids du modèle d'IA, les tampons d'inférence par image et le pipeline de diffusion vidéo. Sur les caméras avec 512 Mo ou moins, l'activation de fonctionnalités d'IA complexes tout en diffusant en 4K à 30 ips entraîne souvent soit une baisse de la précision de l'IA, soit des saccades dans le flux vidéo.
Traitement des métadonnées d'IA aux côtés de la diffusion vidéo 4K
Où l'IA consomme de la RAM
Le traitement de l'IA sur une caméra n'est pas comme exécuter une application sur votre téléphone. La caméra charge l'intégralité du modèle de réseau neuronal en RAM au démarrage. Pour un modèle de détection humaine basique, cela peut représenter 20 à 50 Mo. Pour un modèle plus avancé qui détecte les humains, les véhicules et les visages, cela peut représenter 80 à 150 Mo. Et cette mémoire reste occupée pendant toute la durée de fonctionnement de la caméra.
En plus du modèle lui-même, le moteur d'IA a besoin de mémoire de travail pour chaque image qu'il traite :
- Tampon d'entrée vidéo : Une copie de l'image vidéo actuelle, mise à l'échelle à la taille d'entrée du modèle. Pour une image 4K réduite à 640×640, cela représente environ 1,2 Mo.
- Cartes de caractéristiques intermédiaires : Les couches à l'intérieur du réseau neuronal produisent des données temporaires pendant l'inférence. Cela peut utiliser 30 à 100 Mo selon la complexité du modèle.
- Tampon de métadonnées de sortie : Coordonnées des boîtes englobantes, étiquettes de classe d'objets, scores de confiance, identifiants de suivi. Petit par image, mais cela s'accumule lorsqu'il est stocké pour la recherche d'événements.
Le conflit entre l'IA et le streaming
Voici le problème principal. L'encodeur vidéo et le moteur d'IA doivent tous deux lire les mêmes images vidéo depuis la RAM. Sur un système à faible quantité de RAM, ils se disputent la bande passante DDR. Le contrôleur DDR ne peut traiter qu'une seule requête de lecture à la fois. Lorsque le moteur d'IA effectue un passage d'inférence intensif — lisant des millions de paramètres depuis la RAM — l'encodeur peut être bloqué pendant quelques millisecondes. À 30 ips, chaque image n'a que 33 ms. Un blocage de 5 ms signifie que l'encodeur manque son délai, et vous obtenez une image perdue ou un flux saccadé.
Comment nous résolvons ce problème chez Loyalty-Secu
Notre approche consiste à utiliser des SoC avec des chemins mémoire NPU (Neural Processing Unit) dédiés, combinés à 1 Go ou plus de DDR. Cela donne au moteur d'IA sa propre voie pour accéder à la RAM sans bloquer le pipeline vidéo. Nous optimisons également nos modèles d'IA par quantification — convertissant les poids flottants 32 bits en entiers 8 bits — ce qui réduit l'utilisation de la RAM du modèle de 75 % avec une perte de précision minimale.
En savoir plus sur Quantification de modèle pour l'IA en périphérie 4 pour comprendre comment cette technique réduit l'empreinte mémoire.
Ce que vous devez demander à votre fournisseur
Si une usine vous dit que sa caméra “ prend en charge l'IA ”, posez-leur ces questions :
- Quelle est la capacité totale de la DDR ?
- Combien de RAM le modèle d'IA consomme-t-il à l'exécution ?
- L'IA peut-elle fonctionner à pleine précision pendant que la caméra diffuse le flux principal 4K plus un sous-flux vers deux spectateurs simultanés ?
- Avez-vous testé cela dans un scénario de stress de 24 heures ?
S'ils ne peuvent pas répondre clairement à ces questions, la fonctionnalité IA est probablement une case à cocher sur une fiche technique, pas une capacité réelle.
| Capacité de la RAM | Capacité de l'IA | Stabilité du streaming 4K avec IA activée |
|---|---|---|
| 256 Mo | Détection de mouvement basique uniquement | Instable avec plus d'un spectateur |
| 512 Mo | Détection d'humains/véhicules | Stable avec 2 à 3 spectateurs, ralentissement occasionnel dans les scènes complexes |
| 1 Go+ | Suite IA complète (visage, véhicule, comportement) | Stable avec 5+ spectateurs, adapté aux projets de calcul en périphérie |
Pour une référence comparative, consultez cette comparaison des processeurs IA en périphérie pour la surveillance 5.
Conclusion
La capacité de la RAM est le facteur caché qui détermine si votre caméra PTZ reste stable ou plante lorsque des charges réelles multi-flux se présentent. Demandez les spécifications, effectuez les tests de résistance et ne vous fiez jamais uniquement à une fiche technique.
1. Comprendre les exigences de mémoire pour les SoC de vidéosurveillance. ︎↩︎ 2. Comment le noyau Linux termine les processus sous pression mémoire. ︎↩︎ 3. Note technique sur la bande passante et la contention de la mémoire DDR. ︎↩︎ 4. Guide TensorFlow Lite sur la quantification post-entraînement pour l'IA en périphérie. ︎↩︎ 5. Comparaison comparative des processeurs IA en périphérie pour la surveillance. ︎↩︎