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, RSTP, 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:

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

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

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

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:

Advanced Options w raspi-config

Dalej wybieramy Memory Split:

Memory Split w raspi-config

I ustawiam 256MB na potrzeby przetwarzania grafiki:

Pamięć RAM dla GPU

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:

VLC Media Player RTSP

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

Autoryzacja w RTSP

Chwilka oczekiwania na obraz i…:

VLC RTSP RPi CPU 100%

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:

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

Stream pomocniczy RTSP VLC RPi

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ć

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:

Stream z omxplayer

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ęć.

Stream RTSP w omxplayer

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:

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:

Restartomx w crontab

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ć.

Wpis “Raspberry Pi jako player streamu z kamery IP” komentowano 7 razy

  1. Nie jestem ekspertem jeśli chodzi o linux’a, ale nie da się jakoś skryptem sprawdzać, czy jakiś program działa? I dopiero jeśli nie działa to go uruchomić?

    • @SpeX: Wykrywanie, czy program jest włączony jest proste.
      Wykrywanie, czy działa (np. czy się nie zawiesił, albo nie stracił połączenia z kamerą) jest trudne.

      Co do wyświetlania kilku kamer na raz (o ile sprzętowy układ dekodowania sobie poradzi z kilkoma strumieniami na raz), to trzeba by pewnie zmienić parametr „-aspect-mode fill” na coś innego, być może też pokombinować z menadżerem okien, żeby je odpowiednio ustawić względem siebie.

      @Wojtek: Jeżeli co jakiś czas program się wyłączał, to oprócz tego crona można by go umieścić w nieskończonej pętli „while”. Wtedy próbowałby się uruchomić ponownie natychmiast po zakończeniu zamiast po 0-15 minutach.

      Czy sprawdzałeś może opóźnienia? Używałem kiedyś tabletu z Androidem do wyświetlania obrazu z kamery i typowe były 4s opóźnienia, czasami nawet większe przy użyciu VLC, bo sobie buforowało obraz. Pomogło użycie tablet z Windows i programu producenta do podglądu kamer (opóźnienie spadło chyba do 1s, nie rosło i bardzo dobrze sobie radziło z chwilowymi problemami z siecią, w przeciwieństwie do VLC, gdzie trzeba było ręcznie wejść ponownie na stream).

      • @pm; Fakt, jest różnica w tym, iż program działa albo albo się zawiesił, ale cały czas jest uruchomiony.

      • Niezły pomysł z tą pętlą, w wolnej chwili popatrzę na to. Nie ma najmniejszego problemu z opóźnieniami. Nawet jak omxplayer nie był resetowany co 15 minut a chodził do czasu wysypania się. Problem był w programie klienckim iVMS-4200 na Windows, gdzie lag wynosił 2 minuty na dobę, ale zmiana ustawień z jakości na wydajność rozwiązała problem.

    • Przed chwilą sprawdziłem, da się, zamiast –aspect-mode stosujesz –win x1,y1,x2,y2 gdzie x1, y1 itd to współrzędne ekranu w pikselach. Np. cztery instancje omxplayer, każdy wyświetla okno w innej części ekranu.

Dodaj komentarz