Exact rtsp-streamformaat. Hoe u de mogelijkheid kunt controleren om een RTSP-stream vanaf een IP-camera in verschillende webbrowsers uit te zenden. Latency testen VLC versus WebRTC

RTSP (Real Time Streaming Protocol)– een real-time streamingprotocol dat een eenvoudige set basisopdrachten bevat voor het besturen van een videostream.

RTSP-bronnen en IP-camera's aansluiten in videoconferenties

Dankzij het RTSP-protocol kan elke TrueConf-gebruiker verbinding maken met IP-videocamera's en andere bronnen van media-inhoud die gebruikmaken van dit protocol om externe objecten te monitoren. De gebruiker kan ook verbinding maken met dergelijke camera's om beelden uit te zenden tijdens een videoconferentie.

Dankzij RTSP-protocolondersteuning kunnen TrueConf Server-gebruikers niet alleen verbinding maken met IP-camera's, maar ook videoconferenties uitzenden naar RTSP-spelers en mediaservers. Lees meer over RTSP-uitzendingen.

Voordelen van het gebruik van IP-camera's met TrueConf-softwareoplossingen

Door een IP-camera in een kantoor of industriële werkplaats te installeren en er op elk gewenst moment verbinding mee te maken, kunt u het productieproces van uw bedrijf controleren.
U kunt objecten op afstand 24 uur per dag in de gaten houden. Als u bijvoorbeeld op vakantie gaat en uw appartement niet onbeheerd wilt achterlaten, installeert u daar eenvoudig één of meerdere IP-camera's. Door een van deze camera's te bellen vanaf uw pc waarop de TrueConf-clienttoepassing is geïnstalleerd, kunt u op elk gewenst moment verbinding maken met uw appartement en in realtime zien wat daar gebeurt.
In TrueConf-clienttoepassingen voor Windows, Linux en macOS hebben alle gebruikers toegang tot de mogelijkheid om videoconferenties op te nemen, waardoor u tijdens videobewaking alle gebeurtenissen kunt opnemen en er schriftelijk bewijs van kunt ontvangen.

De vraag rijst vaak: hoe sluit je een IP-camera aan op een NVR als deze niet op de compatibiliteitslijst staat?

Er zijn twee opties ONVIF en RTSP

Laten we beginnen met het ONVIF-protocol (Open Network Video Interface Forum)

ONVIF is een algemeen geaccepteerd protocol voor de gezamenlijke bediening van IP-camera's, NVR's, software, in het geval dat alle apparaten van verschillende fabrikanten zijn. ONVIF kan worden vergeleken met de Engelse taal voor internationale communicatie van mensen.

Zorg ervoor dat de aangesloten apparaten ONVIF ondersteunen; op sommige apparaten is ONVIF mogelijk standaard uitgeschakeld.
Of de ONVIF-autorisatie is mogelijk uitgeschakeld, wat betekent dat de login/het wachtwoord altijd standaard is
ongeacht login/wachtwoord voor WEB

Het is ook vermeldenswaard dat sommige apparaten gebruik maken vanaparte poort voor bediening via ONVIF-protocol

In sommige gevallen kan het ONVIF-wachtwoord verschillen van het WEB-toegangswachtwoord.

Wat is er beschikbaar bij verbinding via ONVIF?

Apparaatdetectie

Video-overdracht

Ontvangst en verzending van audiogegevens

PTZ-camerabediening

Videoanalyse (zoals bewegingsdetectie)

Deze parameters zijn afhankelijk van de compatibiliteit van ONVIF-protocolversies. In sommige gevallen zijn sommige parameters niet beschikbaar of werken ze niet correct.

K en met behulp van ONVIF

Bij SNR- en Dahua-recorders bevindt het ONVIF-protocol zich op het tabblad Extern apparaat, op de regel Fabrikant

Selecteer het kanaal waarmee het apparaat wordt verbonden

Selecteer op het tabblad Fabrikant ONVIF

Specificeer ip-adres apparaten

