Instrukcja dołączona do kamery CCTV może nie zawsze zawierać informacje o protokole RTSP, według którego działa urządzenie. Istnieje jednak wiele przypadków, w których wymagane jest użycie tego protokołu, więc konieczne staje się znalezienie jego adresu.
Właściciel systemu nadzoru wideo może potrzebować znajomości strumienia RTSP w różnych sytuacjach:
- podłączyć kamerę do serwera w chmurze;
- skonfigurować transmisję informacji wideo na stronę internetową;
- do odtwarzania wideo w strumieniu odtwarzacza na różnych urządzeniach - telefonie komórkowym, laptopie lub tablecie.
Do czego służy protokół RTSP?
Nazwa protokołu RTSP przekłada się na sterowanie online. W ten sposób protokół przesyłania strumieniowego w czasie rzeczywistym pomaga zarządzać strumieniowaniem wideo online. Protokół ten jest bardzo często używany w monitoringu wideo IP, ponieważ zawiera opis niezbędnych poleceń.
Protokół RTSP umożliwia właścicielowi kamery bezpieczeństwa rozwiązanie kilku ważnych funkcji:
- transmisja danych za pomocą VLC;
- transmituj wideo do swoich zasobów i platform;
- skonfigurować rejestratory wideo NVR;
- podłącz kamerę nadzoru wideo z wirtualną pamięcią;
- dodać kamerę wideo do aplikacji mobilnych opartych na systemie Android lub iOS.
Jednocześnie dla wielu użytkowników systemów nadzoru wideo otwarcie strumienia RTSP nie jest łatwe i raczej trudne.
Znajdź adres RTSP kamery monitorującej
Istnieje kilka opcji, które umożliwiają sprawdzenie strumienia RTSP kamery wideo, gdy nie jest on określony w odpowiednich instrukcjach.
Duża liczba kamer IP sprzedawanych w Rosji zawiera chińskie elementy XMEye. Elementy te można zobaczyć nawet u krajowych producentów kamer, takich jak Vesta, HiQ, SVplus i tym podobnych. Kamera takich modeli będzie miała następujący format strumienia RTSP:
rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi
Adres ten zawiera takie elementy jak:
- 192.168.132.32 – bezpośredni adres IP urządzenia;
- 554 – port protokołu (domyślnie ma numer 554, ale ten parametr można zmienić w ustawieniach urządzenia);
- admin - logowanie do kamery monitorującej;
- 12355 – hasło logowania użytkownika.
W przypadku, gdy w kamerze wideo IP są obecne inne komponenty, należy użyć jednej z dwóch wymienionych poniżej opcji.
Pierwsza opcja jest najbardziej uproszczona. Aby znaleźć strumień RTSP z kamery monitorującej, musisz skontaktować się z producentem lub dostawcą tego urządzenia. Na życzenie będą mogli dostarczyć format pożądanego strumienia, a nawet chińscy sprzedawcy mogą świadczyć tę usługę - z fabryk w Chinach lub strony AliExpress.
Drugą opcją jest użycie specjalistycznego oprogramowania. Ta metoda może pomóc, gdy osoba niebędąca właścicielem systemu nadzoru wideo nie ma możliwości lub chęci zażądania adresu strumienia RTSP od dostawcy. Wtedy możesz zrobić to sam za pomocą oprogramowania.
Najpierw musisz pobrać program o nazwie One Device Manager. Po instalacji to oprogramowanie pomoże Ci znaleźć adres RTSP.
Z reguły większość kamer wideo obsługuje protokół onvif, więc nie powinno być żadnych trudności podczas korzystania z oprogramowania. Ważny niuans - do prawidłowego działania należy podłączyć laptopa lub komputer, na którym zostanie zainstalowany program, a także samo urządzenie IP, do tej samej sieci lokalnej.
W sieci można znaleźć całe listy zawierające adresy strumieni RTSP, ponieważ dane te zależą od marki produkującej kamerę do monitoringu wideo.
Jak otworzyć strumień RTSP w kamerze?
Gdy adres strumienia RTSP stanie się znany właścicielowi systemu śledzenia, może on odbierać informacje wideo z kamery IP. Aby otworzyć transmisję strumieniowego wideo, musisz wykonać następującą listę kroków:
- ustawić stały adres IP dla kamery i zamówić ją u dostawcy Internetu;
- przesyłać lokalne żądania pochodzące z kamery wideo do portu RTSP;
- zdać test wydajności.
Adres statyczny można skonfigurować za pomocą programu IP Hunter lub możesz skontaktować się z usługodawcą internetowym i poprosić go o podanie stałego adresu IP jako dodatkowej opcji. Następnie musisz skonfigurować porty przekazywania i przekazywania do portu RTSP z lokalnych portów kamery wideo. Następnie możesz przejść do sprawdzania przepływu.
Aby zrozumieć, czy łącze RTSP działa, możesz otworzyć odtwarzacz VLC i tam go sprawdzić. Aby to zrobić, w menu głównym odtwarzacza musisz kliknąć kategorię „Media” i wybrać element „Otwórz adres URL”. Następnie musisz przejść do zakładki „Sieć” w oknie „Źródło” i określić swój link.
Rozwiązanie problemu transmisji online z kamery IP, generalnie rzecz biorąc, nie wymaga korzystania z WebRTC. Sama kamera jest serwerem, posiada adres IP i może być podłączona bezpośrednio do routera w celu dystrybucji treści wideo. Dlaczego więc korzystać z technologii WebRTC?
Są tego co najmniej dwa powody:
1. Wraz ze wzrostem liczby widzów transmisji Ethernet, najpierw będzie zmniejszać się grubość kanału, a następnie zasoby samej kamery.
2. Jak wspomniano powyżej, kamera IP jest serwerem. Ale za pomocą jakich protokołów będzie mogła przekazać wideo do przeglądarki na komputerze? Urządzenie przenośne? Najprawdopodobniej będzie to przesyłanie strumieniowe HTTP, w którym ramki wideo lub obrazy JPEG są przesyłane przez HTTP. Przesyłanie strumieniowe HTTP notorycznie nie nadaje się do przesyłania strumieniowego wideo w czasie rzeczywistym, chociaż działa dobrze w przypadku wideo na żądanie, gdzie interaktywność strumienia i opóźnienia nie są szczególnie ważne. W rzeczywistości, jeśli oglądasz film, opóźnienie wideo o kilka sekund nie pogorszy sytuacji, chyba że oglądasz film w tym samym czasie co ktoś inny. "O nie! Jack ją zabił! - Alice pisze spoiler na czacie do Boba 10 sekund przed tragicznym rozwiązaniem.
Lub będzie to RTSP/RTP i H.264, w którym to przypadku wtyczka odtwarzacza wideo, taka jak VLC lub QuickTime, musi być zainstalowana w przeglądarce. Taka wtyczka odbierze i odtworzy wideo, podobnie jak sam odtwarzacz. Ale naprawdę potrzebujemy prawdziwego strumieniowania opartego na przeglądarce bez instalowania dodatkowych kul / wtyczek.
Najpierw powąchajmy kamerę IP, aby dowiedzieć się, co dokładnie to urządzenie wysyła do przeglądarki. Obiektem testów będzie kamera D-Link DCS 7010L:
Możesz przeczytać więcej o instalacji i konfiguracji kamery poniżej, ale tutaj zobaczymy tylko, czego używa do przesyłania strumieniowego wideo. Kiedy wejdziesz do panelu administracyjnego kamery przez interfejs sieciowy, widzimy coś takiego (przepraszam za krajobraz):
Obraz otwiera się we wszystkich przeglądarkach i równomiernie podlagivaet, mniej więcej raz na sekundę. Biorąc pod uwagę, że zarówno kamera, jak i laptop, na którym oglądamy stream, są podłączone do tego samego routera, wszystko powinno być płynne i piękne, ale tak nie jest. Podobny do HTTP. Uruchom Wireshark, aby potwierdzić nasze przypuszczenia:
Tutaj widzimy sekwencję fragmentów TCP o długości 1514 bajtów
I końcowy HTTP 200 OK z długością otrzymanego JPEG:
Nie potrzebujemy tego przesyłania strumieniowego. Nie płynnie, ściąga żądania HTTP. Ile takich żądań na sekundę może wytrzymać kamera? Są powody, by sądzić, że przy 10 widzach i wcześniej kamera bezpiecznie się zginie lub zacznie strasznie szklić i wydawać slajdy.
Jeśli zajrzymy do kodu HTML strony administratora aparatu, zobaczymy następujący interesujący kod:
If(przeglądarka_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) //ponieważ ipv6 nie obsługuje rtsp.var host = g_netip; w przeciwnym razie var host = g_host;o+=""; //alert(o); DW(o); )
RTSP/RTP jest tym, czego potrzebujesz do prawidłowego odtwarzania wideo. Ale czy zadziała w przeglądarce? - Nie. Ale jeśli zainstalujesz wtyczkę QuickTime - wszystko będzie działać. Ale robimy wyłącznie strumieniowanie w przeglądarce.
Można tu również wspomnieć o Flash Playerze, który może odbierać strumień RTMP przekonwertowany z RTSP, RTP, H.264 przez odpowiedni serwer, taki jak Wowza. Ale Flash Player, jak wiadomo, jest również wtyczką do przeglądarki, chociaż jest nieporównywalnie bardziej popularny niż VLC czy QuickTime.
W tym przypadku przetestujemy to samo ponowne przesyłanie strumieniowe RTSP/RTP, ale przeglądarka zgodna z WebRTC będzie używana jako urządzenie odtwarzające bez żadnych dodatkowych wtyczek przeglądarki i innych kul. Skonfigurujemy serwer przekaźnikowy, który pobierze strumień z kamery IP i wyśle go do Internetu do dowolnej liczby użytkowników korzystających z przeglądarek obsługujących WebRTC.
Podłączanie kamery IP
Jak wspomniano powyżej, do testów wybrano prostą kamerę IP D-Link DCS-7010L. Kluczowym kryterium wyboru była tutaj obsługa przez urządzenie protokołu RTSP, ponieważ to za jego pośrednictwem nasz serwer pobierze strumień wideo z kamery.Kamerę podłączamy do routera za pomocą dołączonego kabla krosowego. Po włączeniu zasilania i podłączeniu do routera kamera wzięła adres IP przez DHCP, w naszym przypadku był to 192.168.1.34 (Jeśli przejdziesz do ustawień routera, zobaczysz, że urządzenie DCS 7010L jest podłączone - to jest to). Czas przetestować kamerę.
Otwórz określony adres IP w przeglądarce 192.168.1.34, aby przejść do interfejsu sieciowego administratora kamery. Domyślnie nie ma hasła.
Jak widać, wideo z kamery jest transmitowane poprawnie w panelu administracyjnym. Jednocześnie zauważalne jest okresowe zacinanie się. To naprawimy za pomocą WebRTC.
Konfiguracja kamery
Najpierw w ustawieniach kamery wyłączamy uwierzytelnianie – w ramach testów przekażemy strumień każdemu, kto o to poprosi. W tym celu w interfejsie internetowym kamery przejdź do ustawień Konfiguracja-Sieć i ustaw wartość opcji Uwierzytelnianie w trybie Wyłącz.W tym samym miejscu sprawdzamy wartość portu protokołu RTSP, domyślnie jest to 554. Format przesyłanego wideo jest określony przez używany profil. W kamerze można ustawić do trzech z nich, użyjemy pierwszego, live1.sdp - domyślnie jest ustawione na H.264 dla wideo i G.711 dla audio. W razie potrzeby możesz zmienić ustawienia w sekcji Konfiguracja-audio i wideo.
Teraz możesz sprawdzić działanie kamery przez RTSP. Otwórz VLC Player (możesz użyć dowolnego innego, który obsługuje RTSP - QuickTime, Windows Media Player, RealPlayer itp.) i w oknie dialogowym Otwórz URL ustaw adres RTSP kamery: rtsp://192.168.1.34/live1.sdp
Cóż, wszystko działa tak, jak powinno. Kamera prawidłowo odtwarza strumień wideo w odtwarzaczu za pośrednictwem protokołu RTSP.
Nawiasem mówiąc, strumień jest odtwarzany dość płynnie i bez artefaktów. Tego samego oczekujemy od WebRTC.
Instalacja serwera
Tak więc kamera jest zainstalowana, przetestowana z odtwarzaczami stacjonarnymi i gotowa do transmisji przez serwer. Korzystając z whatismyip.com, określamy zewnętrzny adres IP kamery. W naszym przypadku było to 178.51.142.223. Pozostaje powiedzieć routerowi, że podczas uzyskiwania dostępu przez RTSP na porcie 554 przychodzące żądania są przesyłane do kamery IP.Wbijamy odpowiednie ustawienia do routera ...
...i sprawdź zewnętrzny adres IP i port RTSP za pomocą telnetu:
Telnet 178.51.142.223 554
Po upewnieniu się, że na tym porcie jest odpowiedź, przystępujemy do instalacji serwera WebRTC.
Za hosting odpowiadać będzie serwer wirtualny na 64 bitowym Centosie na Amazon EC2.
Aby nie mieć problemów z wydajnością, wybraliśmy instancję m3.medium z jednym VCPU:
Tak, tak, są też Linode i DigitalOcean, ale w tym przypadku chciałem Amazon.
Patrząc w przyszłość napiszę, że w panelu sterowania Amazon EC2 trzeba dodać kilka reguł (forward ports), bez których przykład nie zadziała. Są to porty dla ruchu WebRTC (SRTP, RTCP, ICE) i porty dla ruchu RTSP/RTP. Jeśli spróbujesz, reguły Amazona powinny mieć coś podobnego dla ruchu przychodzącego:
Nawiasem mówiąc, z DigitalOcean wszystko będzie łatwiejsze, wystarczy otworzyć te porty na zaporze lub wyciszyć te ostatnie. Zgodnie z najnowszymi doświadczeniami w obsłudze instancji DO, nadal podają statyczny adres IP i nie zawracają sobie głowy NATami, co oznacza, że przekierowanie portów, jak w przypadku Amazona, nie jest potrzebne.
Użyjemy WebRTC Media & Broadcasting Server Flashphonera jako oprogramowania serwerowego, które przekazuje strumień RTSP/RTP do WebRTC. Serwer strumieniowy jest bardzo podobny do Wowzy, który może przesyłać strumieniowo RTSP/RTP do Flasha. Jedyną różnicą jest to, że ten strumień zostanie przekazany do WebRTC, a nie Flash. Tych. uczciwy DTLS przejdzie między przeglądarką a serwerem, zostanie nawiązana sesja SRTP, a strumień zakodowany w VP8 trafi do przeglądarki.
Aby zainstalować, potrzebujemy dostępu SSH.
Pod spojlerem - szczegółowy opis wykonywanych poleceń
1. Pobierz archiwum instalacyjne serwera:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Wdrożone:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Zainstalowane:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Podczas procesu instalacji wprowadzono zewnętrzny adres IP serwera: 54.186.112.111 oraz wewnętrzny 172.31.20.65 (ten, który jest Prywatnym IP).
4. Uruchomiono serwer:
$service webcallserver start
5. Sprawdzone dzienniki:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Upewniliśmy się, że serwer wystartował i jest gotowy do pracy:
$ps aux | grep Flashphoner
7. Zainstalowany i uruchomiony Apache:
$mniam zainstaluj httpd
$usługa httpd start
8. Pobrałem pliki internetowe i umieściłem je w standardowym folderze 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. Wprowadź adres IP serwera w konfiguracji flashphoner.xml:
10. Zatrzymaj zaporę.
$usługa iptables stop
Teoretycznie zamiast punktu 10 należałoby ustawić wszystkie niezbędne porty i reguły zapory, ale do celów testowych zdecydowaliśmy się po prostu wyłączyć zaporę.
Dostrajanie serwera
Przypomnijmy, że struktura naszej transmisji WebRTC jest następująca:
Zainstalowaliśmy już główne elementy tego schematu, pozostaje ustalenie „strzałek” interakcji.
Połączenie między przeglądarką a serwerem WebRTC zapewnia klient sieciowy, który jest dostępny na github :. Zestaw plików JS, CSS i HTML jest po prostu wrzucany do /var/www/html na etapie instalacji (patrz paragraf 9 powyżej pod spojlerem).
Interakcja między przeglądarką a serwerem jest konfigurowana w konfiguracyjnym pliku XML flashphoner.xml. Należy tam wpisać adres IP serwera, aby klient sieciowy mógł połączyć się z serwerem WebRTC za pośrednictwem Websockets HTML5 (pkt 9 powyżej).
Tutaj kończy się konfiguracja serwera, możesz sprawdzić jego działanie:
Otwieramy stronę klienta WWW index.html w przeglądarce (w tym celu Apache został zainstalowany na tym samym serwerze Amazon za pomocą polecenia mniam -y zainstaluj httpd):
54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp
Tutaj webrtc-ipcam.ddns.net to bezpłatna domena uzyskana za pośrednictwem dynamicznego serwera DNS noip.com, która odnosi się do naszego zewnętrznego adresu IP. Powiedzieliśmy routerowi, aby przekierował żądania RTSP do 192.168.1.34 zgodnie z regułami NAT (patrz również powyżej).
Parametr id=rtsp://webrtc-ipcam.ddns.net/live1.sdp określa adres URL strumienia do odtworzenia. Serwer WebRTC zażąda strumieni z kamery, przetworzy je i wyśle do przeglądarki w celu odtworzenia przez WebRTC. Może twój router obsługuje DDNS. Jeśli nie, to sama kamera IP ma takie wsparcie:
A tak wygląda obsługa DDNS w samym routerze:
Teraz możesz zacząć testować i oceniać wyniki.
Testowanie
Po otwarciu linku w przeglądarce nawiązywane jest połączenie z serwerem WebRTC, który wysyła do kamery IP żądanie odbioru strumienia wideo. Cały proces trwa kilka sekund.
W tym czasie przeglądarka łączy się z serwerem przez websockets, następnie serwer żąda kamery IP przez RTSP, odbiera strumień H.264 przez RTP i transkoduje go do VP8/SRTP - który docelowo odtwarzany jest przez przeglądarkę WebRTC.
W dolnej części wideo wyświetlany jest adres URL strumienia wideo, który można skopiować i otworzyć do oglądania z innej przeglądarki lub karty.
Jesteśmy przekonani, że to naprawdę WebRTC.
Nagle zostaliśmy oszukani, a wideo z kamery IP ponownie przesyłane jest przez HTTP? Nie patrzmy bezczynnie na zdjęcie, tylko sprawdźmy, jaki ruch faktycznie mamy. Oczywiście ponownie uruchamiamy Wireshark i konsolę debugowania w Chrome. W konsoli Chrome przeglądarki możemy zaobserwować:
Tym razem nic nie migocze i nie widać żadnych obrazów przesyłanych przez HTTP. Tym razem widzimy tylko ramki Websocket, a większość z nich to typy ping/pong, aby utrzymać sesję Websocket. Ciekawe ramki: connect, PrepareRtspSession i onReadyToPlay - to kolejność, w jakiej nawiązywane jest połączenie z serwerem: najpierw połączenie Websocket, a następnie żądanie streamu do odtwarzania.
A oto, co to pokazuje chrome://webrtc-internals
Według wykresów mamy bitrate z kamery IP na poziomie 1Mbps. Istnieje również ruch wychodzący, najprawdopodobniej są to pakiety RTCP i ICE. RTT do serwera Amazon to około 300 milisekund.
Teraz spójrzmy na Wireshark, ruch UDP z adresu IP serwera jest tam wyraźnie widoczny. Na poniższym obrazku pakiety 1468 bajtów. To jest WebRTC. Dokładniej, pakiety SRTP przenoszą ramki wideo VP8, które możemy obserwować na ekranie przeglądarki. Dodatkowo żądania STUN są pomijane (najniższy pakiet na obrazku) - jest to WebRTC ICE dokładnie sprawdzający połączenie.
Warto również zwrócić uwagę na stosunkowo małe opóźnienie (ping do centrum danych wynosił około 250 ms) odtwarzania wideo. WebRTC działa przez SRTP/UDP, który jest najszybszym sposobem dostarczania pakietów, w przeciwieństwie do HTTP, RTMP i innych metod przesyłania strumieniowego podobnych do TCP. Tych. latencja widziana okiem powinna być RTT + buforowanie przeglądarki, dekodowanie i czas odtwarzania. Wizualnie, w tym przypadku jest - oko prawie nie widzi opóźnienia, jest to mniej niż 500 milisekund.
Kolejny test to podłączenie innych widzów. Udało mi się otworzyć 10 okien Chrome, a każde z nich pokazywało zdjęcie. W tym samym czasie sam Chrome zaczął trochę stępić. Po otwarciu 11. okna na innym komputerze odtwarzanie pozostało płynne.
O WebRTC na urządzeniach mobilnych
Jak wiesz, WebRTC jest obsługiwany przez przeglądarki Chrome i Firefox na platformie Android.Sprawdźmy, czy będzie tam wyświetlana nasza transmisja:
Na zdjęciu telefon HTC wideo z aparatu jest wyświetlane w przeglądarce Firefox. Nie ma różnic w płynności odtwarzania z pulpitu.
Wniosek
W rezultacie udało nam się uruchomić transmisję na żywo WebRTC z kamery IP do kilku przeglądarek przy minimalnym wysiłku. Nie były wymagane żadne tamburyny ani nauka o rakietach - tylko podstawowa znajomość Linuksa i konsoli SSH.Jakość transmisji była na akceptowalnym poziomie, a opóźnienie odtwarzania było niewidoczne dla oka.
Podsumowując, możemy powiedzieć, że transmisje WebRTC oparte na przeglądarce mają prawo istnieć, ponieważ. w naszym przypadku WebRTC nie jest już kulą ani wtyczką, ale prawdziwą platformą do odtwarzania wideo w przeglądarce.
Dlaczego nie widzimy powszechnego przyjęcia WebRTC?
Być może głównym hamulcem jest brak kodeków. Społeczność i dostawcy WebRTC powinni dołożyć starań, aby wprowadzić kodek H.264 do WebRTC. Nie ma nic do powiedzenia przeciwko VP8, ale po co rezygnować z milionów kompatybilnych urządzeń i oprogramowania współpracującego z H.264? Patenty, takie patenty...Po drugie, nie pełne wsparcie w przeglądarkach. Na przykład w IE i Safari pytanie pozostaje otwarte i tam będziesz musiał przełączyć się na inny rodzaj przesyłania strumieniowego lub użyć wtyczki, takiej jak webrtc4all.
Mamy więc nadzieję, że w przyszłości zobaczymy ciekawsze rozwiązania, które nie będą wymagały transkodowania i konwersji strumieni, a większość przeglądarek będzie w stanie odtwarzać strumienie bezpośrednio z różnych urządzeń.
Często pojawia się pytanie: jak podłączyć kamerę ip do NVR, jeśli nie ma jej na liście kompatybilności?
Istnieją dwie opcje ONVIF i RTSP
Zacznijmy od protokołu ONVIF (Open Network Video Interface Forum)
ONVIF jest wspólnym protokołem dla interoperacyjności kamer IP, NVR, oprogramowania, w przypadku, gdy wszystkie urządzenia pochodzą od różnych producentów. ONVIF można porównać do angielskiego w międzynarodowej komunikacji między ludźmi.
Upewnij się, że podłączone urządzenia obsługują ONVIF, na niektórych urządzeniach ONVIF może być domyślnie wyłączony.
Lub autoryzację ONVIF można wyłączyć, co oznacza, że login/hasło zawsze będzie domyślnym
niezależnie od loginu/hasła do WEB 
Warto również zauważyć, że niektóre urządzenia używająosobny port do pracy w ramach protokołu ONVIF
W niektórych przypadkach hasło ONVIF może różnić się od hasła dostępu WEB.
Co jest dostępne po połączeniu przez ONVIF?
Wykrywanie urządzeń
Przesyłanie danych wideo
Odbieranie i przesyłanie danych audio
Sterowanie PTZ (PTZ)
Analiza wideo (np. detekcja ruchu)
Te opcje zależą od zgodności wersji protokołu ONVIF. W niektórych przypadkach niektóre parametry są niedostępne lub działają nieprawidłowo.
K i przy użyciu ONVIF
W rejestratorach SNR i Dahua protokół ONVIF znajduje się w zakładce Remote Device, Manufacturer line
Wybierz kanał, do którego będzie podłączone urządzenie
Z zakładki Producent wybierz ONVIF
Sprecyzować adres IP urządzenia
RTSP port pozostaje domyślny
Korzystanie z kamer ONVIF port 8080
(od 2017 r. w nowych modelach ONVIF port został zmieniony na 80 dla serii Alpha, Mira)
Kamery OMNY Baza posługiwać się ONVIF port 80, w rejestratorze jest określony jako port HTTP
Nazwać
Hasło zgodnie z parametrami urządzenia
kanał zdalny wartość domyślna to 1. Jeśli urządzenie jest wielokanałowe, wyświetlany jest numer kanału.
Bufor dekodera— buforowanie strumienia wideo z wartością czasu
Rodzaj serweraistnieje możliwość wyboru harmonogramu TCP, UDP
TCP- nawiązuje połączenie między nadawcą a odbiorcą, dba o to, aby wszystkie dane docierały do adresata bez zmian i w pożądanej kolejności, reguluje również prędkość transmisji.
W przeciwieństwie do TCP, UDP nie nawiązuje wstępnego połączenia, ale po prostu rozpoczyna transmisję danych. UDP nie śledzi otrzymywanych danych i nie powiela ich w przypadku utraty lub błędu.
UDP jest mniej niezawodny niż TCP. Ale z drugiej strony zapewnia szybsze przesyłanie strumieniowe ze względu na brak retransmisji utraconych pakietów.
Harmonogram— automatyczne wykrywanie typu.
Tak wyglądają podłączone urządzenia w Dahua
Zielony status oznacza, że rejestrator i kamera są połączone pomyślnie
Czerwony status oznacza, że występują problemy z połączeniem. Na przykład port połączenia jest nieprawidłowy.
Drugim sposobem na połączenie jest RTSP(Protokół przesyłania strumieniowego w czasie rzeczywistym) 
RTSPprotokół przesyłania strumieniowego w czasie rzeczywistym, który opisuje polecenia sterujące strumieniem wideo.
Za pomocą tych poleceń strumień wideo jest transmitowany od źródła do odbiorcy.
na przykład z kamery IP do rejestratora lub serwera.
Co jest dostępne podczas łączenia przez RTSP?
Przesyłanie danych wideo
Odbieranie i przesyłanie danych audio
korzyśćtego protokołu przesyłania, ponieważ nie wymaga zgodności wersji.
Obecnie RTSP jest obsługiwany przez prawie wszystkie kamery IP i NVR.
niedogodności Protokół polega na tym, że nic innego nie jest dostępne poza transmisją danych wideo i audio.
Spójrzmy na przykład podłączenia kamery do i za pomocą RTSP
.jpg)
RTSP znajduje się w zakładce Remote Device, Manufacturer line, w rejestratorze SNR i Dahua jest prezentowany jakoOgólny
Wybierz kanał, do którego będzie podłączone urządzenie
Adres URL- tutaj wpisujemy ciąg zapytania, za pomocą którego kamera powraca podstawowy Strumień RTSP z wysoki rezolucja.
Dodatkowy adres URL - tutaj wprowadź ciąg zapytania, za pomocą którego kamera powraca dodatkowy Strumień RTSP z niska rozdzielczość.
Przykład żądania:
rtsp://172.16.31.61/1 główny strumień
rtsp://172.16.31.61/2 dodatkowy wątek
Dlaczego potrzebujesz dodatkowego strumienia?
Na lokalnym monitorze podłączonym do rejestratora wieloobrazowego rejestrator wykorzystuje dodatkowy wątek w celu oszczędzania zasobów. Na przykład na małych obrazkach 16 okien wcale nie jest konieczne dekodowanie rozdzielczości Full HD, wystarczy D1. Cóż, jeśli w tym przypadku otworzyłeś okna 1/4/8, główny strumień jest dekodowany z wysoką rozdzielczością.
Nazwaćzgodnie z parametrami urządzenia
Hasło zgodnie z parametrami urządzenia
Bufor dekoderabuforowanie strumienia wideo z wartością czasu
Rodzaj serwera- TCP, UDP, Harmonogram (podobny do protokołu ONVIF)
Ten artykuł odpowiada na najczęściej zadawane pytania, takie jak:
Czy kamera IP jest kompatybilna z NVR?
A jeśli jest kompatybilny, to jak podłączyć!?
Protokół RTSP
RTSP (Real Time Streaming Protocol lub, w języku rosyjskim, protokół przesyłania strumieniowego w czasie rzeczywistym) to protokół aplikacji opisujący polecenia sterujące strumieniem wideo. Za pomocą tych poleceń możemy „rozkazać” kamerze lub serwerowi np. rozpoczęcie nadawania strumienia wideo. Przykładowe żądanie rozpoczęcia odtwarzania wygląda następująco: PLAY rtsp://192.168.0.200/h264 RTSP/1.0
Oznacza to, że RTSP to tylko zestaw poleceń do sterowania strumieniem wideo. Zróbmy eksperyment. Aby to zrobić, potrzebujemy kamery IP obsługującej protokół RTSP i jej adres RTSP. Ten adres wygląda mniej więcej tak: rtsp://
Protokół TCP
Załóżmy, że wybraliśmy metodę RSTP przez TCP i chcemy rozpocząć transmisję strumienia wideo. Co się stanie na poziomie mechanizmów transportowych? Wcześniej za pomocą kilku poleceń zostanie nawiązane połączenie między nadawcą a odbiorcą. Następnie rozpocznie się przesyłanie danych wideo. Jednocześnie mechanizmy TCP
zapewni, że wszystkie dane dotrą do adresata w niezmienionej postaci i we właściwej kolejności. TCP będzie również regulował prędkość transmisji, aby nadajnik nie wysyłał danych intensywniej niż odbiornik może je przetworzyć, np.
UDP jest alternatywą dla protokołu transportowego TCP. W przeciwieństwie do protokołu TCP, UDP nie nawiązuje wstępnego połączenia, lecz po prostu rozpoczyna transmisję danych. UDP nie upewnia się, że dane są odbierane i nie powiela ich, jeśli brakuje części lub są odbierane z błędami. mniej UDP
niezawodny niż TCP. Ale z drugiej strony zapewnia szybsze przesyłanie strumieniowe ze względu na brak mechanizmu retransmisji utraconych pakietów. Różnicę między protokołami TCP i UTP można zilustrować następującym przykładem. Spotykają się dwaj przyjaciele. Opcja TCP:
Ivan: Cześć! Może poczatujemy?" (połączenie nawiązane)
Szymon: „Cześć! Chodźmy!” (połączenie nawiązane)
Ivan: „Wczoraj byłem w sklepie. Czy rozumiesz?" (transfer danych)
Szymon: „Tak!” (potwierdzenie)
Ivan: „Rozładowywali nowy sprzęt. Czy rozumiesz?" (transfer danych)
Siemion: „Nie” (potwierdzenie)
Ivan: „Rozładowywali nowy sprzęt. Czy rozumiesz?" (retransmisja)
Szymon: „Tak!” (potwierdzenie)
Ivan: „Jutro znów tam będę. Czy rozumiesz?" (transfer danych)
Szymon: „Tak!” (potwierdzenie)
Wariant UDP
Ivan: Cześć! Poszedłem wczoraj do sklepu” (transmisja danych)
Ivan: „Rozładowywali nowy sprzęt” (transmisja danych)
Ivan: „Jutro znów tam będę” (transmisja danych)
Ivan: „Mogę uzyskać ceny” (transmisja danych)
Ivan: „Obiecali zniżki za dobre ilości” (transmisja danych)
Ivan: „Jak chcesz, dzwoń – pojedziemy razem” (transmisja danych)
Siemion: „Tak, zadzwonię” (transmisja danych)
Możesz również zobaczyć różnicę w protokołach, wykonując następujący eksperyment: spróbuj ustawić kamerę w trybie RTSP przez TCP i pomachaj ręką przed obiektywem - zobaczysz opóźnienie na ekranie monitora. Teraz uruchom ten sam test w trybie RTSP przez UDP. Opóźnienie będzie mniejsze. Na czas opóźnienia wpływa kilka czynników: format kompresji, moc komputera, protokół transmisji i funkcje oprogramowania zaangażowanego w dekodowanie wideo.
RTP (Real-time Transport Protocol) lub protokół transportu w czasie rzeczywistym w języku rosyjskim. Ten protokół jest specjalnie zaprojektowany do przesyłania ruchu w czasie rzeczywistym. Pozwala monitorować synchronizację przesyłanych danych, dostosowywać kolejność dostarczania pakietów i dlatego jest bardziej odpowiedni niż inne do przesyłania danych wideo i audio. Ogólnie rzecz biorąc, do przesyłania strumienia wideo preferowane jest użycie protokołu RTP lub UDP. Praca przez TCP jest uzasadniona tylko wtedy, gdy musimy pracować z problematycznymi sieciami, ponieważ protokół TCP będzie w stanie poprawić błędy i awarie, które pojawiają się podczas przesyłania danych.
Jak sprawdzić możliwość nadawania strumienia RTSP z kamery IP w różnych przeglądarkach internetowych?
Sprawdźmy wyświetlanie strumienia wideo RTSP w przeglądarkach Chrome, Firefox, Safari na komputerach stacjonarnych z systemem Windows, Mac OS X, Linux i urządzeniach mobilnych z systemem Android i iOS
Sprawdzanie strumienia RTSP w VLC
Aby szybko upewnić się, że strumień RTSP jest dostępny i przesyła strumieniowo wideo, otwórz go w odtwarzaczu VLC. Jeśli strumień jest odtwarzany poprawnie, przystępujemy do testowania interfejsu sieciowego. Możesz uzyskać adres URL RTSP w panelu sterowania kamery IP lub użyć publicznie dostępnego strumienia wideo RTSP, takiego jak ten: rtsp://b1.dnsdojo.com:1935/live/sys3.stream
Testowanie strumienia RTSP-WebRTC w przeglądarkach Google Chrome i Mozilla Firefox
Upewniamy się, że ten sam strumień RTSP jest odtwarzany na zwykłej stronie HTML w przeglądarkach Chrome i Firefox.
1. Pobierz interfejs demonstracyjny w , menu „Demo / Streaming Min”. Jest to minimalny interfejs sieciowy HTML5, który wykorzystuje technologię WebRTC do wyświetlania strumienia wideo RTSP w przeglądarkach Chrome i Firefox.
2. Nawiąż połączenie z serwerem połączeń internetowych
3. Wprowadź adres RTSP kamery i rozpocznij odtwarzanie strumienia:
W rezultacie pomyślnie przetestowaliśmy odtwarzanie strumienia RTSP w przeglądarce Google Chrome. Podobny test można przeprowadzić w przeglądarkach Firefox i Opera na tych platformach stacjonarnych i mobilnych, które obsługują technologię WebRTC w przeglądarkach.
Testowanie strumienia RTSP-Websocket w przeglądarce Safari pod iOS i Mac OS X
Przeglądarki na urządzeniach z systemem iOS nie obsługują technologii WebRTC. Z tego powodu używany jest oddzielny odtwarzacz „WS Player Min”, który pobiera strumień za pośrednictwem protokołu Websocket i odtwarza go w elemencie HTML5-Canvas przeglądarki.
1. Podobnie jak w przypadku Chrome, musisz otworzyć stronę interfejsu demonstracyjnego, ale wybierz inny element menu:
2. Następnie nawiąż połączenie z Web Call Server
3. Wprowadź znany wcześniej adres transmisji RTSP i odtwórz strumień wideo:
Powyżej pokazano zatem możliwość przeglądania ruchu konwertowanego za pomocą Web Call Server RTSP na większości popularnych przeglądarek internetowych, w tym na najpopularniejszych platformach mobilnych.
Następnym krokiem jest dodanie odtwarzacza HTML5 RTSP do własnej witryny. Proces dodawania został szczegółowo opisany w sąsiedniej sekcji Implementacja.
Filmy opisujące proces testowania RTSP-WebRTC i RTSP-Websocket player
Odtwarzacz RTSP-WebRTC dla Chrome i Firefox
RTSP Websocket Player dla iOS Safari
Pobierz serwer połączeń internetowych 5
Wymagania systemowe: Linux x86_64, 1 rdzeń procesora, 2 GB pamięci RAM, Java
Instalacja:
- wget https://website/download-wcs5.2-server.tar.gz
- Rozpakuj i zainstaluj za pomocą skryptu "install.sh"
- Uruchom serwer za pomocą polecenia „service webcallserver start”
- Otwórz interfejs sieciowy https://host:8444 i aktywuj licencję
Jeśli korzystasz z serwerów Amazon EC2, nie musisz niczego pobierać.
