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:

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:

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.

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ć

omxplayer -o hdmi --live rtsp://admin:[email protected] --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:

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:

#!/bin/bash
pkill omxplayer.bin
omxplayer -o hdmi --live rtsp://admin:[email protected] --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

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

Możesz również polubić…

21 komentarzy

  1. SpeX pisze:

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

    • pm pisze:

      @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).

      • SpeX pisze:

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

      • Wojtek pisze:

        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.

    • Wojtek pisze:

      Tak, da się. Z drugiej strony tak jak napisałem, zrobiłem to brutalnie, po prostu tak było mi łatwiej.

  2. SpeX pisze:

    A co jak bym chciał mieć podzielony ekran na 4 i odbierać 4 różne sygnały video?

    • Wojtek pisze:

      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.

  3. K L pisze:

    Działa to bardzo ładnie. restart co 15 to dobry pomysł. ma ustawiona jedną kamerą i jest dobrze.\
    Teraz dodałem kolejne podzieliłem ekran i nie wiem jak uruchomić 4 instalacje omx playera naraz
    używając twojego sposobu z restartem co 15 minut.

  4. PL pisze:

    Niestety ale u mnie cos nie działa. Mam malinke 3 z najnowszym softem i obraz u mnie jest głównie w postaci pionowych kolorowych pasów. Co jakiś czas pojawi się obraz ale to na chwilę. Próba z kanałem dodatkowym powoduje, ze obraz pojawia się częściej niż pionowe pasy. Próbowałem rożne ustawienia strumienia na kamerze. Przy odtwarzaniu na komputerze przy użyciu VLC, poza małym opóźnieniem, odtwarzane jest prawie płynnie… Kamera Gemini – może soft w kamerze nie współgra z kodekiem w Malince…

    • Wojtek pisze:

      Możesz w VLC podejrzeć dane strumienia. W jakiej rozdzielczości próbujesz wyświetlić obraz? Zobacz też jak wygląda obciążenie procesora w rpi przy próbie odtwarzania. Może pomóc upgrade firmware kamerki, o ile jest taka możliwość

      • PL pisze:

        Używając omxplayer obciążenie procesora nie przekraczało 10%. Nie ma znaczenia rozdzielczość – ale wieksze problemy były przy rozdzielczością 1920×1080 ale przy D1 równiez były… Probuję sie dowiedziec czy jest nowszy soft do kamery ew sprobuję z inną kamerą.

  5. Pawel R pisze:

    Witam U mnie nic nie działa w VLC widok kamery jest ok ale OMCPLAYER niestety ciemno. Tzn pojawia sie proces i nic po za tym 🙁 Może ktos pomoże w temacie potrzebuje odpalić 4ry kamery, strumień z rejestratora BCS,

  6. Wojtek pisze:

    No ok, ale co masz w okienku, w którym wpisujesz komendę uruchomienia omxplayer? Jakie parametry obrazu? Możesz to podejrzeć łącząc się przez VNC do raspberry.

  7. Daro pisze:

    A próbował ktoś taki stream nagrywać na kartę mSD w Malinie lub podpięty szybki pendrive?
    Ewentualnie jak to zrobić poprzez omxplayer, do tej pory używam motionEye na raspaju.

  8. Lukasz pisze:

    Mamy problem z podzieleniem ekranu na 4 i uruchomieniem podglądu z 4 kamer.
    Stosujemy komendę:
    screen -dmS stream1 sh -c ‘omxplayer –live –refresh –video_queue 4 –fps 30
    –win “0 0 959 539” rtsp:……’
    screen -dmS stream2 sh -c ‘omxplayer –live –refresh –video_queue 4 –fps 30
    –win “960 540 1920 1080” rtsp…..’
    W tym układzie działa, pokazuje obraz z 2 kamer, jeden w lewym kwadracie, drugi w prawym dolnym.
    Jeżeli tylko jakaś linia podglądu najedzie na siebie (np dając podgląd kamery w 1 połówce ekranu z lewej i z prawej) to żaden obraz z żadnej kamery się nie wyświetla. Ktoś spotkał się z takim problemem?

  9. Marck pisze:

    A ja mam problem z innej strony. Robię podgląd kamer z rejestratora Dahua. Niestety domyślnie wyświetla mi obraz z kamery podpiętej do kanału 1. Ktoś wie jak wyświetlić podgląd z kanału 3? Gdy podaję pełen adres to jest rtsp://user:pass@ipaddress/cam/realpath?channel=3&subtype=0 program wywala się na plecy. A na VLC działa. Pomoże ktoś?

  10. Marcin pisze:

    Idzie odpalić omxplayer w trybie konsoli i streamować z kamery ip bezpośrednio do pliku?

  11. Michal pisze:

    Próbowałem zrobić wg. Twojego opisu z Raspberry Pi 4B 2G na kamerze IP Zintronic A5 5Mpix i problem polegał na tym, że omxplayer ani VLC player nie odtwarzały mi codec’a h265, zmieniłem na h264 highprofile i udało się uruchomić podgląd ale tylko 800×600 ( rtsp://IP/12 ) ( monitor miałem 1280×1024 ) niestety nie znalazłem w omxplayer opcji do wyświetlania w innej rozdzielczości dla wyższego stream ( rtsp://IP:554/11 ), jak wybierałem normalnie to wychodził i nie odtwarzał. Dodatkowo napisałem skrypt, który wykrywa czy proces działa i jak nie działa to go odpali, o ile faktycznie skończy się na ubitym procesie a nie zawieszonym.

  12. Daniel pisze:

    Dzien dobry,
    interesuje mnie nie podgląd w trubie rzeczywistym a nagranie materiału wideo a potem odtworzenie go w dowolnej chwili. Czy jest takie rozwiązanie? RP3 musiałoby miec dostęp do zasobu smb ( tu nie ma problemu) tylko jak kazać mu zapisać obraz z dzwiękiem – nawet bez dzwięku byłoby ok.
    pozdrawiam
    Daniel

Leave a Reply

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.