RTSP, HTTP-FLV, ONVIF, H.264/H.265, audio i limity połączeń

RTSP, ONVIF, kodek i substream często są wrzucane do jednego worka. W tej lekcji porządkujemy te pojęcia, bo późniejszy Frigate zależy od poprawnego źródła i rozsądnej liczby połączeń.

W rozmowach o kamerach bardzo łatwo pomieszać słowa „stream”, „RTSP”, „H.265” i „ONVIF”, a potem próbować naprawiać niewłaściwą warstwę. Dla początkującego wystarczy prosty model. Stream to konkretny wariant obrazu, na przykład wysokiej jakości Clear albo lekki Fluent. Kodek to sposób kompresji obrazu, na przykład H.264 albo H.265. Protokół transmisji to sposób, którym program pobiera obraz z kamery, na przykład RTSP albo HTTP-FLV. ONVIF jest standardem komunikacji między urządzeniami monitoringu i może przenosić informacje o profilach, zdarzeniach czy sterowaniu PTZ. To rozróżnienie ma bardzo praktyczny skutek. Jeżeli VLC łączy się z RTSP, ale nie pokazuje 4K, problemem może być dekoder H.265. Jeśli RTSP nie łączy się w ogóle, kodek nie jest jeszcze pierwszym podejrzanym. Jeżeli Home Assistant widzi person detection, ale karta live nie pokazuje Clear, zdarzenia i wideo mogą korzystać z różnych mechanizmów. Dzięki temu nie będziemy już traktowali każdego problemu jako „kamera nie działa”.

HTTP-FLV to alternatywny transport obrazu. Frigate ma osobne zalecenia dla Reolink, ponieważ w praktyce streamy HTTP bywają stabilniejsze w części generacji kamer. Dla 5 MP i niżej aktualna dokumentacja rekomenduje http-flv . Dla nowszych 6 MP+ takich jak Duo 3 opisuje nowy wariant HTTP-FLV enhanced przy FFmpeg 8.0 albo RTSP. Tu pojawia się ważny niuans. Ogólna dokumentacja Reolink mówi, że klasyczny FLV obsługuje H.264 i dlatego typowy 8 MP main H.265 nie zadziała w klasycznym FLV. Frigate z kolei opisuje nowszy enhanced wariant dla wybranych nowych H.265. To nie sprzeczność, tylko różne generacje rozwiązania. Dlatego C01 i Duo 3 nie dostaną identycznej konfiguracji.

D340P ma 5 MP i H.264, dlatego dla samego wideo dobrze wpisuje się w rekomendację HTTP-FLV. Jednocześnie Doorbell to urządzenie, w którym two-way audio jest funkcją pierwszoplanową. Nie wystarczy więc znaleźć jeden pasywny stream i uznać temat za zamknięty. Aktualny Frigate dla nowych Reolinków z two-way audio pokazuje model, w którym HTTP-FLV pozostaje stabilnym źródłem obrazu, a dodatkowy RTSP jest przekazywany bezpośrednio do go2rtc do obsługi rozmowy. Dokumentacja podkreśla, że tego RTSP nie należy wówczas prefiksować przez ffmpeg: , bo go2rtc musi obsłużyć go samodzielnie.

Oficjalna diagnostyka Reolink dla RTSP/ONVIF/RTMP prowadzi bardzo podobną ścieżką: IP, port i konto; dostępność w LAN; włączone usługi; aktualny firmware; zgodny kodek; a potem porównanie z VLC. To jest dokładnie kolejność, której będziemy się trzymać.

Mamy luksus wynikający z topologii SG2218P: możemy testować oba tory. Bezpośredni RTSP z 192.168.1.101 mówi nam, czy działa kamera. RTSP z 192.168.1.20 i odpowiednim kanałem mówi nam, czy NVR potrafi udostępnić to, co sam odbiera. To dwie różne diagnozy. Jeżeli bezpośredni C01 działa, ale ten sam kanał przez NVR nie, problem jest po stronie rejestratora, jego kanału albo ograniczeń konkretnej rewizji. Jeżeli przez NVR działa, a bezpośrednio nie, sprawdzamy usługi Server Settings kamery. Jeśli oba nie działają, ale lokalny Live View Reolink działa, wracamy do portów, firmware i kodeka.