RTSP poort blijft standaard

Camera's gebruiken ONVIF poort 8080
(sinds 2017 is op nieuwe ONVIF-modellen de poort gewijzigd naar 80 voor de Alpha- en Mira-series)
OMNY-camera's Baseren gebruik ONVIF poort 80, in de registrar wordt dit aangegeven als een HTTP-poort

Naam

Wachtwoord volgens apparaatparameters

Kanaal op afstand standaard is 1. Als het apparaat meerkanaals is, wordt het kanaalnummer aangegeven.

Decoderbuffer— buffering van de videostream die de tijdswaarde aangeeft

Servertypehier is er een keuze uit TCP- en UDP-schema

TCP- brengt een verbinding tot stand tussen zender en ontvanger, zorgt ervoor dat alle gegevens ongewijzigd en in de gewenste volgorde de ontvanger bereiken en regelt bovendien de transmissiesnelheid.

In tegenstelling tot TCP, UDP brengt geen voorlopige verbinding tot stand, maar begint in plaats daarvan eenvoudigweg met het verzenden van gegevens. UDP controleert niet of gegevens zijn ontvangen en dupliceert deze niet in geval van verlies of fouten.

UDP is minder betrouwbaar dan TCP. Maar aan de andere kant zorgt het voor een snellere transmissie van streams vanwege de afwezigheid van hertransmissie van verloren pakketten

Schema— automatische typedetectie.

Zo zien verbonden apparaten eruit in Dahua

Groene status betekent dat de recorder en camera succesvol zijn verbonden

Een rode status betekent dat er verbindingsproblemen zijn. De verbindingspoort is bijvoorbeeld onjuist.

De tweede verbindingsmethode is RTSP(Real-time streamingprotocol)

RTSPeen real-time streamingprotocol dat opdrachten beschrijft voor het besturen van een videostream.

Met behulp van deze opdrachten wordt de videostream uitgezonden van de bron naar de ontvanger

bijvoorbeeld van een IP-camera naar een DVR of server.

Wat is er beschikbaar bij verbinding via RTSP?

Video-overdracht

Ontvangst en verzending van audiogegevens

VoordeelDit overdrachtsprotocol houdt in dat er geen versiecompatibiliteit vereist is.

Tegenwoordig wordt RTSP ondersteund door bijna alle IP-camera's en NVR's

Gebreken Het protocol is dat er behalve de overdracht van video- en audiogegevens niets anders beschikbaar is.

Laten we eens kijken naar een voorbeeld van het aansluiten van een camera naar en met behulp van RTSP

RTSP op het tabblad Remote Device, Fabrikant, in de SNR- en Dahua-recorder wordt het weergegeven alsAlgemeen

Selecteer het kanaal waarmee het apparaat wordt verbonden

URL-adres- hier voeren we de querystring in waarvoor de camera verzendt eenvoudig RTSP-stream met hoog oplossing.

Extra URL - Hier voer de querystring in waarvoor de camera verzendt aanvullend RTSP-stream met lage resolutie.

Voorbeeld verzoek:

rtsp://172.16.31.61/1 hoofdstream

rtsp://172.16.31.61/2 extra stream

Waarom heb je een extra draad nodig?

Op een lokale monitor die is aangesloten op de meerbeeldenrecorder, gebruikt de recorder een extra thread om bronnen te besparen. Bij kleine afbeeldingen met 16 vensters is het bijvoorbeeld helemaal niet nodig om de Full HD-resolutie te decoderen, D1 is voldoende. Welnu, als je 1/4/8 vensters hebt geopend, wordt in dit geval de hoofdstream met hoge resolutie gedecodeerd.

Naamvolgens apparaatparameters

Wachtwoord volgens apparaatparameters

Decoderbufferbufferen van videostream die de tijdswaarde aangeeft

Servertype- TCP, UDP, Schedule (vergelijkbaar met ONVIF-protocol)

Dit artikel geeft antwoord op de meest voorkomende vragen, zoals:

Is de IP-camera compatibel met de NVR?

