La question se pose souvent : Comment connecter une caméra ip au NVR si elle n'est pas dans la liste de compatibilité ?
Il y a deux options ONVIF et RTSP
Commençons par le protocole ONVIF (Open Network Video Interface Forum)
ONVIF est un protocole commun pour l'interopérabilité des caméras IP, NVR, Logiciel, si tous les appareils proviennent de fabricants différents. ONVIF peut être comparé à langue Anglaise pour la communication internationale des personnes.
Assurez-vous que les appareils connectés prennent en charge ONVIF, sur certains appareils ONVIF peut être désactivé par défaut.
Ou l'autorisation ONVIF peut être désactivée, ce qui signifie que le login / mot de passe sera toujours celui par défaut
quel que soit le login/mot de passe pour le WEB 
Il convient également de noter que certains appareils utilisentport séparé pour le travail sous le protocole ONVIF
Dans certains cas, le mot de passe ONVIF peut différer du mot de passe d'accès WEB.
Qu'est-ce qui est disponible lorsqu'il est connecté via ONVIF ?
Découverte d'appareils
Transfert de données vidéo
Réception et transmission de données audio
Contrôler Caméras PTZ(PTZ)
Analyse vidéo (par exemple, détection de mouvement)
Ces options dépendent de la compatibilité des versions du protocole ONVIF. Dans certains cas, certains paramètres ne sont pas disponibles ou ne fonctionnent pas correctement.
K et en utilisant ONVIF
Dans les bureaux d'enregistrement SNR et Dahua Protocole ONVIF situé sur l'onglet Appareil distant, ligne Fabricant
Sélectionnez le canal auquel l'appareil sera connecté
Dans l'onglet Fabricant, sélectionnez ONVIF
Spécifier adresse IP dispositifs
RTSP le port reste par défaut
Les caméras utilisent ONVIF port 8080
(depuis 2017, sur les nouveaux modèles ONVIF, le port est passé à 80 pour les séries Alpha, Mira)
Caméras OMNY Base utiliser ONVIF port 80, dans le registraire, il est spécifié comme un port HTTP
Nom
Mot de passe selon les paramètres de l'appareil
canal distant la valeur par défaut est 1. Si l'appareil est multicanal, le numéro de canal est indiqué.
Mémoire tampon du décodeur- mise en mémoire tampon du flux vidéo avec valeur temporelle
Type de serveuril y a un choix de TCP, UDP Schedule
TCP- établit une connexion entre l'expéditeur et le destinataire, s'assure que toutes les données parviennent au destinataire sans modification et dans l'ordre souhaité, régule également la vitesse de transmission.
Contrairement à TCP, UDP n'établit pas de connexion préliminaire, mais commence simplement à transmettre des données. UDP ne garde pas trace des données reçues et ne les duplique pas en cas de perte ou d'erreur.
UDP est moins fiable que TCP. Mais d'un autre côté, il fournit un streaming plus rapide en raison de l'absence de retransmission des paquets perdus.
Programme— détection automatique du type.
Voici à quoi ressemblent les appareils connectés à Dahua
L'état vert signifie que le DVR et la caméra sont connectés avec succès
L'état rouge signifie qu'il y a des problèmes de connexion. Par exemple, le port de connexion est incorrect.
La deuxième façon de se connecter est RTSP(Protocole de diffusion en temps réel) 
RTSPun protocole de diffusion en temps réel qui décrit les commandes de contrôle d'un flux vidéo.
À l'aide de ces commandes, le flux vidéo est diffusé de la source au destinataire.
par exemple d'une caméra IP vers un DVR ou un serveur.
Qu'est-ce qui est disponible lors de la connexion via RTSP ?
Transfert de données vidéo
Réception et transmission de données audio
avantagede ce protocole de transfert en ce qu'il ne nécessite pas de compatibilité de version.
Aujourd'hui, RTSP est pris en charge par presque toutes les caméras IP et NVR.
désavantages protocole est que rien d'autre n'est disponible, sauf pour la transmission de données vidéo et audio.
Regardons un exemple de connexion d'une caméra vers et en utilisant RTSP
.jpg)
RTSP situé sur l'onglet Remote Device, ligne Manufacturer, dans le registre SNR et Dahua, il est présenté commeGénéral
Sélectionnez le canal auquel l'appareil sera connecté
Adresse URL- ici, nous entrons dans la chaîne de requête par laquelle la caméra revient basique Flux RTSP de haute résolution.
URL supplémentaire - ici entrez la chaîne de requête par laquelle la caméra revient Additionnel Flux RTSP de basse résolution.
Exemple de demande :
rtsp://172.16.31.61/1 flux principal
rtsp://172.16.31.61/2 flux supplémentaire
Pourquoi avez-vous besoin d'un flux supplémentaire ?
Sur un moniteur local connecté à un enregistreur multi-images, l'enregistreur utilise un fil supplémentaire pour économiser les ressources. Par exemple, dans de petites images de 16 fenêtres, il n'est pas du tout nécessaire de décoder la résolution Full HD, D1 suffit. Eh bien, si vous avez ouvert 1/4/8 fenêtres dans ce cas, le flux principal est décodé en haute résolution.
Nomselon les paramètres de l'appareil
Mot de passe selon les paramètres de l'appareil
Mémoire tampon du décodeurmise en mémoire tampon du flux vidéo avec valeur temporelle
Type de serveur- TCP, UDP, Schedule (similaire au protocole ONVIF)
Cet article répond aux questions les plus courantes telles que :
La caméra IP est-elle compatible avec le NVR ?
Et si c'est compatible, comment se connecter !?
Protocole RTSP
RTSP (Real Time Streaming Protocol ou, en russe, protocole de diffusion en temps réel) est un protocole d'application qui décrit les commandes de contrôle d'un flux vidéo. Avec ces commandes, nous pouvons "ordonner" à la caméra ou au serveur, par exemple, de commencer à diffuser un flux vidéo. Un exemple de requête pour démarrer la lecture ressemble à ceci : PLAY rtsp://192.168.0.200/h264 RTSP/1.0
Autrement dit, RTSP n'est qu'un ensemble de commandes permettant de contrôler le flux vidéo. Faisons une expérience. Pour ce faire, nous avons besoin d'une caméra IP prenant en charge le protocole RTSP et son adresse RTSP. Cette adresse ressemble à ceci rtsp://
Protocole TCP
Supposons que nous ayons choisi la méthode RSTP sur TCP et que nous souhaitions commencer à transmettre un flux vidéo. Que va-t-il se passer au niveau des mécanismes de transport ? Au préalable, à l'aide de plusieurs commandes, une connexion sera établie entre l'expéditeur et le destinataire. Après cela, le transfert de données vidéo commencera. Dans le même temps, les mécanismes TCP
garantira que toutes les données parviennent au destinataire sans changement et dans le bon ordre. TCP régulera également le débit de transmission afin que l'émetteur n'envoie pas de données plus intensément que le récepteur ne peut les traiter, par exemple,
UDP est une alternative au transport Protocole TCP. Contrairement à TCP, UDP n'établit pas de pré-connexion, mais commence simplement à transmettre des données. UDP ne s'assure pas que les données sont reçues et ne les duplique pas si des pièces sont manquantes ou reçues avec des erreurs. UDP moins
fiable que TCP. Mais d'un autre côté, il offre un streaming plus rapide en raison de l'absence de mécanisme de retransmission des paquets perdus. La différence entre les protocoles TCP et UTP peut être illustrée par l'exemple suivant. Deux amis se rencontrent. Options TCP :
Ivan : Bonjour ! Est ce que tu veux qu'on discute?" (la connexion est établie)
Simon : "Bonjour ! Allons !" (la connexion est établie)
Ivan : « Hier, j'étais dans le magasin. Comprenez vous?" (transfert de données)
Simon : "Oui !" (la confirmation)
Ivan : « Ils déchargeaient du nouveau matériel. Comprenez vous?" (transfert de données)
Semyon : "Non" (confirmation)
Ivan : « Ils déchargeaient du nouveau matériel. Comprenez vous?" (retransmission)
Simon : "Oui !" (la confirmation)
Ivan: "Demain, je serai de nouveau là-bas. Comprenez vous?" (transfert de données)
Simon : "Oui !" (la confirmation)
Variante UDP
Ivan : Bonjour ! Je suis allé au magasin hier » (transmission de données)
Ivan : "Ils déchargeaient du nouveau matériel" (transmission de données)
Ivan : « Demain, je serai de nouveau là » (transmission de données)
Ivan : "Je peux vous obtenir des prix" (transmission de données)
Ivan : "Ils ont promis des remises pour de bons volumes" (transmission de données)
Ivan: "Si tu veux, appelle - nous irons ensemble" (transmission de données)
Semyon : "Oui, j'appellerai" (transmission de données)
Vous pouvez également voir la différence entre les protocoles en faisant l'expérience suivante : essayez de régler l'appareil photo sur le mode RTSP sur TCP et agitez votre main devant l'objectif - vous verrez un retard sur l'écran du moniteur. Exécutez maintenant le même test en mode RTSP sur UDP. Le retard sera moindre. Plusieurs facteurs influent sur le temps de retard : le format de compression, la puissance de l'ordinateur, le protocole de transmission et les fonctionnalités du logiciel impliqué dans le décodage vidéo.
RTP (Real-time Transport Protocol), ou protocole de transport en temps réel en russe. Ce protocole est spécifiquement conçu pour transmettre le trafic en temps réel. Il vous permet de surveiller la synchronisation des données transmises, d'ajuster la séquence de livraison des paquets et est donc plus adapté à la transmission de données vidéo et audio. En général, il est préférable d'utiliser RTP ou UDP pour transmettre un flux vidéo. Travailler via TCP n'est justifié que si nous devons travailler avec des réseaux problématiques, car le protocole TCP sera en mesure de corriger les erreurs et les pannes qui se produisent lors du transfert de données.
RTSP (protocole de diffusion en temps réel) est un protocole de streaming en temps réel qui contient un ensemble simple de commandes de base pour contrôler le flux vidéo.
Connecter des sources RTSP et des caméras IP dans une visioconférence
Le protocole RTSP permet à tout utilisateur TrueConf de se connecter à des caméras vidéo IP et à d'autres sources de contenu multimédia diffusant à l'aide de ce protocole pour surveiller des objets distants. Aussi, l'utilisateur peut se connecter à de telles caméras pour diffuser des images lors d'une visioconférence.
Grâce à la prise en charge du protocole RTSP, les utilisateurs de TrueConf Server peuvent non seulement se connecter à des caméras IP, mais également diffuser des vidéoconférences sur des lecteurs RTSP et des serveurs multimédias. En savoir plus sur les diffusions RTSP.
Avantages de l'utilisation de caméras IP avec les solutions logicielles TrueConf
- En installant une caméra IP dans un bureau ou un atelier industriel et en vous y connectant à tout moment, vous pouvez surveiller le processus de production de votre entreprise.
- Vous pouvez effectuer une surveillance 24 heures sur 24 des objets distants. Par exemple, si vous partez en vacances et que vous ne souhaitez pas laisser votre appartement sans surveillance, il vous suffit d'y installer une ou plusieurs caméras IP. En appelant l'une de ces caméras depuis votre PC avec l'application client TrueConf installée, vous pouvez vous connecter à tout moment à votre appartement et voir ce qui s'y passe en temps réel.
- Les applications clientes TrueConf pour Windows, Linux et macOS offrent à tous les utilisateurs la possibilité d'enregistrer des vidéoconférences, grâce auxquelles vous pouvez enregistrer n'importe quel événement pendant la vidéosurveillance et en recevoir une preuve documentaire.
Selon certaines données, à ce jour, le monde a installé des centaines de millions Caméras IP pour la vidéosurveillance. Cependant, loin d'être tous, le retard de lecture vidéo est critique. La vidéosurveillance, en règle générale, se produit "statiquement" - le flux est enregistré dans le stockage et peut être analysé pour détecter les mouvements. Pour la vidéosurveillance, de nombreuses solutions logicielles et matérielles ont été développées qui font bien leur travail.
Dans cet article, nous examinerons une application légèrement différente. Caméras IP, à savoir l'utilisation dans des émissions en ligne, le cas échéant faible délai de communication.
Tout d'abord, clarifions un éventuel malentendu dans la terminologie concernant les webcams et les caméras IP.
Webcam est un appareil de capture vidéo qui ne possède pas son propre processeur ni interface réseau. La webcam doit être connectée à un ordinateur, un smartphone ou un autre appareil disposant carte réseau et processeur.
caméra IP est un appareil autonome qui possède sa propre carte réseau et son propre processeur pour compresser la vidéo capturée et l'envoyer sur le réseau. Ainsi, la caméra IP est un mini-ordinateur autonome qui se connecte entièrement au réseau et n'a pas besoin d'être connecté à un autre appareil, et peut diffuser directement sur le réseau.
Faible latence(faible latence) est une exigence assez rare pour les caméras IP et les diffusions en ligne. La nécessité de travailler avec une faible latence apparaît, par exemple, si la source du flux vidéo interagit activement avec les spectateurs de ce flux.
Le plus souvent, une faible latence est nécessaire dans les cas d'utilisation de jeux. Exemples : enchères vidéo en direct, casino vidéo avec croupier en direct, émission de télévision interactive en direct avec hôte, télécommande quadricoptère, etc.
Un croupier de casino en ligne en direct au travail.
Une caméra IP RTSP ordinaire, en règle générale, presse la vidéo dans H.264 codec et peut fonctionner selon deux modes de transport de données : entrelacé et non entrelacé.
Mode entrelacé le plus populaire et le plus pratique, car dans ce mode, les données vidéo sont transmises via le protocole TCP à l'intérieur connexion réseauà la caméra. Afin de distribuer d'une caméra IP à entrelacé, il vous suffit d'ouvrir / transférer un port RTSP de la caméra (par exemple, 554) vers l'extérieur. Le lecteur n'a qu'à se connecter à la caméra via TCP et à capter le flux déjà à l'intérieur de cette connexion.
Le deuxième mode de fonctionnement de la caméra est non entrelacé. Dans ce cas, la connexion est établie en utilisant le protocole RTSP/TCP, et le trafic va déjà séparément, selon le protocole RTP/UDP en dehors du canal TCP créé.
Mode non entrelacé plus favorable pour la diffusion vidéo avec un délai minimal, car il utilise le protocole RTP/UDP, mais en même temps c'est plus problématique si le joueur est situé derrière NAT.
Lors de la connexion à la caméra IP d'un lecteur située derrière le NAT, le lecteur doit savoir quelles adresses IP externes et quels ports il peut utiliser pour recevoir le trafic audio et vidéo. Ces ports sont spécifiés dans le texte SDP config qui est envoyé à la caméra lorsqu'une connexion RTSP est établie. Si le NAT a été ouvert correctement et que les adresses IP et les ports corrects sont définis, alors tout fonctionnera.
Ainsi, afin de prendre une vidéo de la caméra avec un délai minimal, vous devez utiliser non entrelacé mode et recevoir le trafic vidéo via UDP.
Les navigateurs ne prennent pas directement en charge la pile de protocoles RTSP/UDP, mais prennent en charge la pile de protocoles de la technologie intégrée WebRTC.
Les technologies de navigateur et de caméra sont très similaires, en particulier SRTP c'est crypté RTP. Mais pour une distribution correcte aux navigateurs, une caméra IP aurait besoin d'une prise en charge partielle de la pile WebRTC.
Pour éliminer cette incompatibilité, un serveur relais intermédiaire est nécessaire, qui sera un pont entre les protocoles de la caméra IP et les protocoles du navigateur.
Le serveur prend le flux de la caméra IP vers lui-même en RTP/UDP et le donne aux navigateurs connectés via WebRTC.
La technologie WebRTC fonctionne selon le protocole UDP et assure ainsi une faible latence dans le sens Serveur > Navigateur. La caméra IP fonctionne également sur le protocole RTP/UDP et fournit une faible latence dans la direction Caméra > Serveur.
La caméra peut fournir un nombre limité de flux, en raison de ressources et d'une bande passante limitées. L'utilisation d'un serveur intermédiaire vous permet d'adapter la diffusion d'une caméra IP à grand nombre spectateurs.
D'autre part, lors de l'utilisation du serveur, deux branches de communication sont activées :
1) Entre spectateurs et serveur
2) Entre le serveur et la caméra
Une telle topologie présente un certain nombre de "caractéristiques" ou de "pièges". Nous les listons ci-dessous.
Piège #1 - Codecs
Les codecs utilisés peuvent être un obstacle à une faible latence et entraîner une dégradation des performances globales du système.Par exemple, si une caméra envoie un flux vidéo 720p en H.264 et qu'un navigateur Chrome est connecté à Téléphone intelligent Android avec prise en charge de VP8 uniquement.
Lorsque le transcodage est activé, une session de transcodage doit être créée pour chacune des caméras IP connectées, qui décode H.264 et encode en VP8. Dans ce cas, un serveur biprocesseur à 16 cœurs ne pourra desservir que 10 à 15 caméras IP, avec un calcul approximatif de 1 caméra par cœur physique.
Par conséquent, si les capacités du serveur ne permettent pas de transcoder le nombre prévu de caméras, alors le transcodage doit être évité. Par exemple, ne servez que les navigateurs prenant en charge H.264 et proposez aux autres d'utiliser application mobile pour iOS ou Android, où le codec H.264 est pris en charge.
En option pour contourner le transcodage dans un navigateur mobile, vous pouvez utiliser HLS. Mais le streaming HTTP n'est pas du tout à faible latence et ne peut actuellement pas être utilisé pour le streaming interactif.
Piège #2 - Débit et perte de la caméra
Le protocole UDP aide à faire face au délai, mais permet la perte de paquets vidéo. Par conséquent, malgré la faible latence, avec de grandes pertes de réseau entre la caméra et le serveur, l'image peut être corrompue.
Afin d'éliminer les pertes, vous devez vous assurer que le flux vidéo généré par la caméra a un débit binaire qui correspond à la bande passante allouée entre la caméra et le serveur.
Piège #3 - Débit binaire et perte du spectateur
Chaque téléspectateur qui se connecte au serveur dispose également d'un certain débit sur Télécharger.Si la caméra IP envoie un flux qui dépasse les capacités du canal spectateur (par exemple, la caméra envoie 1 Mbit/s, et le spectateur ne peut accepter 500 kbit/s), alors il y aura de grandes pertes sur ce canal et, par conséquent, des frises vidéo ou de forts artefacts.
Dans ce cas, trois options s'offrent à vous :
- Transcodez le flux vidéo individuellement pour chaque spectateur au débit binaire requis.
- Transcodez les flux non pas pour chaque connecté, mais pour un groupe d'un groupe de téléspectateurs.
- Préparez à l'avance les flux de la caméra dans plusieurs résolutions et débits.
Deuxième option est de réduire la charge sur le CPU du serveur en utilisant des groupes de transcodage. Le serveur crée plusieurs groupes par débit, par exemple deux :
- 200 Kbits/s
- 1 Mbit/s
Troisième option implique un rejet complet du transcodage côté serveur et l'utilisation de flux vidéo déjà préparés dans diverses résolutions et débits binaires. Dans ce cas, la caméra est configurée pour produire deux ou trois flux avec des résolutions et des débits binaires différents, et les téléspectateurs basculent entre ces flux en fonction de leur bande passante.
Dans ce cas, la charge de transcodage sur le serveur disparaît et se déplace vers la caméra elle-même, car la caméra est maintenant obligée d'encoder deux ou plusieurs flux au lieu d'un.
En conséquence, nous avons envisagé trois options pour s'adapter à la bande passante des téléspectateurs. Si nous supposons qu'une session de transcodage prend 1 cœur de serveur, nous obtenons le tableau suivant de charge CPU :
Le tableau montre que nous pouvons déplacer la charge de transcodage vers la caméra ou transférer le transcodage vers le serveur. Les options 2 et 3 semblent être les plus optimales.
Tester RTSP en tant que WebRTC
Il est temps d'effectuer quelques tests pour révéler l'image réelle de ce qui se passe. Prenons une vraie caméra IP et testons-la pour mesurer la latence de diffusion.Prenons une ancienne caméra IP pour tester Liaison D DCS-2103 avec le soutien RTSP et codecs H.264 et G.711.
Étant donné que la caméra est restée longtemps dans un placard avec d'autres appareils et câbles utiles, j'ai dû l'envoyer à réinitialiser en appuyant sur le bouton à l'arrière de l'appareil photo et en le maintenant enfoncé pendant 10 secondes.
Après la connexion au réseau, un voyant vert s'est allumé sur la caméra et le routeur a vu un autre appareil en réseau local avec l'adresse IP 192.168.1.37.
Nous allons sur l'interface Web de la caméra et définissons les codecs et la résolution pour les tests :
Ensuite, nous allons à paramètres réseau et découvrez l'adresse RTSP de la caméra. Dans ce cas, l'adresse RTSP live1.sdp, c'est à dire. La caméra est disponible sur rtsp://192.168.1.37/live1.sdp
L'accessibilité de la caméra peut être facilement vérifiée avec lecteur VLC. Média - Flux réseau ouvert.
Nous nous sommes assurés que la caméra fonctionne et donne la vidéo via RTSP.
Nous utiliserons Web Call Server 5 comme serveur de test. Il s'agit d'un serveur de streaming avec prise en charge RTSP et WebRTC protocoles. Il se connectera à la caméra IP en RTSP et prendre le flux vidéo. Distribuez davantage le flux en WebRTC.
Après l'installation, vous devez basculer le serveur en mode RTSP non entrelacé dont nous avons parlé plus haut. Cela peut être fait en ajoutant le paramètre
rtsp_interleaved_mode=false
Ce paramètre est ajouté à la configuration flashphoner.properties et nécessite un redémarrage du serveur :
Redémarrage du service webcallserver
Ainsi, nous avons un serveur qui fonctionne selon le schéma non entrelacé, reçoit les paquets de la caméra IP via UDP, puis les distribue via WebRTC (UDP).
Le serveur de test est situé sur un serveur VPS situé dans le centre de données de Francfort, dispose de 2 cœurs et de 2 gigaoctets de RAM.
La caméra est située sur le réseau local au 192.168.1.37.
Par conséquent, la première chose que nous devons faire est de transférer le port 554 vers 192.168.1.37 pour les appels entrants. TCP/RTSP connexions afin que le serveur puisse se connecter à notre caméra IP. Pour cela, ajoutez une seule règle dans les paramètres du routeur :
La règle indique au routeur de rediriger tout le trafic entrant sur le port 554 vers 37 - l'adresse IP.
Si vous avez un NAT convivial et que vous connaissez l'adresse IP externe, vous pouvez commencer à tester avec le serveur.
Lecteur de démonstration standard dans le navigateur Google Chrome Ressemble à ça:
Pour lancer la lecture d'un flux RTSP, il vous suffit de saisir son adresse dans le champ Flux.
Dans ce cas, l'adresse du flux : rtsp://ip-cam/live1.sdp
Ici caméra IP il s'agit de l'adresse IP externe de votre caméra. Le serveur essaiera d'établir une connexion à cette adresse.
Test de latence VLC vs WebRTC
Après avoir configuré la caméra IP et testé dans VLC, configurez le serveur et testez RTSP transitent par le serveur avec distribution par WebRTC, on peut enfin comparer les délais.Pour ce faire, nous utiliserons une minuterie qui affichera des fractions de seconde sur l'écran du moniteur. Allumez la minuterie et lisez le flux vidéo simultanément sur VLC localement et sur Navigateur Firefox via un serveur distant.
Ping au serveur 100ms.
Ping local 1 ms.
Le premier test de minuterie ressemble à ceci :
Sur un fond noir se trouve la minuterie d'origine, qui affiche un délai nul. La gauche VLC, sur la droite Firefox recevoir WebRTC flux depuis un serveur distant.
| Zéro | VLC | Firefox, WCS | |
| Temps | 50.559 | 49.791 | 50.238 |
| latence ms | 0 | 768 | 321 |
Nous avons pris quelques photos pour capturer les valeurs de retard.