Raspberry Pi jako player streamu z kamery IP

W dzisiejszym wpisie przedstawię tani sposób na wyświetlanie obrazu z kamery IP. Tani, bo potrzebne będą, prócz kamery, Raspberry Pi i monitor lub telewizor. Rozwiązanie powstało z konieczności. W istniejącym systemie monitoringu obraz z kamer IP nagrywany jest na dyski rejestratora, a podgląd zrealizowano na komputerze PC z odpowiednim oprogramowaniem. Jednak w innych miejscach pojawiła się konieczność podglądu co dzieje się przy drzwiach wejściowych czy bramie.

Monitoring na kamerach IP z zasilaniem PoE

Wspomniane wcześniej kamery IP, zarówno wewnętrzne jak i zewnętrzne to produkty dość znanej, chińskiej firmy HikVision. Przez 3 lata użytkowania (praca non stop), zarówno kamery jak i rejestrator były praktycznie bezobsługowe (3 czy 4 przypadki zaniku obrazu z losowej kamery, “naprawione” restartem przez odłączone/podłączenie zasilania), co jest chyba dobrą rekomendacją. Prawie 20 kamer jest zasilanych w standardzie PoE wprost ze switcha, co znakomicie uprościło całą instalację, która sprowadza się do dobrej jakości skrętki poprowadzonej do każdej z kamer. Całość, ze względów bezpieczeństwa, pracuje w odrębnej sieci lan, odseparowanej od pozostałych komputerów i internetu. W jednym z pomieszczeń, znajduje się komputer z oprogramowaniem klienckim, który łączy się do rejestratora i wyświetla obraz z kamer, w praktycznie dowolnej konfiguracji. Po czasie okazało się, że obraz z wybranych kamer przydałby się też w innych pomieszczeniach. Do wyświetlania miały zostać użyte typowe monitory PC, a player miał być tani, niewielkich rozmiarów, pobierający mało energii. Od razu do głowy przyszły mi płytki typu Banana Pi czy Raspberry Pi. Akurat ta druga była pod ręką, a opis konfiguracji znajduje się poniżej.

HikVision, RTSP, H.264 i Raspberry Pi

Jeśli chodzi o temat odtwarzania multimediów, w tym tych egzotycznych, to niezależnie od platformy do głowy przychodzi mi multimedialny kombajn VLC. Zrobiłem pierwsze próby z podłączeniem kamery do komputera PC i odtwarzanie strumienia video za pomocą tego programu – poszło bez problemu. Kamery IP korzystają z protokołu RTSP (Real Time Streaming Protocol) do przesyłania obrazu. Link do strumienia najczęściej wygląda tak:

rtsp://adresp_ip_kamery:port/kanał_video

Konkretny przykład dla posiadanej przeze mnie kamery HikVision, transmitującej strumień w jakości Full HD wygląda tak:

rtsp://adres_ip:554/Streaming/channels/101

Jest też kanał pomocniczy, gdzie transmitowany obraz ma mniejszą rozdzielczość:

rtsp://adres_ip:554/Streaming/channels/102

Strumień może być zabezpieczony loginem i hasłem, który również może być podany z adresie strumienia:

rtsp://login:hasło@adres_ip_kamery:port/kanał_video

