{"id":12951,"date":"2026-09-09T18:25:00","date_gmt":"2026-09-09T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12951"},"modified":"2026-09-09T13:21:24","modified_gmt":"2026-09-09T11:21:24","slug":"tutorial-budowanie-i-sprawdzanie-adresow-rtsp-kamer-ip","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/cctv-pl\/tutorials-pl-cctv-pl\/tutorial-budowanie-i-sprawdzanie-adresow-rtsp-kamer-ip\/","title":{"rendered":"Tutorial: Budowanie i sprawdzanie adres\u00f3w RTSP kamer IP"},"content":{"rendered":"

Kamera IP przesy\u0142a obraz przez RTSP, a RTSP jest znormalizowany. Adres prowadz\u0105cy do obrazu ju\u017c nie. Ka\u017cdy producent wymy\u015bli\u0142 w\u0142asn\u0105 \u015bcie\u017ck\u0119, a kamera zapytana pod z\u0142\u0105 \u015bcie\u017ck\u0105 odpowiada dok\u0142adnie tak samo jak przy z\u0142ym ha\u015ble: wcale.<\/p>\n

Taki adres sk\u0142ada si\u0119 z sze\u015bciu cz\u0119\u015bci. Cztery wygl\u0105daj\u0105 jednakowo w ka\u017cdej kamerze, dwie trzeba sprawdzi\u0107 u konkretnego producenta. Poni\u017cej kolejno\u015b\u0107, w jakiej najlepiej te cz\u0119\u015bci z\u0142o\u017cy\u0107, oraz jedno polecenie rozstrzygaj\u0105ce, czy wynik dzia\u0142a – zanim trafi do rejestratora, gdzie b\u0142\u0105d chowa si\u0119 za sze\u015bcioma innymi ustawieniami.<\/p>\n

\n\"Adres
Tylko dwa ostatnie odcinki r\u00f3\u017cni\u0105 si\u0119 zale\u017cnie od producenta. Wszystko przed nimi jest identyczne w ka\u017cdej kamerze.<\/figcaption><\/figure>\n

Sze\u015b\u0107 cz\u0119\u015bci adresu strumienia<\/h2>\n

Adres RTSP jest zbudowany jak adres internetowy: schemat, dane logowania, host, port, \u015bcie\u017cka, a w cz\u0119\u015bci kamer jeszcze ci\u0105g zapytania nios\u0105cy numer strumienia.<\/p>\n

rtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/Streaming\/Channels\/102\nrtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/cam\/realmonitor?channel=1&subtype=1\nrtsps:\/\/192.168.1.1:7441\/aBcD1234EfGh?enableSrtp<\/code><\/pre>\n
Schemat to rtsp<\/code>, a port 554, dop\u00f3ki nikt go nie przeni\u00f3s\u0142. Ubiquiti stanowi wyj\u0105tek wart zapami\u0119tania: UniFi Protect odpowiada na rtsps<\/code> na porcie 7441, odrzuca zwyk\u0142e RTSP i zamiast czytelnej \u015bcie\u017cki wydaje nieprzejrzysty identyfikator. Ten identyfikator pojawia si\u0119 dopiero po w\u0142\u0105czeniu RTSP dla pojedynczej kamery w Protect.<\/p>\n
Host oznacza kamer\u0119, nigdy rejestrator. Rejestrator potrafi wystawi\u0107 strumie\u0144 ponownie, ale wtedy pod w\u0142asnym adresem i na w\u0142asnym porcie – a b\u0142\u0105d na tej warstwie wygl\u0105da jak uszkodzona kamera.<\/p>\n
Dlaczego \u015bcie\u017cka w ka\u017cdej kamerze nazywa si\u0119 inaczej<\/h2>\n
\u015acie\u017cka niesie dwie informacje, dla kt\u00f3rych sam RTSP nie ma pola: kt\u00f3ry obiektyw i kt\u00f3ry z jego strumieni. Niemal ka\u017cda kamera oferuje co najmniej dwa – strumie\u0144 g\u0142\u00f3wny w pe\u0142nej rozdzielczo\u015bci do zapisu i podstrumie\u0144 o czwartej cz\u0119\u015bci tej rozdzielczo\u015bci do podgl\u0105du i analizy ruchu.<\/p>\n\n\n\n\n\n\n\n\n
Producent<\/th>\nStrumie\u0144 g\u0142\u00f3wny<\/th>\nPodstrumie\u0144<\/th>\n<\/tr>\n<\/thead>\n
Hikvision<\/td>\n\/Streaming\/Channels\/101<\/td>\n\/Streaming\/Channels\/102<\/td>\n<\/tr>\n
Dahua, Amcrest<\/td>\n\/cam\/realmonitor?channel=1&subtype=0<\/td>\n\/cam\/realmonitor?channel=1&subtype=1<\/td>\n<\/tr>\n
Reolink<\/td>\n\/h264Preview_01_main<\/td>\n\/h264Preview_01_sub<\/td>\n<\/tr>\n
Axis<\/td>\n\/axis-media\/media.amp<\/td>\n\/axis-media\/media.amp?resolution=640×360<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Numeracja Hikvision jest przekr\u0119cana najcz\u0119\u015bciej. Trzy cyfry to sklejone ze sob\u0105 kana\u0142 i strumie\u0144: z 1 oraz 01 powstaje 101, drugi strumie\u0144 pierwszego kana\u0142u to 102. W kamerze z jednym obiektywem kana\u0142 zawsze wynosi 1; w obudowie z kilkoma matrycami drugi obiektyw nosi numery 201 i 202.<\/p>\n
Zgadywanie staje si\u0119 zb\u0119dne, gdy kamera obs\u0142uguje ONVIF. Wywo\u0142anie GetStreamUri<\/code> zwraca adres, kt\u00f3ry sama kamera uwa\u017ca za poprawny, wraz ze \u015bcie\u017ck\u0105 – a ta odpowied\u017a bije ka\u017cd\u0105 tabel\u0119.<\/p>\n
Has\u0142a, kt\u00f3re rozbijaj\u0105 adres<\/h2>\n
Dane logowania stoj\u0105 mi\u0119dzy schematem a hostem, oddzielone dwukropkiem i zamkni\u0119te znakiem ma\u0142py. W\u0142a\u015bnie tam siedzi najcichszy b\u0142\u0105d: has\u0142o zawieraj\u0105ce ma\u0142p\u0119, dwukropek, uko\u015bnik lub krzy\u017cyk ko\u0144czy dane logowania za wcze\u015bnie, a reszta has\u0142a zostaje odczytana jako nazwa hosta.<\/p>\n
Lekarstwem jest kodowanie procentowe. Ma\u0142pa zamienia si\u0119 w %40<\/code>, dwukropek w %3A<\/code>, uko\u015bnik w %2F<\/code>, krzy\u017cyk w %23<\/code>, znak zapytania w %3F<\/code>. Has\u0142o Sommer@2026<\/code> pojawia si\u0119 wi\u0119c w adresie jako Sommer%402026<\/code> i pozostaje w kamerze niezmienione.<\/p>\n
Do drugiej strony tej sprawy nale\u017cy uwaga: wiele kamer uwierzytelnia si\u0119 przez RTSP digest, a nie przez Basic Auth. Has\u0142o nie w\u0119druje zatem przez sie\u0107 otwartym tekstem, cho\u0107 otwartym tekstem stoi w adresie. Otwartym tekstem w\u0119druje natomiast sam adres – w historii pow\u0142oki, w pliku Compose, w linii dziennika. Dane logowania do kamery nale\u017c\u0105 wi\u0119c do osobnego konta z samym prawem podgl\u0105du, nigdy do konta administratora.<\/p>\n
Sprawdzenie adresu, zanim gdziekolwiek trafi<\/h2>\n
Jedno polecenie odpowiada na jedyne pytanie, kt\u00f3re na tym etapie si\u0119 liczy. Otwiera strumie\u0144, czyta pierwsze pakiety, wypisuje znalezione dane i ko\u0144czy prac\u0119.<\/p>\n
ffprobe -hide_banner -rtsp_transport tcp \\\n  -i \"rtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/Streaming\/Channels\/102\"<\/code><\/pre>\n
Dzia\u0142aj\u0105cy adres w ci\u0105gu sekundy lub dw\u00f3ch wypisuje lini\u0119 strumienia z kodekiem, rozdzielczo\u015bci\u0105 i liczb\u0105 klatek. Wszystko inne jest diagnoz\u0105, a cztery cz\u0119ste odpowiedzi wskazuj\u0105 w cztery r\u00f3\u017cne strony.<\/p>\n\n\n\n\n\n\n\n\n
Odpowied\u017a<\/th>\nZnaczenie<\/th>\n<\/tr>\n<\/thead>\n
401 Unauthorized<\/td>\nHost i \u015bcie\u017cka s\u0105 poprawne, dane logowania nie – albo konto nie ma prawa do strumienia<\/td>\n<\/tr>\n
404 Not Found<\/td>\nDane logowania przyj\u0119te, \u015bcie\u017cka b\u0142\u0119dna – o jednego producenta albo jeden numer strumienia obok<\/td>\n<\/tr>\n
Connection refused<\/td>\nNa porcie 554 nic nie nas\u0142uchuje; RTSP wy\u0142\u0105czone w kamerze albo port przeniesiony<\/td>\n<\/tr>\n
Przekroczenie czasu po handshake<\/td>\nSesja stoi, pakiety wideo nie docieraj\u0105 – niemal zawsze zablokowany UDP<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Ostatnia z czterech t\u0142umaczy, dlaczego w poleceniu stoi -rtsp_transport tcp<\/code>. Domy\u015blnie kana\u0142 steruj\u0105cy biegnie przez TCP, a obraz przez UDP na osobnych portach. Przez granic\u0119 VLAN albo przez zapor\u0119 handshake dochodzi wi\u0119c do skutku, a obraz mimo to nigdy nie przychodzi. Wymuszony TCP kosztuje troch\u0119 op\u00f3\u017anienia i usuwa ca\u0142\u0105 klas\u0119 usterek.<\/p>\n
Kt\u00f3ry strumie\u0144 gdzie nale\u017cy<\/h2>\n
Gdy adres ju\u017c dzia\u0142a, podstrumie\u0144 okazuje si\u0119 po\u017cyteczniejsz\u0105 po\u0142ow\u0105. Zapis potrzebuje strumienia g\u0142\u00f3wnego, bo to ten materia\u0142 ogl\u0105da ubezpieczyciel albo s\u0105d. Analiza ruchu i wykrywanie obiekt\u00f3w potrzebuj\u0105 ma\u0142ych obraz\u00f3w i z nimi przyspieszaj\u0105: detektor karmiony klatkami 4K sp\u0119dza czas na ich pomniejszaniu.<\/p>\n
Frigate wyra\u017ca ten podzia\u0142 wprost, przypisuj\u0105c rol\u0119 ka\u017cdemu strumieniowi – ta sama my\u015bl dotyczy ka\u017cdego rejestratora przyjmuj\u0105cego dwa wej\u015bcia na kamer\u0119.<\/p>\n
cameras:\n  wjazd:\n    ffmpeg:\n      inputs:\n        - path: rtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/Streaming\/Channels\/102\n          input_args: preset-rtsp-restream\n          roles: [detect]\n        - path: rtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/Streaming\/Channels\/101\n          input_args: preset-rtsp-restream\n          roles: [record]<\/code><\/pre>\n
Dwa po\u0142\u0105czenia do jednej kamery bywaj\u0105 zarazem g\u00f3rn\u0105 granic\u0105. Tanie kamery dopuszczaj\u0105 cztery r\u00f3wnoczesne sesje RTSP, czasem tylko dwie, a pi\u0105ta pr\u00f3ba ko\u0144czy si\u0119 komunikatem niemaj\u0105cym nic wsp\u00f3lnego z adresem. Restreamer taki jak go2rtc rozwi\u0105zuje to, otwieraj\u0105c jedn\u0105 sesj\u0119 i rozdaj\u0105c kopie pozosta\u0142ym.<\/p>\n
Co i tak psuje si\u0119 p\u00f3\u017aniej<\/h2>\n
Adres, kt\u00f3ry raz zadzia\u0142a\u0142, potrafi przesta\u0107 dzia\u0142a\u0107, cho\u0107 nic si\u0119 w nim nie zmieni\u0142o. Trzy przyczyny obejmuj\u0105 niemal wszystko.<\/p>\n
Pierwsza to DHCP. Kamera adresowana wypo\u017cyczonym IP w\u0119druje po restarcie routera, a adres wskazuje na to, co przej\u0119\u0142o numer. Rezerwacja na serwerze DHCP albo sta\u0142y adres w samej kamerze ko\u0144czy to na trwa\u0142e.<\/p>\n
Druga to aktualizacja oprogramowania, kt\u00f3ra resetuje prze\u0142\u0105cznik RTSP albo konto podgl\u0105du. Oba warto sprawdzi\u0107 po aktualizacji w pierwszej kolejno\u015bci, bo objaw – najpierw Connection refused, potem 401 – wygl\u0105da na usterk\u0119 sieci.<\/p>\n
Trzecia to czas. Wiele kamer porzuca sesj\u0119 le\u017c\u0105c\u0105 bez informacji zwrotnej RTCP, a cz\u0119\u015b\u0107 rejestrator\u00f3w nigdy jej nie wysy\u0142a. Wygl\u0105da to tak: strumie\u0144 dzia\u0142a godzinami i znika w nocy, za ka\u017cdym razem o nieco innej porze. Restreamer z ponownym \u0142\u0105czeniem usuwa objaw, a odst\u0119p keepalive poni\u017cej progu czasowego kamery usuwa przyczyn\u0119.<\/p>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n