Jak uzyskać strumień RTSP z kamery? Adres, test i problemy

Strumień RTSP to jeden z tematów, przy których pozornie prosta kwestia szybko okazuje się wielowarstwowym problemem technicznym. RTSP samo w sobie nie przesyła wideo – pełni rolę protokołu sterowania sesją, a właściwe dane wideo transportuje RTP. Ten artykuł wyjaśnia, jak uzyskać działający adres RTSP z kamery, jak go przetestować i co zrobić, gdy coś nie działa.

Najważniejsze informacje z tego artykułu:

• Adres URL strumienia RTSP zależy od producenta, modelu, firmware’u i numeru kanału – nie istnieje jeden uniwersalny format.
• Kamery zgodne z ONVIF udostępniają poprawny adres RTSP przez operację GetStreamUri, co eliminuje konieczność zgadywania ścieżki.
• Transport RTP przez UDP daje niższe opóźnienia, ale jest wrażliwy na NAT i firewall; RTP przez TCP jest stabilniejszy, ale może zwiększać opóźnienie.
• Brak obrazu przy poprawnym adresie RTSP często wynika z niezgodności kodeka, brakujących parametrów SPS/PPS lub oczekiwania na pierwszą klatkę kluczową IDR.
• Port 554 należy traktować jako punkt wejścia do sesji RTSP, a nie jako kanał transmisji wideo – dane RTP są wysyłane na osobno negocjowane porty UDP.

Jak uzyskać strumień RTSP z kamery – od adresu do działającego połączenia?

Żeby uzyskać strumień RTSP z kamery, potrzebujesz czterech rzeczy: adresu IP kamery, numeru portu (domyślnie 554), danych logowania oraz właściwej ścieżki strumienia. Format adresu URL wygląda tak:

rtsp://użytkownik:hasło@adres_IP:554/ścieżka_strumienia

Przykład dla kamery z adresem 192.168.1.50, loginem admin i hasłem admin123:

rtsp://admin:admin123@192.168.1.50:554/stream1

Problem w tym, że ścieżka /stream1 jest tylko przykładem. Każdy producent stosuje własny format ścieżki RTSP i nie istnieje jeden adres działający dla wszystkich kamer. Poniżej opisuję, jak tę ścieżkę ustalić w sposób pewny.

Metoda 1 – ONVIF GetStreamUri (kamery z obsługą ONVIF)

Jeśli kamera obsługuje ONVIF (standard stosowany przez większość sieciowych kamer IP), nie zaczynaj od zgadywania ścieżki. Procedura jest następująca:

1. Ustal adres usługi ONVIF – najczęściej http://ADRES_KAMERY/onvif/device_service.
2. Wywołaj operację GetProfiles, żeby pobrać listę profili wideo.
3. Wybierz profil odpowiadający strumieniowi, który chcesz odebrać (np. główny lub pomocniczy).
4. Wywołaj GetStreamUri dla wybranego tokena profilu.
5. Kamera zwróci gotowy adres URI RTSP – skopiuj go i użyj w kliencie.

To podejście jest pewniejsze od szukania adresów w internecie, bo adres RTSP zależy od profilu, kanału, kodeka i wariantu strumienia. Dwa urządzenia tego samego producenta mogą zwracać różne ścieżki, jeśli różnią się firmware’em albo regionem sprzedaży. Dotyczy to w szczególności urządzeń z rebrandingiem OEM – kamery Dahua, Hikvision, BCS, Kenik, Annke czy HiLook mogą wyglądać identycznie sprzętowo, ale obsługiwać inne endpointy RTSP.

Warto wiedzieć, że WS-Discovery, które służy do automatycznego wykrywania urządzeń ONVIF w sieci, korzysta z multicastu na adresie 239.255.255.250 i UDP/3702. Nie przechodzi przez routery, VLAN-y ani wiele konfiguracji Wi-Fi – brak automatycznego wykrycia nie oznacza więc braku obsługi ONVIF ani RTSP.

Kamery obsługujące ONVIF Profile T (dla H.265, metadanych, zdarzeń analitycznych i dwukierunkowego audio) zwracają adres RTSP przez tę samą procedurę, ale klient musi obsługiwać H.265, żeby obraz był widoczny.

Metoda 2 – dokumentacja producenta i znane ścieżki

Jeśli kamera nie ma ONVIF, adres RTSP trzeba ustalić na podstawie dokumentacji producenta lub interfejsu webowego kamery. Poniżej przykłady formatów spotykanych u różnych producentów:

Traktuj te adresy jako punkt wyjścia, a nie gwarancję działania – konkretna ścieżka zależy od wersji firmware’u i modelu. W urządzeniach wielokanałowych (rejestratory NVR, kamery wieloobiektywowe) ścieżka wymaga numeru kanału, a numer w URL-u nie zawsze odpowiada fizycznemu obiektywowi w kamerach fisheye lub termowizyjnych.

Wiele kamer udostępnia jednocześnie kilka strumieni RTSP:

• Main stream – pełna rozdzielczość, do nagrywania.
• Sub stream – mniejsza rozdzielczość, do podglądu na żywo.
• Third stream – jeśli dostępny, zazwyczaj do analityki.

Pobieranie głównego strumienia 4K tylko do podglądu lub detekcji AI niepotrzebnie obciąża kamerę i sieć. Do analityki i detekcji obiektów warto pobierać substream o stałej liczbie klatek i mniejszej rozdzielczości.

Wskazówka: Jeśli hasło zawiera znaki specjalne (@, :, #, %, /, ?, &), zakoduj je w formacie URL przed umieszczeniem w adresie RTSP. Znak @ to %40, : to %3A. Odtwarzacze błędnie interpretują niezakodowane znaki jako część adresu lub parametrów zapytania, co objawia się błędem autoryzacji mimo poprawnego hasła.

Jak sprawdzić i włączyć RTSP w ustawieniach kamery?

Większość kamer IP ma RTSP domyślnie włączony, ale część tańszych modeli – szczególnie przeznaczonych do pracy z chmurą P2P – może go wyłączać lub w ogóle go nie udostępniać.

Żeby sprawdzić i włączyć RTSP:

1. Otwórz interfejs webowy kamery (zazwyczaj pod jej adresem IP w przeglądarce).
2. Przejdź do sekcji konfiguracji sieci lub ustawień wideo (nazwy różnią się zależnie od producenta).
3. Odszukaj zakładkę RTSP lub Video Streaming.
4. Sprawdź, czy RTSP jest włączony i na jakim porcie działa.
5. Zapisz lub skopiuj ścieżkę strumienia widoczną w ustawieniach.

Jeśli kamera działa wyłącznie przez aplikację producenta z połączeniem P2P (przez chmurę), może nie udostępniać RTSP w sieci lokalnej – mimo że podgląd na telefonie działa. W takim przypadku RTSP jest niedostępne bez zmiany trybu pracy urządzenia, a część modeli nie daje tej możliwości.

Kiedy projektuję lub dobieram kamery do systemów wymagających integracji z oprogramowaniem VMS, Frigate czy Home Assistant, pierwszą rzeczą, którą sprawdzam, jest właśnie dostępność lokalnego RTSP – bo obecność podglądu w aplikacji producenta absolutnie nie gwarantuje, że kamera udostępnia strumień RTSP.

Jak przetestować strumień RTSP?

Przed konfiguracją docelowego systemu warto sprawdzić adres RTSP prostym narzędziem. Najszybciej zrobisz to przez FFmpeg lub VLC.

Test przez FFmpeg (ffplay) z wymuszonym transportem TCP:

ffplay -rtsp_transport tcp "rtsp://użytkownik:hasło@192.168.1.50:554/ścieżka"

Diagnostyka kodeka i parametrów SDP przez ffprobe:

ffprobe -rtsp_transport tcp -show_streams -show_format "rtsp://użytkownik:hasło@192.168.1.50:554/ścieżka"

Test przez VLC: Otwórz VLC → Media → Otwórz strumień sieciowy → wklej adres RTSP.

Jeśli strumień działa przez TCP, przetestuj też UDP i porównaj stabilność:

ffplay -rtsp_transport udp "rtsp://użytkownik:hasło@192.168.1.50:554/ścieżka"

Po udanym teście możesz skonfigurować docelowe oprogramowanie – VMS, OpenCV, Frigate, ZoneMinder, Home Assistant czy inny system. Przy integracji z NVR lub systemem detekcji AI warto testować stabilność przez 12–24 godziny, bo część kamer poprawnie startuje sesję RTSP, ale zrywa ją po przepełnieniu bufora, odnowieniu tokenu lub o zmianie nocy i dnia.

Czym jest RTSP i jak naprawdę działa?

RTSP (Real Time Streaming Protocol) nie transportuje wideo – pełni rolę protokołu sterowania sesją, podobnie jak pilot do telewizora kontroluje odtwarzacz, ale sam nie jest dźwiękiem ani obrazem. Właściwe dane wideo i audio są przenoszone przez protokół RTP (Real-time Transport Protocol), któremu towarzyszą pakiety kontrolne RTCP.

Typowa sesja przebiega w czterech krokach:

1. DESCRIBE – klient pyta kamerę o opis sesji; kamera zwraca SDP (Session Description Protocol) z informacjami o kodeku, rozdzielczości, klatkażu i ścieżkach audio-wideo.
2. SETUP – klient konfiguruje transport dla każdej ścieżki i negocjuje porty UDP lub tryb TCP.
3. PLAY – kamera zaczyna wysyłać pakiety RTP z danymi wideo.
4. TEARDOWN – zakończenie sesji.

To oznacza, że sam otwarty port 554 (domyślny port RTSP) nie gwarantuje odbioru obrazu. Przy transporcie RTP przez UDP kamera wysyła dane wideo na osobne, negocjowane porty UDP po stronie klienta. Jeśli te porty są blokowane przez firewall, sesja RTSP nawiązuje się poprawnie, ale obraz nie dociera.

Badania nad stosem RTSP/RTP/RTCP pokazują, że w dobrze skonfigurowanych środowiskach sieciowych skuteczność dostarczania pakietów może sięgać około 97%. W lokalnych sieciach LAN opóźnienia end-to-end przy RTSP over UDP mieszczą się typowo w zakresie 100–300 ms, a przy RTSP over TCP wynoszą 200–500 ms. W sieciach WAN klienci RTSP zazwyczaj dodają kilka sekund bufora dla stabilności, co przekłada się na opóźnienia rzędu 2–10 sekund.

Jak wybrać transport – UDP czy TCP?

Wybór transportu RTP ma bezpośredni wpływ na stabilność i opóźnienie strumienia. Porównanie:

Przy problemach z obrazem przez UDP pierwsze, co warto sprawdzić, to czy firewall nie blokuje dynamicznych portów RTP – sam port 554 może być otwarty, ale media nadal nie docierają. Wymuszenie TCP rozwiązuje ten problem jednym poleceniem.

Wskazówka: Jeśli RTSP działa lokalnie, ale nie przez przekierowanie portów z internetu, sam port 554 to za mało – RTP/UDP wymaga przepuszczenia dodatkowych portów negocjowanych w SETUP. Bezpieczniejsze jest wymuszenie RTP over TCP albo dostęp przez VPN.

Kodeki, SDP i czarny obraz – co naprawdę blokuje odbiór strumienia?

Poprawny adres RTSP to dopiero połowa sukcesu. Drugą połową jest zgodność kodeka i parametrów strumienia z klientem odbiorczym.

Czarny obraz przy poprawnym URL-u to jeden z częstszych problemów – i rzadko wynika z błędnego adresu. Sprawdź kolejno:

• Czy klient otrzymał odpowiedź SDP z komendą DESCRIBE?
• Czy SDP zawiera parametry sprop-parameter-sets (SPS i PPS dla H.264)?
• Czy do klienta docierają pakiety RTP?
• Czy przyszła pierwsza klatka IDR (klatka kluczowa, od której dekoder może zacząć dekodowanie)?
• Czy kamera nie publikuje H.265, mimo że klient obsługuje tylko H.264?
• Czy strumień nie jest ustawiony na H.264+ lub H.265+ (smart codec), który nie jest zgodny z uniwersalnymi klientami?

SPS (Sequence Parameter Set) i PPS (Picture Parameter Set) to parametry niezbędne do inicjalizacji dekodera H.264. Ich utrata lub brak przy każdej klatce kluczowej powoduje czarny obraz albo artefakty do czasu otrzymania kolejnego zestawu parametrów. Część kamer nie wysyła SPS/PPS przy każdym IDR – w takich sytuacjach pomocne jest użycie FFmpeg lub GStreamer jako pośrednika, który normalizuje strumień.

W kamerach z długim GOP (Group of Pictures) pierwsza klatka może pojawić się kilka sekund po połączeniu, bo klient czeka na IDR. Skrócenie interwału I-frame w ustawieniach kamery poprawia czas startu strumienia kosztem wyższego bitrate’u.

Warto też zwrócić uwagę na liczbę równoczesnych sesji RTSP – część kamer blokuje jednoczesne połączenia na tym samym koncie lub profilu. Utworzenie osobnego konta tylko do odczytu strumienia często eliminuje losowe rozłączenia w NVR lub systemie analityki.

Jak diagnozować problemy ze strumieniem RTSP?

Diagnozę warto prowadzić warstwowo, zaczynając od podstaw sieciowych:

Warstwa IP – sprawdź dostępność kamery:

ping ADRES_KAMERY
nc -vz ADRES_KAMERY 554

Otwarty port 554 oznacza działający endpoint TCP, ale jeszcze nie poprawną ścieżkę RTSP.

Warstwa RTSP – zweryfikuj odpowiedzi protokołu:

Najważniejsze kody odpowiedzi RTSP:

• 401 – brak uwierzytelnienia lub błędne dane logowania.
• 404 – nieistniejący URI strumienia.
• 454 – nieistniejąca sesja RTSP.
• 461 – nieobsługiwany transport.
• 500/503 – błąd po stronie kamery lub przeciążenie.

Warstwa RTP – analiza pakietów w Wireshark:

Filtruj ruch: rtsp, rtp, rtcp, udp.port == NEGOCJOWANY_PORT. Jeśli widoczne są DESCRIBE i SETUP, ale brak pakietów RTP, problem leży w firewallu lub adresie docelowym. Jeśli RTP dociera, ale brak obrazu – analizuj payload type, SPS/PPS i obsługę kodeka.

Warstwa dekodera – ffprobe:

ffprobe -rtsp_transport tcp -show_streams "rtsp://użytkownik:hasło@IP:554/ścieżka"

ffprobe pokaże kodek, rozdzielczość, klatkaż, profil H.264 i dostępne ścieżki audio. Przy H.264 warto sprawdzić, czy dekoder dostaje IDR i czy nie pojawiają się komunikaty o brakujących reference frames.

Kiedy przy wdrożeniach natrafiałem na problem z brakiem obrazu mimo poprawnego adresu RTSP, bardzo często winowajcą okazywał się H.265 lub H.265+ w kamerze przy kliencie obsługującym tylko H.264. Wystarczyło w ustawieniach kamery przełączyć koder na H.264, żeby obraz pojawił się natychmiast.

Jak kontrolować opóźnienie strumienia RTSP?

Opóźnienie end-to-end w strumieniu RTSP to suma wielu składowych – od czujnika przez enkoder, bufor transportowy, jitterbuffer, aż po dekoder i renderer. Każdy etap dokłada swoje milisekundy.

Przy monitoringu czasu rzeczywistego warto stosować taką konfigurację:

• H.264 zamiast H.265, jeśli dekoder jest ograniczony sprzętowo.
• Krótki GOP i stała liczba klatek w ustawieniach kamery.
• RTP/UDP w kontrolowanej sieci lokalnej, RTP/TCP przy Wi-Fi i VPN.
• Bufor jittera (latency) 50–300 ms zależnie od stabilności sieci.

Przy użyciu GStreamer domyślna wartość bufora jittera w elemencie rtspsrc wynosi 2000 ms, co tłumaczy pozornie duże opóźnienie w aplikacjach korzystających z domyślnej konfiguracji. Zmniejszenie parametru latency do 100–200 ms redukuje opóźnienie, ale zwiększa ryzyko zacięć przy zmiennym jitterze. Przykład pipeline’u:

gst-launch-1.0 rtspsrc location="rtsp://user:haslo@192.168.1.50:554/stream" protocols=tcp latency=200 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! autovideosink sync=false

Agresywne zmniejszenie bufora nie rozwiąże problemu leżącego w enkorderze – jeśli kamera ma długi GOP, wysoki bitrate lub niestabilne znaczniki czasu RTP, efektem będą artefakty, a nie niższe opóźnienie.

Przy integracji strumienia z systemami detekcji AI, jak Frigate podłączony do kamery Synology czy inne rozwiązania NVR, lepiej pobierać substream o mniejszej rozdzielczości i stałym klatkażu. Opóźnienie inferencji i dekodowania jest wtedy ważniejsze niż szczegółowość obrazu.

Jak zadbać o bezpieczeństwo strumienia RTSP?

Klasyczne rtsp:// nie szyfruje transmisji. Hasło przesyłane metodą Basic Authentication jest zakodowane jedynie w Base64, a dane wideo mogą być odczytane przez każdego z dostępem do segmentu sieci.

Zalecana architektura bezpiecznego dostępu do strumienia RTSP:

• Umieść kamery w osobnym VLAN-ie i ogranicz ich dostęp do internetu.
• Dostęp do strumienia realizuj przez VPN.
• Wyłącz anonimowy dostęp RTSP.
• Stosuj Digest Authentication zamiast Basic – RFC 7826 wskazuje Basic jako właściwy wyłącznie przez połączenie chronione TLS.
• Utwórz osobne konto z uprawnieniami tylko do podglądu strumienia.
• Ogranicz dostęp firewallem do konkretnych adresów systemów VMS lub analityki.
• Rotuj hasła i monitoruj liczbę równoczesnych sesji.

RTSP 2.0 definiuje rtsps:// jako RTSP przez TLS z domyślnym portem 322. TLS chroni zarówno sygnalizację RTSP, jak i osadzone pakiety RTP przy trybie interleaved over TCP. Obsługa rtsps jest jednak wciąż rzadka w tańszych kamerach.

Wskazówka: Nie wystawiaj portu RTSP bezpośrednio do internetu. Samo przekierowanie TCP/554 nie rozwiązuje problemu z RTP/UDP – media mogą być wysyłane na osobno negocjowane porty UDP. VPN albo wymuszenie RTP over TCP to podejście zarówno stabilniejsze, jak i bezpieczniejsze. Warto też zadbać o właściwe zabezpieczenie kamer IP na poziomie całej instalacji.

Przy planowaniu infrastruktury sieciowej dla kamer IP warto też zwrócić uwagę na dobór przełącznika sieciowego do kamer IP – odpowiednia przepustowość i obsługa PoE mają bezpośredni wpływ na stabilność strumieni RTSP, szczególnie przy większej liczbie kamer z wyższymi rozdzielczościami.

Jeśli kamera wykazuje problemy z łącznością, zanim zaczniesz diagnozować RTSP, sprawdź warunki sieciowe. Słaby sygnał Wi-Fi może powodować przerwy w strumieniu, dlatego w takich przypadkach warto wiedzieć, jak wzmocnić sygnał kamery bezprzewodowej. Z kolei jeśli kamera raportuje tryb offline, problem może leżeć poza warstwą RTSP – przyczyny trybu offline kamery bywają zróżnicowane i warto je wykluczyć przed głębszą diagnostyką protokołu.

Podsumowanie

Uzyskanie strumienia RTSP z kamery wymaga ustalenia czterech elementów: adresu IP, portu, danych logowania i właściwej ścieżki. Kamery zgodne z ONVIF pozwalają pobrać gotowy adres przez operację GetStreamUri, co eliminuje zgadywanie. Bez ONVIF ścieżkę trzeba ustalić z dokumentacji producenta lub interfejsu webowego kamery. Poprawny adres RTSP to dopiero punkt wyjścia – stabilny odbiór zależy od zgodności kodeka, wyboru transportu (UDP lub TCP), konfiguracji bufora jittera i bezpieczeństwa sieci. Przetestuj strumień przez ffplay lub VLC zanim skonfigurujesz docelowy system.

FAQ

Q: Czy kamery działające przez chmurę P2P obsługują RTSP?

A: Nie zawsze. Kamery pracujące wyłącznie przez aplikację producenta z chmurą P2P często nie udostępniają lokalnego RTSP. Podgląd w aplikacji nie oznacza dostępności strumienia RTSP w sieci lokalnej.

Q: Czy można zmienić domyślny port RTSP z 554 na inny?

A: Tak, większość kamer IP pozwala zmienić port RTSP w ustawieniach sieciowych. Niestandardowy port trzeba podać wprost w adresie URL, np. rtsp://użytkownik:hasło@IP:8554/ścieżka.

Q: Ile równoczesnych sesji RTSP może obsłużyć kamera?

A: Limit zależy od modelu i producenta. Tańsze kamery mogą obsługiwać 1–2 równoczesne sesje, droższe kilka lub kilkanaście. Przekroczenie limitu skutkuje odmową połączenia lub rozłączaniem aktywnych sesji.

Q: Czy VLC obsługuje RTSP over TCP?

A: Tak. W VLC można wymusić TCP przez Narzędzia → Preferencje → Wejście/Kodeki → Domyślny transport strumieniowania: TCP. Alternatywnie opcję transport TCP można ustawić w zaawansowanych parametrach odtwarzania.

Q: Jak sprawdzić, czy kamera obsługuje ONVIF bez dedykowanego oprogramowania?

A: Możesz wysłać zapytanie HTTP POST na adres http://ADRES_KAMERY/onvif/device_service z prostym żądaniem SOAP GetDeviceInformation. Jeśli kamera odpowie kodem 200 i danymi producenta, obsługuje ONVIF. Narzędzia takie jak ONVIF Device Manager robią to automatycznie.