Résoudre le problème de la diffusion en ligne à partir d'une caméra IP ne nécessite généralement pas l'utilisation de WebRTC. La caméra elle-même est un serveur, possède une adresse IP et peut être connectée directement à un routeur afin de diffuser du contenu vidéo. Alors pourquoi utiliser la technologie WebRTC ?
Il y a au moins deux raisons à cela :
1. À mesure que le nombre de téléspectateurs d'une diffusion Ethernet augmente, il y aura d'abord une pénurie croissante d'épaisseur de canal, puis des ressources de la caméra elle-même.
2. Comme mentionné ci-dessus, la caméra IP est un serveur. Mais par quels protocoles pourra-t-elle donner la vidéo au navigateur de bureau ? Appareil mobile ? Il s'agira très probablement d'un streaming HTTP, où les images vidéo ou les images JPEG sont transmises via HTTP. Le streaming HTTP, comme vous le savez, n'est pas tout à fait adapté à vidéo en continu en temps réel, bien qu'il fonctionne bien dans la vidéo à la demande, où l'interactivité et la latence du flux ne sont pas particulièrement importantes. En fait, si vous regardez un film, retarder la vidéo de quelques secondes ne l'aggravera pas, sauf si vous regardez le film en même temps que quelqu'un d'autre. "Oh non! Jack l'a tuée ! - Alice écrit un spoiler dans le chat à Bob 10 secondes avant le dénouement tragique.
Ou ce sera RTSP/RTP et H.264, auquel cas un plugin de lecteur vidéo tel que VLC ou QuickTime doit être installé dans le navigateur. Un tel plugin captera et lira la vidéo, tout comme le lecteur lui-même. Mais nous avons vraiment besoin d'un vrai streaming basé sur un navigateur sans installer de béquilles / plugins supplémentaires.
Tout d'abord, reniflons la caméra IP pour savoir exactement ce que cet appareil envoie vers le navigateur. En tant que sujet de test, il y aura une caméra D-Link DCS 7010L :
Vous pouvez en savoir plus sur l'installation et la configuration de la caméra ci-dessous, mais ici, nous verrons simplement ce qu'elle utilise pour le streaming vidéo. Lorsque vous accédez au panneau d'administration de la caméra via l'interface Web, nous voyons quelque chose comme ceci (désolé pour le paysage) :
L'image s'ouvre dans tous les navigateurs et podlagivaet uniformément, environ une fois par seconde. Étant donné que la caméra et l'ordinateur portable sur lequel nous regardons le flux sont connectés au même routeur, tout devrait être fluide et beau, mais ce n'est pas le cas. Semblable à HTTP. Exécutez Wireshark pour confirmer nos suppositions :
Ici, nous voyons une séquence de fragments TCP de 1514 octets de long
Et un dernier HTTP 200 OK avec la longueur du JPEG reçu :
Nous n'avons pas besoin de ce streaming. Pas fluide, tire les requêtes HTTP. Combien de requêtes de ce type par seconde la caméra peut-elle supporter ? Il y a des raisons de croire qu'à 10 spectateurs et plus tôt, la caméra sera pliée en toute sécurité ou qu'elle commencera à trembler terriblement et à donner des diapositives.
Si vous regardez dans pages HTML panneau d'administration de la caméra, nous verrons ce code intéressant :
Si(navigateur_IE) DW(""); sinon (if(mpMode == 1) var RTSPName = g_RTSPName1 ; sinon si(mpMode == 2) var RTSPName = g_RTSPName2 ; sinon si(mpMode == 3) var RTSPName = g_RTSPName3 ; var o="" ; si (g_isIPv6) //parce que ipv6 ne prend pas en charge rtsp.var host = g_netip;else var host = g_host;o+=""; //alerte(o); DW(o); )
RTSP/RTP est exactement ce dont vous avez besoin pour une lecture vidéo correcte. Mais cela fonctionnera-t-il dans un navigateur ? - Pas. Mais si vous installez le plugin QuickTime - tout fonctionnera. Mais nous faisons du streaming purement basé sur un navigateur.
Ici, vous pouvez également mentionner Lecteur Flash, qui peut recevoir un flux RTMP converti à partir de RTSP, RTP, H.264 via un serveur approprié comme Wowza. Mais Flash Player, comme vous le savez, est aussi un plug-in de navigateur, bien qu'il soit incomparablement plus populaire que VLC ou QuickTime.
Dans ce cas, nous testerons le même re-streaming RTSP/RTP, mais un navigateur compatible WebRTC sera utilisé comme périphérique de lecture sans plugins de navigateur supplémentaires et autres béquilles. Nous allons configurer un serveur relais qui prendra le flux de la caméra IP et l'enverra sur Internet à un nombre arbitraire d'utilisateurs utilisant des navigateurs compatibles WebRTC.
Connecter une caméra IP
Comme mentionné ci-dessus, une simple caméra IP D-Link DCS-7010L a été choisie pour les tests. Le critère de sélection clé ici était la prise en charge par l'appareil du protocole RTSP, puisque c'est par lui que notre serveur prélèvera le flux vidéo de la caméra.Nous connectons la caméra au routeur avec le cordon de raccordement inclus. Après la mise sous tension et la connexion au routeur, la caméra a pris une adresse IP via DHCP, dans notre cas c'était 192.168.1.34 (Si vous allez dans les paramètres du routeur, vous verrez que l'appareil DCS 7010L est connecté - c'est il). Il est temps de tester la caméra.
Ouvrez l'adresse IP spécifiée dans le navigateur 192.168.1.34 pour accéder à l'interface Web de l'administrateur de la caméra. Par défaut, il n'y a pas de mot de passe.
Comme vous pouvez le voir, la vidéo de la caméra est diffusée correctement dans le panneau d'administration. Dans le même temps, un brouillage périodique est perceptible. C'est ce que nous allons corriger en utilisant WebRTC.
Configuration de la caméra
Tout d'abord, dans les paramètres de la caméra, nous désactivons l'authentification - dans le cadre des tests, nous donnerons le flux à tous ceux qui le demanderont. Pour cela, dans l'interface web de la caméra, rendez-vous dans les paramètres Configuration-Réseau et définissez la valeur de l'option Authentification désactivée.Au même endroit, nous vérifions la valeur du port du protocole RTSP, par défaut c'est 554. Le format de la vidéo transmise est déterminé par le profil utilisé. Vous pouvez en configurer jusqu'à trois dans la caméra, nous utiliserons le premier, live1.sdp - par défaut, il est configuré pour utiliser H.264 pour la vidéo et G.711 pour l'audio. Vous pouvez modifier les paramètres si nécessaire dans la section Configuration-Audio et Vidéo.
Vous pouvez maintenant vérifier le fonctionnement de la caméra via RTSP. Ouvrez VLC Player (vous pouvez utiliser n'importe quel autre lecteur prenant en charge RTSP - QuickTime, Windows lecteur multimédia, RealPlayer, etc.) et dans la boîte de dialogue Ouvrir l'URL, définissez l'adresse RTSP de la caméra : rtsp://192.168.1.34/live1.sdp
Eh bien, tout fonctionne comme il se doit. La caméra lit correctement le flux vidéo dans le lecteur via le protocole RTSP.
Soit dit en passant, le flux est reproduit de manière assez fluide et sans artefacts. Nous attendons la même chose de WebRTC.
Installation du serveur
Ainsi, la caméra est installée, testée avec des lecteurs de bureau et prête à diffuser via le serveur. En utilisant whatismyip.com, nous déterminons l'adresse IP externe de la caméra. Dans notre cas, c'était 178.51.142.223. Il reste à dire au routeur que lors de l'accès via RTSP sur le port 554, les requêtes entrantes sont transmises à la caméra IP.Nous martelons les paramètres appropriés dans le routeur ...
...et vérifiez l'adresse IP externe et le port RTSP à l'aide de telnet :
Telnet 178.51.142.223 554
Après s'être assuré qu'il y a une réponse sur ce port, nous procédons à l'installation du serveur WebRTC.
Un serveur virtuel sur Centos 64 bits sur Amazon EC2 se chargera de l'hébergement.
Afin de ne pas avoir de problèmes de performances, nous avons choisi l'instance m3.medium avec un seul VCPU :
Oui, oui, il y a aussi Linode et DigitalOcean, mais dans ce cas je voulais Amazon.
Pour l'avenir, j'écrirai que dans le panneau de configuration Amazon EC2, vous devez ajouter plusieurs règles (ports de transfert), sans lesquelles l'exemple ne fonctionnera pas. Il s'agit de ports pour le trafic WebRTC (SRTP, RTCP, ICE) et de ports pour le trafic RTSP/RTP. Si vous essayez, les règles d'Amazon devraient avoir quelque chose de similaire pour le trafic entrant :
Avec DigitalOcean, d'ailleurs, tout sera plus simple, il suffit d'ouvrir ces ports sur le pare-feu ou d'étouffer ce dernier. Selon la dernière expérience d'exploitation des instances DO, elles donnent toujours une adresse IP statique et ne se soucient pas des NAT, ce qui signifie que la redirection de port, comme dans le cas d'Amazon, n'est pas nécessaire.
Nous utiliserons WebRTC Media & Broadcasting Server de Flashphoner comme logiciel serveur qui relaie un flux RTSP/RTP vers WebRTC. Le serveur de streaming est très similaire à Wowza, qui peut diffuser RTSP/RTP vers Flash. La seule différence est que ce flux sera donné à WebRTC, pas à Flash. Celles. un DTLS honnête passera entre le navigateur et le serveur, une session SRTP sera établie et le flux encodé en VP8 ira au spectateur.
Nous avons besoin d'un accès SSH pour l'installation.
Sous le spoiler - une description détaillée des commandes exécutées
1. Téléchargez l'archive d'installation du serveur :
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Déployé :
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Installé :
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Lors du processus d'installation, l'adresse IP externe du serveur a été saisie : 54.186.112.111 et interne 172.31.20.65 (celle qui est une IP privée).
4. Démarrez le serveur :
$service webcallserver start
5. Vérifié les journaux :
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Nous nous sommes assurés que le serveur a démarré et est prêt à fonctionner :
$ps aux | grep Flashphone
7. Apache installé et lancé :
$yum installer httpd
$service démarrage httpd
8. Téléchargez les fichiers Web et placez-les dans dossier standard apache /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Entrez l'adresse IP du serveur dans la configuration flashphoner.xml :
10. Arrêt du pare-feu.
$service iptables s'arrête
En théorie, au lieu du point 10, il serait correct de définir tous les ports et règles de pare-feu nécessaires, mais à des fins de test, nous avons décidé de simplement désactiver le pare-feu.
Réglage du serveur
Rappelons que la structure de notre diffusion WebRTC est la suivante :
Nous avons déjà installé les principaux éléments de ce schéma, il reste à établir les "flèches" des interactions.
La connexion entre le navigateur et le serveur WebRTC est assurée par un client web, qui est disponible sur github :. Un ensemble de fichiers JS, CSS et HTML est simplement jeté dans /var/www/html au stade de l'installation (voir paragraphe 9 ci-dessus sous le spoiler).
L'interaction entre le navigateur et le serveur est configurée dans le fichier XML de configuration flashphoner.xml. Vous devez y saisir l'adresse IP du serveur afin que le client web puisse se connecter au serveur WebRTC via les Websockets HTML5 (point 9 ci-dessus).
La configuration du serveur se termine ici, vous pouvez vérifier son fonctionnement :
Nous ouvrons la page du client web index.html dans le navigateur (pour cela, Apache a été installé sur le même serveur Amazon avec la commande miam -y installer httpd):
54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp
Ici webrtc-ipcam.ddns.net est un domaine gratuit obtenu via le serveur DNS dynamique noip.com , qui fait référence à notre adresse IP externe. Nous avons dit au routeur de rediriger les requêtes RTSP vers 192.168.1. Adresses NAT(voir aussi ci-dessus).
Paramètre id=rtsp://webrtc-ipcam.ddns.net/live1.sdp spécifie l'URL du flux à lire. Le serveur WebRTC demandera des flux à la caméra, les traitera et les enverra au navigateur pour lecture via WebRTC. Peut-être que votre routeur prend en charge le DDNS. Sinon, la caméra IP elle-même a un tel support :
Et voici à quoi ressemble le support DDNS dans le routeur lui-même :
Vous pouvez maintenant commencer à tester et évaluer les résultats.
Essai
Après avoir ouvert le lien dans le navigateur, une connexion est établie avec le serveur WebRTC, qui envoie une demande à la caméra IP pour recevoir un flux vidéo. L'ensemble du processus prend quelques secondes.
À ce moment, le navigateur se connecte au serveur via des websockets, puis le serveur demande la caméra IP via RTSP, reçoit le flux H.264 via RTP et le transcode en VP8/SRTP - qui est finalement lu par le navigateur WebRTC.
Au bas de la vidéo, l'URL du flux vidéo est affichée, qui peut être copiée et ouverte pour être visualisée à partir d'un autre navigateur ou onglet.
Nous sommes convaincus qu'il s'agit bien de WebRTC.
Du coup, on s'est trompé, et la vidéo de la caméra IP est à nouveau envoyée via HTTP ? Ne regardons pas l'image sans rien faire, mais vérifions quel type de trafic nous obtenons réellement. Bien sûr, nous redémarrons Wireshark et la console de débogage dans Chrome. Dans la console Chrome du navigateur, nous pouvons observer ce qui suit :
Cette fois, rien ne clignote et aucune image n'est visible, transmise via HTTP. Tout ce que nous voyons cette fois, ce sont des cadres Websocket et la plupart d'entre eux sont de type ping/pong pour maintenir une session Websocket. Cadres intéressants : connect, prepareRtspSession et onReadyToPlay - c'est l'ordre dans lequel une connexion au serveur est établie : d'abord une connexion Websocket, puis une demande de flux pour la lecture.
Et voici ce que ça montre chrome://webrtc-internes
Selon les graphiques, nous avons un débit binaire de la caméra IP de 1 Mbps. Il y a aussi du trafic sortant, il s'agit très probablement de paquets RTCP et ICE. Le RTT vers le serveur Amazon est d'environ 300 millisecondes.
Regardons maintenant Wireshark, le trafic UDP de l'adresse IP du serveur y est clairement visible. Dans l'image ci-dessous, des paquets de 1468 octets. C'est WebRTC. Plus précisément, les paquets SRTP transportent des trames vidéo VP8, que nous pouvons observer sur l'écran du navigateur. De plus, les requêtes STUN sont ignorées (le paquet le plus bas de l'image) - c'est WebRTC ICE qui vérifie soigneusement la connexion.
Il convient également de noter la latence relativement faible (le ping vers le centre de données était d'environ 250 ms) de la lecture vidéo. WebRTC fonctionne sur SRTP/UDP, qui, quoi qu'on en dise, est le plus manière rapide livraison de paquets, par opposition à HTTP, RTMP et autres méthodes de diffusion en continu de type TCP. Celles. la latence vue par l'œil devrait être RTT + mise en mémoire tampon du navigateur, décodage et temps de lecture. Visuellement, dans ce cas, c'est - l'œil ne voit presque pas le retard, il est inférieur à 500 millisecondes.
Le prochain test consiste à connecter d'autres téléspectateurs. J'ai pu ouvrir 10 fenêtres Chrome, et chacune d'elles montrait une image. Dans le même temps, Chrome lui-même a commencé à s'émouvoir un peu. Lors de l'ouverture de la 11e fenêtre sur un autre ordinateur, la lecture est restée fluide.
À propos de WebRTC sur les appareils mobiles
Comme vous le savez, WebRTC est pris en charge par les navigateurs Chrome et Firefox sur la plate-forme Android.Vérifions si notre diffusion y sera affichée :
Sur l'image htc téléphone, la vidéo de la caméra s'affiche dans le navigateur Firefox. Il n'y a aucune différence dans la fluidité de la lecture à partir du bureau.
Conclusion
En conséquence, nous avons réussi à lancer une diffusion WebRTC en direct depuis une caméra IP vers plusieurs navigateurs avec un minimum d'effort. Aucun tambourin ou science des fusées n'était requis - seulement une connaissance de base de Linux et de la console SSH.La qualité de la diffusion était à un niveau acceptable et le retard de lecture était invisible à l'œil.
En résumé, nous pouvons dire que les diffusions WebRTC basées sur un navigateur ont le droit d'exister, car. dans notre cas, WebRTC n'est plus une béquille ou un plugin, mais une véritable plateforme de lecture vidéo dans le navigateur.
Pourquoi ne voyons-nous pas l'adoption généralisée du WebRTC ?
Le principal frein, peut-être, est le manque de codecs. La communauté WebRTC et les fournisseurs doivent s'efforcer d'introduire le codec H.264 dans WebRTC. Il n'y a rien à dire contre VP8, mais pourquoi renoncer à des millions d'appareils et de logiciels compatibles qui fonctionnent avec H.264 ? Des brevets, de tels brevets...En second lieu, pas de prise en charge complète dans les navigateurs. Avec IE et Safari par exemple, la question reste ouverte et là il faudra passer à un autre type de streaming ou utiliser un plugin comme webrtc4all.
Donc, à l'avenir, nous espérons voir des solutions plus intéressantes qui ne nécessiteront pas de transcodage et de conversion de flux et la plupart des navigateurs pourront lire des flux avec divers appareils déjà directement.
Comment vérifier la possibilité de diffusion Flux RTSPà partir d'une caméra IP dans divers navigateurs Web
Vérifions l'affichage du flux vidéo RTSP dans les navigateurs Chrome, Firefox, Safari sur les ordinateurs de bureau avec Windows, Mac OS X, Linux et les appareils mobiles exécutant Android et iOS
Vérification du flux RTSP dans VLC
Pour vous assurer rapidement que le flux RTSP est disponible et diffuse de la vidéo, ouvrez-le dans le lecteur VLC. Si le flux est reproduit correctement, nous procédons au test de l'interface Web. Vous pouvez obtenir l'URL RTSP dans le panneau de configuration de la caméra IP ou utiliser un flux vidéo RTSP accessible au public, tel que celui-ci : rtsp://b1.dnsdojo.com:1935/live/sys3.stream
Tester le flux RTSP-WebRTC dans les navigateurs Google Chrome et Mozilla Firefox
Nous nous assurons que le même flux RTSP est lu sur une page HTML normale dans Navigateurs Chrome et Firefox.
1. Téléchargez l'interface de démo sur , menu ‘Demo / Streaming Min’. Il s'agit d'une interface Web HTML5 minimale qui utilise la technologie WebRTC pour afficher un flux vidéo RTSP dans les navigateurs Chrome et Firefox.
2. Établir la connexion avec Web Call Server
3. Saisissez l'adresse RTSP de la caméra et démarrez la lecture du flux :
En conséquence, nous avons vérifié avec succès la lecture du flux RTSP dans Navigateur Google Chrome. Un test similaire peut être effectué avec les navigateurs Firefox et Opera sur les plates-formes de bureau et mobiles qui prennent en charge la technologie WebRTC dans les navigateurs.
Test du flux RTSP-Websocket dans Navigateur Safari pour iOS et Mac OS X
Les navigateurs sur les appareils iOS ne prennent pas en charge la technologie WebRTC. Pour cette raison, un lecteur séparé "WS Player Min" est utilisé, qui prend le flux via le protocole Websocket et le lit dans l'élément HTML5-Canvas du navigateur.
1. Comme dans le cas de Chrome, vous devez ouvrir la page de l'interface de démonstration, mais sélectionnez un autre élément de menu :
2. Après cela, établissez une connexion avec Web Call Server
3. Entrez l'adresse précédemment connue de la diffusion RTSP et lisez le flux vidéo :
Ainsi, la possibilité de visualiser le trafic RTSP converti à l'aide de Web Call Server sur la plupart des navigateurs Web, y compris sur les plateformes mobiles les plus populaires.
L'étape suivante consiste à ajouter un lecteur HTML5 RTSP à votre propre site Web. Le processus d'ajout est décrit en détail dans la section adjacente Implémentation.
Vidéos décrivant le processus de test du lecteur RTSP-WebRTC et RTSP-Websocket
Lecteur RTSP-WebRTC pour Chrome et Firefox
Lecteur Websocket RTSP pour iOS Safari
Télécharger Web Call Server 5
Configuration requise: Linux x86_64, processeur 1 cœur, 2 Go de RAM, Java
Installation:
- wget https://site/download-wcs5.2-server.tar.gz
- Décompressez et installez à l'aide du script "install.sh"
- Démarrez le serveur avec la commande "service webcallserver start"
- Ouvrez l'interface web https://host:8444 et activez votre licence
Si vous utilisez des serveurs Amazon EC2, vous n'avez rien à télécharger.
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 Protocole TCPà l'intérieur de la 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 connaître les adresses IP externes et les ports qu'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 de diffusion qui se connecte au serveur dispose également d'une certaine bande passante de téléchargement.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.
Le lecteur de démonstration standard du navigateur Google Chrome ressemble à ceci :
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 le 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.
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.
Visualisation confortable des émissions vidéo ou configurable à l'aide de lecteurs multimédias logiciels sur votre ordinateur personnel. Aujourd'hui, nous allons voir comment mettre en place un flux RTSP pour équipement réseau La technologie Dahua dans l'un des lecteurs multimédias VLC les plus populaires.
RTSP (Real Time Streaming Protocol - protocole de streaming en temps réel) est un protocole qui permet à l'utilisateur de lire à distance un flux de données multimédia (audio et vidéo) à l'aide d'un lien hypertexte et d'un lecteur multimédia (dans notre cas, VLC Media Player).
Si vous devez configurer un flux vidéo, procédez comme suit :
- Tout d'abord, vous devez télécharger et installer VLC Media Player, qui est disponible gratuitement sur le site officiel.
- Cliquez sur l'élément de menu Média (Média) - Ouvrir le flux réseau (Ouvrir l'URL).
- Entrer adresse réseau RTSP à la ligne de conseil.
- Appuyez sur le bouton de lecture lorsque l'image vidéo apparaît à l'écran.
Décryptage du lien RTSP
Exemple:
rtsp:// :@:/cam/realmonitor?channel= &sous-type=
Où :
rtsp://admin : [courriel protégé]:554/cam/realmonitor?channel=1&subtype=1
Les caméras vidéo IP Dahua Technology prennent en charge les protocoles de transfert de données TCP et UDP. Si le port 554 a été modifié, modifiez-le dans le champ correspondant des paramètres de la caméra (interface Web).
Si vous rencontrez des problèmes lors de la configuration d'un flux RTSP, veuillez vous reporter à la section appropriée.