W przypadku HikVision, jeśli podamy tylko adres IP (rtsp://adres_ip), kamera wystawi domyślny, główny strumień video.

Wszystkie konkretne informacje dla danego sprzętu można oczywiście znaleźć w jego instrukcji obsługi.

Przygotowałem kartę microSD z ostatnią wersją Raspbiana z interfejsem graficznym, wsadziłem ją do Raspberry Pi 3, system jeszcze zaktualizowałem o najnowsze pakiety i zainstalowałem VLC. Uruchomiłem jeszcze raspi-config, by zwiększyć pamięć video do 256MB, czyli wchodzę w Advanced Options:

Dalej wybieramy Memory Split:

I ustawiam 256MB na potrzeby przetwarzania grafiki:

Pierwsza próba z testową kamerą, której adres IP to 192.0.0.19, fabryczny login admin i hasło 12345. W VLC media player wybieram skrótem CTRL+N okno z parametrami strumienia w sieci:

Jest nieźle, bo pojawia się okienko z prośbą o wpisanie poświadczeń, czyli połączenie zostało nawiązane:

Chwilka oczekiwania na obraz i…:

Porażka, rpi 3, mimo 4 rdzeniowego procesora, nie jest w stanie poprawnie zdekodować strumienia, CPU cały czas jest obciążony w 98-100%. Druga próba ze strumieniem pomocniczym:

rtsp://192.0.0.19/Streaming/Channels/102

I znowu prośba o login i hasło, tym razem obraz jest, ale klatkujący, CPU obciążone pod korek.

Nawet RPi 1 poprawnie dekodowało i odtwarzało strumień w Full HD choćby z youtube, więc nie jest to problem wydajności a raczej programowy, kodeków. Czas więc poszukać innego rozwiązania niż VLC media player.

Na problemy omxplayer

Szukając odtwarzacza strumienia z kamery, natrafiłem na omxplayer. Najciemniej pod latarnią, bo pakiet znajduje się standardowo w Raspbianie, a nawet powstał specjalnie z myślą o Raspberry Pi. Player pracuje w trybie tekstowym, wszystko co jest niezbędne, podaje się jako parametry przy uruchamianiu. Chcąc wyświetlić strumień z wyżej wymienionej kamery, w terminala trzeba wspisać

omxplayer -o hdmi --live rtsp://admin:12345@192.0.0.19 --aspect-mode fill

I teraz po kolei:

• -o hdmi – można zastąpić przez –adev – tu wskazujemy gdzie ma zostać skierowany strumień audio (o ile jest potrzebny), tutaj jest to port HDMI;
• –live – informujemy omxplayer, że będzie miał do czynienia ze strumieniem video odtwarzanym “na żywo”, dalej podajemy adres;
• –aspect-mode – tu podajemy jak obraz ma zostać wpasowany w ekran, do wyboru domyślne letterbox, fill, stretch.

Więcej o omxplayer i jego możliwościach można poczytać na stronach oficjalnej dokumentacji Raspberry Pi.

W adresie strumienia rtsp podajemy już dane autoryzacyjne, więc program od razu nawiązuje połączenie, wyświetla parametry strumienia:

I zaraz cały ekran zostanie wypełniony obrazem z kamery, nadawanym w Full HD, z prędkością ponad 70 klatek na sekundę, odtwarzanym płynnie, bez najmniejszych zacięć.

Jeśli chodzi o obciążenie procesora, to wynosi ono około… 2-3%, czyli super.

Po kilku dniach używania okazało się, że czasem, w sumie nie wiadomo z jakiego powodu, omxplayer przestaje wyświetlać obraz, znika okno ze streamem, w konsoli pojawia się komunikat o zakończeniu pracy programu. Wystarczy wtedy jeszcze raz uruchomić odtwarzacz i wszystko działa jak należy, do czasu kolejnej przerwy. Załatwiłem to prostym skryptem, który jest odpalany co 15 minut przez crona. Jego zawartość to:

#!/bin/bash
pkill omxplayer.bin
omxplayer -o hdmi --live rtsp://admin:12345@192.0.0.19 --aspect-mode fill

Nie ma tu żadnej filozofii, a tylko brutalne działanie. Na początek zabijany jest proces omxplayera i zaraz uruchamiany na nowo. Plik zapisałem pod nazwą restartomx.sh i nadałem mu prawo wykonywania (chmod +x). Następnie odpaliłem crontab -e i dopisałem uruchamianie skryptu co 15 minut:

0,15,30,45 * * * * /home/pi/restartomx.sh

Czyli co 15 minut omxplayer jest zabijany i uruchamiany na nowo. Objawia się to 2-3 sekundowym czarnym obrazem. Nawet jeśli omxplayer się rozsypie i przestanie odtwarzać strumień, czy raspberry pi zostanie zrestartowane, to w ciągu maksymalnie 15 minut wszystko wróci do normy. Rozwiązanie okazało się na tyle skuteczne, że tak skonfigurowane Raspberry Pi 2 odtwarzało sygnał z kamery “bez dotykania” przez ponad 2 lata.

Podsumowanie

Opisany wyżej sposób, oprócz pożytecznego wyświetlania obrazu z kamery, może też znaleźć szereg innych zastosowań. Obraz może być wyświetlany na dedykowanym do RPi, małym ekranie LCD. Nic nie stoi na przeszkodzie, by omxplayer odtwarzał w sposób ciągły jakieś filmy, czy nawet reklamy na telewizorach czy monitorach. Plusem są niewielkie wymiary płytki, którą można zamontować choćby za telewizorem, małe potrzeby w zakresie poboru prądu, często sprawdzi się zasilanie z gniazda USB, w które wyposażone są praktycznie wszystkie nowsze telewizory. Warto tylko zadbać o zastosowanie markowej karty SD, bo niestety wszystkie tanie wynalazki, nie dość że są wolne, to jeszcze padają po kilku miesiącach. Powyższe rozwiązanie z powodzeniem działa na RPi 2 i 3, myślę że na RPi 1 też powinno się sprawdzić.