W następnej lekcji dodamy C01-C05 do oficjalnej integracji Reolink w Home Assistant . Nie będzie to tylko „Add Integration i kliknij Submit”. Zrobimy konto z właściwymi uprawnieniami, autodiscovery i konfigurację ręczną, sprawdzimy Fluent/Clear, person/vehicle/animal, Visitor Doorbell, spotlight, siren, record audio, TrackMix PTZ, presety i Guard return. Wykorzystamy też wiedzę z L9 do diagnozy unavailable. Jeżeli HA zacznie gubić kamerę po otwarciu kilku podglądów, nie będziemy przypadkowo restartować routera. Będziemy wiedzieli, że kamera ma skończoną liczbę sesji, a Fluent/FLV i późniejszy restream mogą być prawdziwym rozwiązaniem.

• Cztery pojęcia, które trzeba od siebie oddzielić
• Clear/Main i Fluent/Sub: dwa streamy, dwa zadania
• H.264 i H.265: kodek to nie rozdzielczość
• Mapa całego zestawu zanim zaczniemy testy
• Włączamy lokalne usługi potrzebne integracjom
• RTSP: podstawowy niezależny test źródła
• Hasło w URL to największa pułapka podczas publikowania konfiguracji
• HTTP-FLV: dlaczego Frigate tak często poleca go dla Reolink
• ONVIF nie jest drugim kodekiem
• RTMP zostawiamy aktywny, choć Frigate nie będzie na nim oparty
• Audio: AAC w streamie i G.711 dla rozmowy zwrotnej
• C01 RLC-810A: starsze 8 MP, dlatego RTSP pozostaje punktem bazowym
• C02 CX410: H.264 i niski ciężar, więc FLV pasuje do niej bardzo dobrze
• C03 Duo 3 PoE: 16 MP i 32:9 wymagają osobnego podejścia
• C04 Doorbell: obraz jest prosty, rozmowa dwukierunkowa już nie
• C05 TrackMix: wide view i tracking lens to dwa różne obrazy jednego urządzenia

Nie przeskakujemy od gotowego efektu do kopiowania konfiguracji. Zaczynamy od Cztery pojęcia, które trzeba od siebie oddzielić, następnie porządkujemy Clear/Main i Fluent/Sub: dwa streamy, dwa zadania i dopiero później przechodzimy do H.264 i H.265: kodek to nie rozdzielczość. Każdy etap ma własny test i jasny warunek PASS.

Pełna lekcja łączy wykonanie z diagnostyką. Wracamy do takich punktów jak Mapa całego zestawu zanim zaczniemy testy oraz Włączamy lokalne usługi potrzebne integracjom. Jeśli wynik zależy od konkretnej kamery, firmware, kadru, sieci albo warunków na posesji, dostajesz procedurę sprawdzenia zamiast jednej liczby do skopiowania.

Na końcu etap musi dać się zweryfikować. Jeśli obraz, stream, detekcja albo integracja zachowuje się inaczej niż opisano, zatrzymujemy się i diagnozujemy najniższą warstwę, która nie przeszła testu. Dzięki temu kolejna lekcja nie dokłada nowych zależności do systemu, który działa tylko przypadkiem.

Procedura, którą stosujemy do każdej nowej kamery także w przyszłości. Choć L9 dotyczy pięciu konkretnych Reolinków, wypracowujemy tu procedurę, którą można zastosować również za rok, gdy dołożysz szóstą kamerę innej generacji. Nie zaczynamy od znalezienia gotowego YAML. Zaczynamy od urządzenia jako źródła. Najpierw nadajemy stabilny adres przez DHCP reservation i aktualizujemy firmware dla dokładnej rewizji. Potem zapisujemy main/sub, rozdzielczość, FPS, bitrate i kodek. Włączamy tylko potrzebne usługi lokalne. Testujemy RTSP niezależnym klientem. Sprawdzamy HTTP-FLV, jeśli dokumentacja danej generacji go rekomenduje. Weryfikujemy audio. Dopiero potem patrzymy na limity sesji i decydujemy, które połączenie będzie bezpośrednie, a które przejdzie przez restream.

Masz mapę streamów C01-C05 i rozumiesz, kiedy używamy RTSP, HTTP-FLV, ONVIF, H.264/H.265 oraz jak ograniczać liczbę połączeń dzięki go2rtc.

Ta lekcja jest częścią kursu Smart Home od Zera na platformie MarkLabs E-Learning. Pełna wersja prowadzi przez konfigurację, testy, diagnostykę i przypadki awaryjne bez zostawiania Cię z poleceniem „skonfiguruj to sam”.