En als het compatibel is, hoe maak je dan verbinding!?

Voor het oplossen van het probleem van online uitzenden vanaf een IP-camera is over het algemeen geen gebruik van WebRTC vereist. De camera zelf is een server, heeft een IP-adres en kan rechtstreeks op de router worden aangesloten om videocontent te distribueren. Dus waarom WebRTC-technologie gebruiken?

Daar zijn minstens twee redenen voor:

1. Naarmate het aantal kijkers van een Ethernet-uitzending toeneemt, zal eerst het gebrek aan kanaaldikte voelbaar zijn, en daarna de middelen van de camera zelf.

2. Zoals hierboven vermeld is de IP-camera een server. Maar welke protocollen kan het gebruiken om video naar de desktopbrowser te sturen? Mobiel apparaat? Hoogstwaarschijnlijk zal dit HTTP-streaming zijn, waarbij videoframes of JPEG-afbeeldingen via HTTP worden verzonden. HTTP-streaming is, zoals u weet, niet helemaal geschikt voor realtime videostreaming, hoewel het zichzelf goed heeft bewezen in on-demand video, waar stream-interactiviteit en latentie niet bijzonder belangrijk zijn. Als je naar een film kijkt, zal een vertraging van een paar seconden het niet erger maken, tenzij je de film tegelijkertijd met iemand anders bekijkt. "O nee! Jack heeft haar vermoord! - Alice schrijft een spoiler in de chat met Bob 10 seconden voor het tragische einde.”

Of het zal RTSP/RTP en H.264 zijn, in welk geval een plug-in voor een videospeler zoals VLC of QuickTime in de browser moet worden geïnstalleerd. Zo'n plug-in kan video opnemen en afspelen, net als de speler zelf. Maar we hebben echte browsergebaseerde streaming nodig zonder extra krukken/plug-ins te installeren.

Laten we eerst een foto maken van de IP-camera om erachter te komen wat dit apparaat precies naar de browser verzendt. De proefpersoon is de D-Link DCS 7010L camera:

Hieronder kunt u meer lezen over het installeren en configureren van de camera, maar hier kijken we alleen naar wat deze gebruikt voor videostreaming. Wanneer we via de webinterface het camerabeheerderspaneel betreden, zien we zoiets als dit (sorry voor het landschap):

De afbeelding wordt in alle browsers geopend en loopt gelijkmatig vast, ongeveer één keer per seconde. Gezien het feit dat zowel de camera als de laptop waarop we de stream bekijken op dezelfde router zijn aangesloten, zou alles soepel en mooi moeten zijn, maar dit is niet het geval. Lijkt op HTTP. Laten we Wireshark lanceren om onze vermoedens te bevestigen:

Hier zien we een reeks TCP-fragmenten van 1514 bytes lang

En een laatste HTTP 200 OK met de lengte van de ontvangen JPEG:

We hebben dit soort streaming niet nodig. Niet soepel, schokt HTTP-verzoeken. Hoeveel van dergelijke verzoeken per seconde kan de camera aan? Er is reden om aan te nemen dat bij tien toeschouwers of eerder de camera veilig zal buigen of vreselijk gaat haperen en dia's zal produceren.

Als je naar de HTML-pagina van het camerabeheerpaneel kijkt, zie je deze interessante code:

Als(browser_IE) DW(""); else ( if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; if (g_isIPv6) //omdat ipv6 geen rtsp ondersteunt. var host = g_netip; anders var host = g_host;"; //waarschuwing(o); DW(o); )

RTSP/RTP is precies wat u nodig heeft voor een goede videoweergave. Maar werkt dit ook in de browser? - Nee. Maar als u de QuickTime-plug-in installeert, werkt alles. Maar we doen puur browsergebaseerde streaming.

Hier kunnen we ook Flash Player noemen, die via een geschikte server zoals Wowza een RTMP-stream kan ontvangen die is geconverteerd van RTSP, RTP, H.264. Maar Flash Player is, zoals u weet, ook een browserplug-in, hoewel deze onvergelijkbaar populairder is dan VLC of QuickTime.

In dit geval zullen we dezelfde RTSP/RTP re-streaming testen, maar een WebRTC-compatibele browser zal worden gebruikt als afspeelapparaat zonder extra browserplug-ins of andere krukken. We zullen een relayserver opzetten die de stream van de IP-camera overneemt en naar internet stuurt naar een willekeurig aantal gebruikers die browsers gebruiken die WebRTC ondersteunen.

Een IP-camera aansluiten

Zoals hierboven vermeld werd er voor het testen gekozen voor een eenvoudige D-Link DCS-7010L IP-camera. Het belangrijkste selectiecriterium hier was de ondersteuning van het apparaat voor het RTSP-protocol, omdat onze server hierdoor de videostream van de camera ontvangt.

Met behulp van het meegeleverde patchsnoer verbinden we de camera met de router. Nadat de stroom was ingeschakeld en verbinding was gemaakt met de router, nam de camera een IP-adres via DHCP, in ons geval was dit 192.168.1.34 (als u naar de routerinstellingen gaat, ziet u dat het DCS 7010L-apparaat is aangesloten - dat is alles ). Het is tijd om de camera te testen.

Open het opgegeven IP-adres in de browser 192.168.1.34 om naar de webinterface van de camerabeheerder te gaan. Standaard is er geen wachtwoord.

Zoals u kunt zien, wordt de video van de camera correct uitgezonden in het beheerderspaneel. Tegelijkertijd is periodiek schudden merkbaar. Dit is wat we zullen oplossen met behulp van WebRTC.

Camera-instelling

Eerst schakelen we authenticatie uit in de camera-instellingen - als onderdeel van het testen geven we de stream aan iedereen die erom vraagt. Ga hiervoor naar de instellingen in de camerawebinterface Installatie - Netwerk en stel de optiewaarde in Verificatie om uit te schakelen.

Daar controleren we ook de waarde van de RTSP-protocolpoort; standaard is deze 554. Het formaat van de verzonden video wordt bepaald door het gebruikte profiel. Je kunt er maximaal drie in de camera instellen, we gebruiken de eerste, live1.sdp - standaard is deze geconfigureerd om H.264 voor video en G.711 voor audio te gebruiken. U kunt de instellingen indien nodig wijzigen in de sectie Installatie – Audio en video.

Nu kun je via RTSP de werking van de camera controleren. Open VLC Player (u kunt elke andere speler gebruiken die RTSP ondersteunt - QuickTime, Windows Media Player, RealPlayer, enz.) en stel in het dialoogvenster Open URL het RTSP-adres van de camera in: rtsp://192.168.1.34/live1.sdp

Nou ja, alles werkt zoals het moet. De camera geeft de videostream regelmatig weer in de speler via het RTSP-protocol.

De stream wordt overigens behoorlijk soepel en zonder artefacten afgespeeld. Wij verwachten hetzelfde van WebRTC.

Serverinstallatie

De camera is dus geïnstalleerd, getest met desktopspelers en klaar voor uitzending via de server. Met behulp van whatismyip.com bepalen we het externe IP-adres van de camera. In ons geval was dit 178.51.142.223. Het enige dat overblijft is om de router te vertellen dat bij toegang via RTSP op poort 554 inkomende verzoeken naar de IP-camera worden verzonden.

Voer de juiste instellingen in de router in...

...en controleer het externe IP-adres en de RTSP-poort met behulp van telnet:

Telnet 178.51.142.223 554

Nadat we ervoor hebben gezorgd dat er een reactie op deze poort is, gaan we verder met het installeren van de WebRTC-server.

Een virtuele server op Centos 64 bit op Amazon EC2 zal verantwoordelijk zijn voor de hosting.
Om prestatieproblemen te voorkomen, hebben we gekozen voor een m3.medium-instantie met één VCPU:

Ja, ja, er zijn ook Linode en DigitalOcean, maar in dit geval wilde ik Amazon proberen.
Vooruitkijkend zal ik schrijven dat je in het Amazon EC2-configuratiescherm verschillende regels moet toevoegen (poorten doorsturen), zonder welke het voorbeeld niet zal werken. Dit zijn poorten voor WebRTC-verkeer (SRTP, RTCP, ICE) en poorten voor RTSP/RTP-verkeer. Als je het probeert, zouden de regels van Amazon iets soortgelijks moeten hebben voor inkomend verkeer:

Trouwens, met DigitalOcean zal alles eenvoudiger zijn, open gewoon deze poorten op de firewall of schakel deze laatste uit. Volgens de laatste ervaringen met het gebruik van DO-instanties geven ze nog steeds een statisch IP-adres af en maken ze zich geen zorgen over NAT's, wat betekent dat port forwarding, zoals in het geval van Amazon, niet nodig is.

We zullen WebRTC Media & Broadcasting Server van Flashphoner gebruiken als serversoftware die de RTSP/RTP-stream doorstuurt naar WebRTC. De streamingserver lijkt sterk op Wowza, die een RTSP/RTP-stream naar Flash kan streamen. Het enige verschil is dat deze stream naar WebRTC wordt gestuurd en niet naar Flash. Die. eerlijke DTLS gaat tussen de browser en de server, er wordt een SRTP-sessie tot stand gebracht en de in VP8 gecodeerde stream gaat naar de kijker.

Voor de installatie hebben we SSH-toegang nodig.

Onder de spoiler vindt u een gedetailleerde beschrijving van de uitgevoerde opdrachten

1. Het serverinstallatiearchief gedownload:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Uitgebreid:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Geïnstalleerd:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Tijdens het installatieproces hebben we het externe IP-adres van de server ingevoerd: 54.186.112.111 en intern 172.31.20.65 (hetzelfde als Private IP).
4. Start de server:
$service webcallserver starten
5. Controleer de logboeken:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. We hebben ervoor gezorgd dat de server is gestart en klaar is om te werken:
$ps aux | grep Flitsfoon
7. Apache geïnstalleerd en gestart:
$yum installeer httpd
$service httpd start
8. De webbestanden gedownload en in de standaard Apache-map /var/www/html geplaatst
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Voer het IP-adres van de server in de flashphoner.xml-configuratie in:
10. De firewall gestopt.
$service iptables stoppen

In theorie zou het in plaats van punt 10 correct zijn om alle noodzakelijke poorten en firewallregels in te stellen, maar voor testdoeleinden hebben we besloten om de firewall eenvoudigweg uit te schakelen.

Serverconfiguratie

Laten we niet vergeten dat de structuur van onze WebRTC-uitzending als volgt is:

We hebben de belangrijkste elementen van dit diagram al geïnstalleerd; het enige dat overblijft is het vaststellen van de ‘pijlen’ van interacties.

De verbinding tussen de browser en de WebRTC-server wordt verzorgd door een webclient, die beschikbaar is op Github:. Er wordt eenvoudigweg een reeks JS-, CSS- en HTML-bestanden in gegooid /var/www/html tijdens de installatiefase (zie punt 9 hierboven onder de spoiler).

De interactie tussen de browser en de server wordt geconfigureerd in het XML-configuratiebestand flashphoner.xml. Daar moet u het IP-adres van de server invoeren, zodat de webclient via HTML5 Websockets (punt 9 hierboven) verbinding kan maken met de WebRTC-server.

De serverinstallatie eindigt hier. U kunt de werking ervan controleren:

Open de webclientpagina index.html in de browser (hiervoor werd Apache op dezelfde Amazon-server geïnstalleerd met de opdracht yum -y installeer httpd):

54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp

Hier webrtc-ipcam.ddns.net is een gratis domein verkregen via de dynamische DNS-server noip.com, die verwijst naar ons externe IP-adres. We hebben de router verteld om RTSP-verzoeken om te leiden naar 192.168.1.34 in overeenstemming met de NAT-netwerkadresvertaalregels (zie ook hierboven).
Parameter id=rtsp://webrtc-ipcam.ddns.net/live1.sdp specificeert de URL van de stream die moet worden afgespeeld. De WebRTC-server vraagt streams van de camera op, verwerkt deze en stuurt deze naar de browser om via WebRTC af te spelen. Mogelijk ondersteunt uw router DDNS. Zo niet, dan heeft de IP-camera zelf dergelijke ondersteuning:

En zo ziet DDNS-ondersteuning eruit in de router zelf:

Nu kunt u beginnen met testen en de resultaten evalueren.

Testen

Na het openen van de link in de browser wordt er verbinding gemaakt met de WebRTC-server, die een verzoek stuurt naar de IP-camera om de videostream te ontvangen. Het hele proces duurt een paar seconden.

Op dit moment wordt er via websockets een verbinding tot stand gebracht tussen de browser en de server, waarna de server de IP-camera opvraagt via RTSP, de H.264-stream ontvangt via RTP en deze transcodeert naar VP8/SRTP - die uiteindelijk de WebRTC-browser afspeelt.

Onderaan de video wordt de URL van de videostream weergegeven, die kan worden gekopieerd en geopend voor weergave vanuit een andere browser of tabblad.

Wij zorgen ervoor dat dit echt WebRTC is.

Wat als we worden misleid en de video van de IP-camera opnieuw via HTTP wordt verzonden? Laten we niet werkeloos naar de afbeelding kijken, maar laten we eens kijken wat voor soort verkeer we daadwerkelijk ontvangen. Natuurlijk lanceren we Wireshark en de foutopsporingsconsole opnieuw in Chrome. In de Chrome-browserconsole kunnen we het volgende zien:

Deze keer knippert er niets en worden er geen beelden zichtbaar verzonden via HTTP. Het enige dat we deze keer zien zijn Websocket-frames en de meeste daarvan zijn ping/pong-types om een Websocket-sessie te onderhouden. Interessante frames: connect, prepareRtspSession en onReadyToPlay - dit is de volgorde waarin een verbinding met de server tot stand wordt gebracht: eerst een Websocket-verbinding en vervolgens een streamverzoek om af te spelen.

Dit is wat het laat zien chrome://webrtc-internals

Volgens de grafieken hebben we een bitrate van de IP-camera van 1Mbps. Er is ook uitgaand verkeer, hoogstwaarschijnlijk zijn dit RTCP- en ICE-pakketten. De RTT naar de Amazon-server is ongeveer 300 milliseconden.

Laten we nu naar Wireshark kijken. U kunt duidelijk UDP-verkeer zien vanaf het IP-adres van de server. In de onderstaande afbeelding zijn de pakketten 1468 bytes. Dit is WebRTC. Om precies te zijn: SRTP-pakketten met VP8-videoframes, die we op het browserscherm kunnen waarnemen. Bovendien glippen STUN-verzoeken door (het laagste pakket op de foto) - dit is WebRTC ICE die de verbinding zorgvuldig controleert.

Het is ook de moeite waard om de relatief lage latentie (ping naar het datacenter was ongeveer 250 ms) bij het afspelen van video op te merken. WebRTC werkt via SRTP/UDP en dit is tenslotte de snelste manier om pakketten af te leveren, in tegenstelling tot HTTP, RTMP en andere TCP-achtige streamingmethoden. Die. De voor het oog zichtbare vertraging moet RTT + de tijd van bufferen, decoderen en afspelen door de browser zijn. Visueel is dit in dit geval het geval: het oog ziet de vertraging bijna niet, deze is minder dan 500 milliseconden.

De volgende test is het verbinden van andere kijkers. Het lukte me om 10 Chrome-vensters te openen, en in elk daarvan stond een afbeelding. Tegelijkertijd begon Chrome zelf een beetje saai te worden. Bij het openen van het 11e venster op een andere computer verliep het afspelen soepel.

Over WebRTC op mobiele apparaten

Zoals u weet, wordt WebRTC ondersteund door Chrome- en Firefox-browsers op het Android-platform.
Laten we eens kijken of onze uitzending daar wordt weergegeven:

De afbeelding toont een HTC-telefoon; de Firefox-browser geeft video van de camera weer. Er zijn geen verschillen in de soepelheid van het afspelen vanaf het bureaublad.

Conclusie

Het resultaat was dat we met minimale inspanning een WebRTC online uitzending vanaf een IP-camera naar verschillende browsers konden lanceren. Er was geen dansen met een tamboerijn of raketwetenschap vereist - alleen basiskennis van Linux en de SSH-console.

De kwaliteit van de uitzending was van een acceptabel niveau en de afspeelvertraging was voor het oog onzichtbaar.

Samenvattend kunnen we zeggen dat browsergebaseerde WebRTC-uitzendingen bestaansrecht hebben, omdat in ons geval is WebRTC niet langer een kruk of een plug-in, maar een echt platform voor het afspelen van video in de browser.

Waarom zien we geen wijdverbreide adoptie van WebRTC?

Het belangrijkste obstakel is misschien wel het gebrek aan codecs. De WebRTC-gemeenschap en leveranciers moeten hun best doen en de H.264-codec in WebRTC introduceren. Er valt niets tegen VP8 te zeggen, maar waarom zou je miljoenen compatibele apparaten en software opgeven die met H.264 werken? Patenten, zulke patenten...

Op de tweede plaats staat geen volledige ondersteuning in browsers. Bij IE en Safari blijft de vraag bijvoorbeeld open en daar zul je moeten overstappen naar een andere vorm van streaming of een plugin als webrtc4all moeten gebruiken.

We hopen dus in de toekomst meer interessante oplossingen te zien waarbij transcodering en conversie van streams niet nodig zullen zijn en de meeste browsers streams van verschillende apparaten rechtstreeks kunnen afspelen.

Als u problemen ondervindt bij het installeren of bedienen van het product, lees dan de veelgestelde vragen en de antwoorden daarop.

Hoe krijg ik een REVISOR VMS-cadeaulicentie?

Volg de instructies om een Revisor VMS-cadeaulicentie te ontvangen. Instructies downloaden.

Ik heb een RedLine IP-camera van 1,3 MP. Ik probeer ActiveX te installeren, maar de foutmelding "HTTP 404 - niet gevonden" verschijnt. Wat moet ik doen?

In 1,3 MP-videocamera's is de ActiveX-module niet ingebouwd; deze moet worden geïnstalleerd vanaf de schijf die in de kit zit of worden gedownload via de link

Voor 4MP-camera's:

rtsp://admin:123456@IP-adres:554/ch01/0 - hoofdthread

rtsp://admin:123456@IP-adres:554/ch01/1 - extra stream

rtsp://admin:123456@IP-adres:554/streaming/mjpeg - mjpeg-stream

Voor 1,3 MP- en 2 MP-camera's

rtsp://admin:123456@IP-adres:554/streaming/video0 - hoofdstream

rtsp://admin:123456@IP-adres:554/streaming/video1 - extra stream

Welke software is geschikt voor mobiele apparaten?

Welke poorten zijn nodig om via het netwerk te werken?

80 - webinterface

554-rtsp (video)stream

4900 - mobiel haven

9988 - Voor clientverbindingen met 4MP IP-camera's

Wat moet ik doen als het geluid op de recorder of software van derden niet werkt?

Om audio te verzenden, moet u de audiotransmissie activeren in de instellingen op het tabblad NETWERK - RTSP-stream.

De hoeveelheid in beslag genomen ruimte is afhankelijk van de geselecteerde opnamekwaliteit en bewegingsfrequentie (bij opname via detectie). Om het archief te berekenen, kunt u Schijfcalculatorsoftware gebruiken.

Hoe vind ik een IP-camera op een lokaal netwerk?

Installeer de software en voer het uit als beheerder. In het venster dat verschijnt, ziet u een lijst met apparatuur die op het lokale netwerk is aangesloten.

Om de netwerkinstellingen te wijzigen, moet u de apparatuur in het bovenste veld selecteren en in het onderste veld de netwerkinstellingen (IP-adres, masker, gateway) opgeven, de gebruikersnaam en het wachtwoord invoeren en op de knop Wijzigen klikken. In de toekomst moet u het opgegeven IP-adres gebruiken om verbinding te maken

Voor 1,3 MP en 2 MP IP-camera's aanbevolen om te gebruiken

Hoe voeg ik een 1,3 MP IP-camera toe aan CVMS?

Als de camera zich op het lokale netwerk bevindt, klik dan in de weergavemodus in het menu Apparaten (aan de linkerkant) met de rechtermuisknop en selecteer "Snel zoeken", selecteer vervolgens de gewenste camera en geef het wachtwoord op.

Als de verbinding via internet tot stand wordt gebracht, klik dan in de weergavemodus in het menu Apparaten (aan de linkerkant) met de rechtermuisknop en selecteer "Apparaat toevoegen" en voer de verbindingsgegevens in, TCP-POORT MOET WORDEN GESPECIFICEERD (standaard 1115)

Hoe u de mogelijkheid kunt controleren om een RTSP-stream vanaf een IP-camera in verschillende webbrowsers uit te zenden

Laten we de weergave van een RTSP-videostream in Chrome, Firefox, Safari-browsers op desktops met Windows, Mac OS X, Linux en mobiele apparaten met Android en iOS controleren

De RTSP-stream controleren in VLC

Om er snel zeker van te zijn dat de RTSP-stream beschikbaar is en video streamt, opent u deze in de VLC-speler. Als de stream correct wordt afgespeeld, gaan we verder met het testen van de webinterface. U kunt de RTSP-URL opvragen in het configuratiescherm van de IP-camera of een openbare RTSP-videostream gebruiken, bijvoorbeeld deze: rtsp://b1.dnsdojo.com:1935/live/sys3.stream

RTSP-WebRTC-stream testen in de browsers Google Chrome en Mozilla Firefox

Wij zorgen ervoor dat dezelfde RTSP-stream wordt afgespeeld op een reguliere HTML-pagina in de Chrome- en Firefox-browsers.

1. Laad de demo-interface via menu ‘Demo / Streaming Min’. Dit is een minimale HTML5-webinterface die WebRTC-technologie gebruikt om een RTSP-videostream weer te geven in Chrome- en Firefox-browsers.

2. Breng een verbinding tot stand met de Web Call Server

3. Voer het RTSP-adres van de camera in en begin met het afspelen van de stream:

Als gevolg hiervan hebben we met succes het afspelen van de RTSP-stream in de Google Chrome-browser getest. Een soortgelijke test kan worden uitgevoerd met de Firefox- en Opera-browsers op desktop- en mobiele platforms die WebRTC-technologie in browsers ondersteunen.

Testen van een RTSP-Websocket-stream in de Safari-browser onder iOS en Mac OS X

Browsers op iOS-apparaten ondersteunen geen WebRTC-technologie. Om deze reden wordt een aparte speler ‘WS Player Min’ gebruikt, die de stream via het Websocket-protocol haalt en afspeelt in het HTML5-Canvas-element van de browser.

1. Net als bij Chrome moet u de demo-interfacepagina openen, maar een ander menu-item selecteren:

2. Breng hierna een verbinding tot stand met de Web Call Server

3. Voer het eerder bekende RTSP-uitzendadres in en speel de videostream af:

Het bovenstaande demonstreert dus de mogelijkheid om RTSP-verkeer dat is geconverteerd met behulp van Web Call Server te bekijken op de meest gebruikelijke webbrowsers, inclusief de meest populaire mobiele platforms.

De volgende stap is het toevoegen van een HTML5 RTSP-speler aan uw eigen website. Het toevoegingsproces wordt in detail beschreven in het aangrenzende Implementatiegedeelte.