Si vous utilisez Caméras PTZ8 sur la 4G dans des zones reculées, vous connaissez la douleur. Les paramètres vidéo par défaut créent un décalage qui donne l'impression que le contrôle panoramique/inclinaison est cassé. J'ai passé des mois à lutter contre ce problème exact.
Oui, vous pouvez personnaliser entièrement la structure GOP pour obtenir une latence extrêmement faible. En raccourcissant la longueur de la GOP pour correspondre à votre fréquence d'images, en désactivant les B-Frames et en utilisant l'encodage Intra-Refresh, vous pouvez réduire le délai de streaming de plusieurs secondes à moins de 300 ms, même sur des connexions 4G instables.
Personnalisation de la structure GOP pour le streaming PTZ 4G à faible latence
Ci-dessous, je détaille les quatre questions les plus fréquentes que me posent les intégrateurs de systèmes concernant le réglage de la GOP. Chaque réponse comprend des valeurs de configuration réelles et les compromis que vous devez connaître avant de modifier quoi que ce soit sur le terrain.
Table des matières
Un réglage de “GOP=1” (toutes les I-Frames) éliminera-t-il le décalage lors des panoramiques PTZ à haute vitesse ?
J'ai testé GOP=1 sur des déploiements 4G en direct. Le résultat m'a surpris. Cela a réduit le délai de décodage, mais a également créé un nouveau goulot d'étranglement qui a aggravé les choses dans certains cas.
Définir GOP=1 éliminera presque complètement le décalage côté décodage, mais cela inondera votre liaison montante 4G avec des rafales de données massives. Sur une connexion stable, cela fonctionne. Sur une cellule 4G faible ou congestionnée, le pic de bande passante provoque une perte de paquets et crée encore plus de saccades qu'une GOP plus longue.
Impact de la bande passante GOP=1 toutes les I-frames sur la caméra PTZ 4G
Pourquoi GOP=1 semble parfait en théorie
Quand chaque image est une Cadre interne1, le décodeur n'attend jamais une image de référence. Si un paquet est perdu, l'image suivante est une image complète. Il n'y a aucune dépendance entre les images. Cela signifie :
- Aucune propagation d'erreur (un paquet perdu ne peut pas corrompre les 2 secondes de vidéo suivantes)
- Temps de commutation de canal instantané (le spectateur voit une image immédiatement)
- La réponse PTZ semble directe et en temps réel
Pourquoi GOP=1 échoue sur les réseaux 4G réels
Voici le problème. Une I-Frame est typiquement 5 à 10 fois plus grande qu'une Image P2. Si votre caméra diffuse à 4 Mbps avec un GOP normal de 25, passer à GOP=1 peut pousser la bande passante requise à 15-25 Mbps. La plupart des 4G9 liaisons montantes dans les zones reculées fournissent au mieux 2-8 Mbps.
Lorsque l'encodeur envoie image après image d'I-Frames pleine taille, le tampon du modem 4G se remplit. Les paquets s'accumulent. La latence augmente, pas diminue. Vous obtenez le contraire de ce que vous vouliez.
Le point idéal pratique
Au lieu de GOP=1, je recommande de définir GOP égal à votre valeur FPS. Cela vous donne une I-Frame par seconde.
| Paramètre GOP | Impact sur la bande passante | Temps de récupération après perte de paquet | Meilleur cas d'utilisation |
|---|---|---|---|
| GOP = 1 | Augmentation de 5 à 10 fois | 0 ms (instantané) | LAN filaire uniquement |
| GOP = FPS (25-30) | Augmentation de 1,3 à 1,5x | 1 seconde maximum | PTZ à distance 4G |
| GOP = 50-100 | Base de référence | 2-4 secondes | Stockage/enregistrement |
Quand GOP=1 a vraiment du sens
Si votre site dispose d'une unité de liaison 4G dédiée (combinant 2-4 cartes SIM) avec un débit montant garanti de 20+ Mbps, alors GOP=1 est viable. Je l'ai déployé pour des projets de surveillance autoroutière où le client a payé des forfaits de données premium. Pour les déploiements solaires standard à carte SIM unique, c'est excessif et contre-productif.
La vraie réponse pour le décalage de panoramique PTZ est : GOP = FPS, B-Frames = 0, et activer Intra-Refresh. Cette combinaison vous offre une latence de bout en bout inférieure à 500 ms sans détruire votre budget de données.
Quelle quantité de données 4G supplémentaires une structure GOP courte consommera-t-elle par rapport à la valeur par défaut ?
Chaque client avec lequel je travaille pose cette question avant de modifier des paramètres. Le coût des données représente de l'argent réel, surtout sur les sites solaires distants où vous payez par gigaoctet. Je fais toujours les calculs avec eux avant d'apporter des modifications.
Un GOP court (égal au FPS) augmentera votre consommation de données 4G mensuelle d'environ 30 à 50 % par rapport au GOP par défaut de 50 à 100. Pour un flux typique de 2 Mbps fonctionnant 24h/24 et 7j/7, cela signifie environ 200 à 300 Go supplémentaires par mois. Le compromis en vaut la peine pour une utilisation active du PTZ, mais vous devriez utiliser une configuration à double flux pour contrôler les coûts.
Comparaison de la consommation de données 4G : structure GOP courte vs longue
Comprendre pourquoi un GOP plus court coûte plus cher en données
Le calcul est simple. Les I-Frames transportent les données complètes de l'image. Les P-Frames ne transportent que la différence par rapport à l'image précédente. Lorsque vous augmentez le nombre d'I-Frames, vous augmentez le volume total de données.
Voici un exemple concret d'un déploiement que j'ai mesuré l'année dernière :
- Résolution du flux : 1080p à 25 IPS
- Débit cible (VBR) : 2 Mbps en moyenne
- GOP = 100 (par défaut) : Une image I toutes les 4 secondes. Données mensuelles = ~648 Go
- GOP = 25 (optimisé) : Une image I toutes les 1 seconde. Données mensuelles = ~850-970 Go
Répartition des coûts de données réels
| Configuration | Débit moyen | Données mensuelles (24h/24, 7j/7) | Données mensuelles (12h/jour) | Coût supplémentaire par rapport au défaut |
|---|---|---|---|---|
| GOP=100, B=2 | 1,8 Mbps | ~583 Go | ~291 Go | Base de référence |
| GOP=25, B=0 | 2,5 Mbps | ~810 Go | ~405 Go | +39% |
| GOP=1 (Tout-I) | 8-12 Mbps | ~2,592-3,888 Go | ~1,296-1,944 Go | +345-567% |
Comment contrôler les coûts de données avec un GOP court
Trois stratégies que je recommande à chaque intégrateur :
Stratégie 1 : Enregistrement piloté par événement Ne diffusez pas 24h/24 et 7j/7 avec un GOP court. Utilisez la détection de mouvement ou les déclencheurs IA pour activer le flux à faible latence uniquement lorsque quelque chose se produit. Pendant les périodes d'inactivité, la caméra peut chuter à 0,5 ips ou arrêter complètement la diffusion.
Stratégie 2 : Architecture à double flux Exécutez deux flux simultanément :
- Flux principal (pour l'enregistrement) : GOP=100, 2 Mbps, H.265. Ceci va à votre NVR ou stockage cloud.
- Flux de prévisualisation (pour le contrôle PTZ en direct) : GOP=25, 1 Mbps, H.264. C'est ce que l'opérateur voit en temps réel.
Stratégie 3 : Commutation dynamique du GOP Notre firmware prend en charge l'ajustement automatique du GOP. Lorsque l'opérateur ouvre la vue en direct et commence le contrôle PTZ, le GOP descend à 15-25. Lorsque personne ne regarde, il revient à 100. Cela seul peut économiser 60-70 % des coûts de données supplémentaires.
Une note sur H.265 par rapport à H.264
H.2653 (HEVC) compresse les images I environ 30-40 % mieux que H.264. Si votre VMS prend en charge le décodage H.265, utilisez-le toujours pour le flux principal. Les économies de bande passante compensent partiellement le coût d'un GOP plus court. Cependant, pour le flux de prévisualisation en direct, H.264 est souvent préférable car il se décode plus rapidement côté client, ce qui est important pour la latence.
Puis-je définir une GOP différente pour le “flux principal” et le “flux de prévisualisation” ?
C'est l'une des premières choses que je configure sur chaque caméra que nous expédions. L'exécution d'un seul flux pour l'enregistrement et la visualisation en direct est un compromis qui nuit aux deux cas d'utilisation. Je les sépare toujours.
Oui, absolument. Nos caméras prennent en charge des paramètres d'encodage indépendants pour le flux principal et le flux secondaire/de prévisualisation. Vous pouvez définir GOP=100 sur le flux principal pour un stockage efficace, tout en exécutant GOP=25 sans images B sur le flux de prévisualisation pour un contrôle PTZ en temps réel. Chaque flux a sa propre instance d'encodeur sur la puce ISP.
Configuration du GOP en double flux : flux principal par rapport au flux de prévisualisation
Comment fonctionne l'encodage en double flux au niveau matériel
Les SoC de surveillance modernes (comme le HiSilicon Hi3536 ou des puces similaires que nous utilisons) disposent de plusieurs canaux d'encodage matériel. Chaque canal fonctionne indépendamment. Cela signifie :
- L'encodeur Main Stream peut fonctionner en H.265, résolution 4K, GOP=100, avec 2 B-Frames
- L'encodeur Sub Stream peut fonctionner en H.264, 720p ou 1080p, GOP=25, avec 0 B-Frames
- Aucun flux n'affecte les performances de l'autre
L'ISP capture l'image complète du capteur une fois, puis l'envoie aux deux encodeurs à leurs résolutions respectives. Il n'y a aucune pénalité de performance pour l'exécution de deux flux avec des paramètres GOP différents.
Configuration recommandée en double flux
| Paramètres | Flux principal (Enregistrement) | Flux de prévisualisation (PTZ en direct) |
|---|---|---|
| Codec | H.265 | H.264 |
| Résolution | 4K ou 1080p | 720p ou 1080p |
| Fréquence d'images | 25 IPS | 25 IPS |
| GOP | 100 | 25 |
| B-images | 0-2 | 0 |
| Mode de débit binaire | VBR5 avec cap | CBR6 |
| Bitrate | 4-6 Mbits/s | 1-1,5 Mbps |
| Profil | Principal | Baseline ou Main |
Pourquoi cela est important pour l'intégration de votre VMS
La plupart des plateformes VMS professionnelles (Milestone, Genetec, Blue Iris) peuvent s'abonner à différents flux pour différents usages. Lorsqu'un opérateur ouvre une caméra dans une vue en grille, le VMS récupère le sous-flux. Lorsqu'il double-clique pour passer en plein écran ou démarrer le contrôle PTZ, il bascule vers le flux principal ou le flux de prévisualisation optimisé.
Il ne s'agit pas seulement d'économiser de la bande passante. Il s'agit de fournir les bonnes données à la bonne tâche :
- Besoins d'enregistrement : Haute résolution, haute efficacité de compression, GOP long pour des tailles de fichiers réduites
- Besoins de visualisation en direct : Faible latence, récupération rapide des erreurs, GOP court pour un contrôle réactif
- Besoins d'analyse IA : Livraison cohérente des images, pas de retards de réorganisation des B-Frames
Comment configurer cela via ONVIF
Si votre VMS utilise ONVIF Profil S4, vous pouvez définir ces paramètres à distance via la configuration du profil multimédia. Chaque profil multimédia ONVIF correspond à une instance d'encodeur. Vous créez deux profils — un pour l'enregistrement, un pour le direct — et attribuez des valeurs GOP différentes à chacun. Nos caméras exposent tous les paramètres GOP et B-Frame via l'interface ONVIF, vous n'avez donc pas besoin de vous connecter à l'interface Web de la caméra pour apporter des modifications.
Pour les intégrateurs qui utilisent notre SDK ou les commandes CGI directement, l'appel API est simple. Vous spécifiez le numéro de canal (0 pour principal, 1 pour secondaire) et définissez le IntervalleIFrame paramètre indépendamment pour chacun.
L'ISP (processeur de signal d'image) permet-il des modes de traitement d'images à “latence nulle” ?
Je reçois cette question des CTO qui ont lu des informations sur l'encodage “ zéro latence ” dans la documentation de l'encodeur logiciel x264/x265. Ils veulent savoir si le processeur de signal d'image (ISP) matériel de nos caméras peut faire la même chose. La réponse est nuancée.
L'ISP lui-même ajoute un délai quasi nul (moins de 5 ms) au pipeline d'images. La latence réelle réside dans l'encodeur, le tampon réseau et le décodeur. Notre ISP prend en charge un mode “ faible latence ” qui désactive la réorganisation des images et l'analyse prédictive, ramenant la latence côté encodage à une seule période d'image (40 ms à 25 FPS). Le “ zéro délai ” véritable est physiquement impossible, mais une latence d'encodage inférieure à 100 ms est réalisable.
Mode de traitement d'images zéro délai ISP pour caméra PTZ
Décomposition de la chaîne de latence
Pour comprendre ce que signifie “ zéro délai ” en pratique, vous devez voir où le temps est passé dans le pipeline complet :
- Exposition du capteur : 1-40 ms (dépend de la vitesse d'obturation)
- Traitement ISP (démosaicage, débruitage, WDR) : 3-8 ms
- Mise en mémoire tampon d'entrée de l'encodeur : 0-80 ms (dépend des paramètres B-Frame et look-ahead)
- Encodage d'une image : 5-15 ms
- Paquétisation réseau (RTP/RTSP) : 1-5 ms
- Tampon modem 4G : 20-80 ms
- Transit réseau : 30-100 ms (dépend de la distance de la station de base et du routage)
- Tampon de gigue côté client : 40-200 ms
- Décodeur : 5-20 ms
- Rendu d'affichage : 8-16 ms (dépend du taux de rafraîchissement du moniteur)
L'ISP contrôle les étapes 2 et partiellement l'étape 3. Lorsque les gens parlent de “ mode ISP zéro latence ”, ils entendent par là que l'ISP transmet chaque image à l'encodeur immédiatement après le traitement, sans conserver les images pour la réduction du bruit temporel ou la HDR par empilement d'images.
Ce que le “ Mode Faible Latence ” désactive réellement
Lorsque vous activez le mode faible latence sur nos caméras, les changements suivants se produisent dans l'ISP et l'encodeur :
- Réduction du bruit 3D temporelle : Réduit de référence 3 images à référence 1 image. Cela augmente légèrement le bruit de l'image dans les scènes sombres mais économise 80 ms de mise en mémoire tampon.
- Réorganisation des images : Complètement désactivé. Aucune image B ne peut être générée.
- Anticipation du contrôle de débit : Désactivé. L'encodeur ne peut pas “regarder” les images futures pour optimiser l'allocation du débit binaire. Cela rend le débit binaire moins fluide mais élimine le délai d'anticipation.
- Empilement d'images WDR : Passe du HDR multi-images au WDR numérique à image unique. La qualité de l'image dans les scènes à contraste élevé diminue légèrement, mais aucune image n'est conservée.
La latence totale réalisable
Avec toutes les optimisations activées (mode ISP faible latence, GOP=FPS, B-Frame=0, tampon de gigue minimal), voici ce que vous pouvez réaliser de manière réaliste :
- Sur un réseau local câblé : 80-150 ms de bout en bout
- Sur une 4G stable (signal fort) : 200-400 ms de bout en bout
- Sur une 4G faible (site solaire distant) : 400-800 ms de bout en bout
- Sur 4G avec transport WebRTC : 150-300 ms de bout en bout (WebRTC gère mieux la gigue que RTSP7)
Quand utiliser le mode faible latence par rapport au mode normal
N'activez pas le mode faible latence sur toutes les caméras par défaut. Il échange la qualité de l'image contre la vitesse. Pour les caméras qui servent uniquement à l'enregistrement et à la lecture (aucun contrôle PTZ en direct nécessaire), conservez le mode ISP normal. La réduction du bruit temporelle et le WDR multi-images produisent des séquences nettement meilleures pour l'examen des preuves.
Activez le mode faible latence uniquement sur les caméras où :
- Un opérateur contrôle activement la PTZ en temps réel
- La caméra alimente un écran de sensibilisation situationnelle en direct
- L'analyse IA nécessite une latence minimale pour les alertes en temps réel
Notre firmware vous permet de basculer entre les modes via un appel API, vous pouvez donc activer le mode faible latence lorsqu'un opérateur prend le contrôle PTZ et revenir au mode haute qualité lorsqu'il le relâche.
Conclusion
La personnalisation de la structure GOP est le moyen le plus efficace de réduire le décalage du contrôle PTZ sur la 4G. Réglez le GOP sur votre FPS, désactivez les images B et utilisez l'encodage double flux pour équilibrer la latence et le coût des données. Si vous avez besoin d'aide pour configurer ces paramètres pour votre déploiement spécifique, contactez-moi à sales05@loyalty-secu.com.
1. Comprendre les images I (images clés) qui contiennent des données d'image complètes et sont cruciales pour le décodage. ︎↩︎ 2. Explorer les images P qui ne transportent que les différences par rapport aux images précédentes, économisant ainsi la bande passante. ︎↩︎ 3. Découvrir l'efficacité de la compression H.265 (HEVC) qui peut réduire l'utilisation de la bande passante pour les images I. ︎↩︎ 4. En savoir plus sur ONVIF Profile S pour le streaming vidéo et la configuration des paramètres d'encodage à distance. ︎↩︎ 5. Comprendre le débit binaire variable (VBR) pour un encodage vidéo efficace avec des limites de bande passante. ︎↩︎ 6. En savoir plus sur le débit binaire constant (CBR) pour une utilisation prévisible de la bande passante dans le streaming en direct. ︎↩︎ 7. Découvrir RTSP, le protocole de streaming traditionnel utilisé par les caméras IP, et ses compromis en matière de latence. ︎↩︎ 8. En savoir plus sur les caméras Pan-Tilt-Zoom et leurs défis de latence sur les réseaux cellulaires. ︎↩︎ 9. Comprendre les caractéristiques du réseau 4G affectant la latence et la bande passante du streaming vidéo. ︎↩︎