Przechwyć strumień RTSP z kamery IP i zapisz

Mam kilka kamer IP, które wysyłają strumień RTSP (h264 mpeg4).

Lokalne trafianie w adres URL za pomocą VLC: rtsp: //192.168.0.21: 554 / mpeg4

Mogę przesyłać strumieniowo kamerę i zrzut na dysk (na pulpicie). Chciałbym jednak przechowywać te pliki na moim serwerze NAS (FreeNAS). Patrzyłem na sposoby przechwytywania strumienia RTSP i zrzucania ich na dysk, ale nie mogę nic znaleźć.

Czy można przechwycić strumień w systemie FreeBSD lub Linux (RaspberryPi) i zrzucić przesyłaną zawartość na dysk lokalny w systemie Linux lub FreeBSD - najlepiej co 30 minut?

EDYCJA: NAS jest bezgłowy (HP N55L lub coś takiego), a RaspberryPi też są bezgłowe.

Zajrzałem już do ZoneMinder, ale potrzebuję czegoś małego. Miałem nadzieję, że wykorzystam Motion do wykrycia ruchu w strumieniu, ale przyjdzie to później.

Kamery IP mają różną jakość, niektóre z mnie zachowują się nieregularnie. Radzenie sobie z ich strumieniami RTSP wymaga dawki odporności na uszkodzenia.

Projekt Live555 zapewnia stosunkowo odporną na błędy implementację klienta RTSP, openRTSP, do pobierania strumieni audio / wideo RTSP przez CLI: http://www.live555.com/openRTSP/

Na przykład, aby zapisać audio / wideo RTSP kamery w plikach w formacie QuickTime (dostępne również AVI i MP4), jeden plik co 15 minut:

$ openRTSP -D 1 -c -B 10000000 -b 10000000 -q -Q -F cam_eight -d 28800 -P 900 -t -u admin 123456 rtsp://192.168.1.108:554/11

Te opcje oznaczają:

-D 1 # Quit if no packets for 1 second or more
-c   # Continuously record, after completion of -d timeframe
-B 10000000 # Input buffer of 10 MB
-b 10000000 # Output buffer 10MB (to file)
-q   # Produce files in QuickTime format
-Q   # Display QOS statistics 
-F cam_eight  # Prefix output filenames with this text
-d 28800      # Run openRTSP this many seconds
-P 900        # Start a new output file every -P seconds
-t            # Request camera end stream over TCP, not UDP
-u admin 123456  # Username and password expected by camera
rtsp://192.168.1.108:554/11  # Camera's RTSP URL

Usunięcie opcji -t powoduje, że zamiast tego openRTSP przyjmuje domyślnie UDP, co może nieco zmniejszyć ruch w sieci. Będziesz musiał grać z opcjami, aby znaleźć kombinację, która Ci odpowiada.

Szczerze mówiąc, same kamery są czasami zawodne lub po prostu wdrażane inaczej - nieoczekiwane zamknięcie gniazda nie jest wcale takie niezwykłe.

Czasami klient openRTSP nie wychwytuje tych usterek. Zdecydowałem się więc na kodowanie kontrolera w Pythonie za pomocą modułu „podprocesów”, aby wywoływać i monitorować standardowe wyjście każdej instancji klienta openRTSP, a także sprawdzać, czy rozmiar plików nadal rośnie.

Wydaje się, że jest to produkt uboczny niskiej jakości przemysłu telewizji przemysłowej, który gra szybko i luźno ze standardami, przy czym RTSP i ONVIF to dwa najczęściej nadużywane.

Na szczęście zazwyczaj można obejść te problemy. O ile wszystkie kamery IP i kontroler nie są zaprojektowane tak, aby dobrze ze sobą współgrać, używaj ONVIF tylko do jednorazowego wykrywania i zarządzania ustawieniami.

Używam openRTSP na kilku Raspberry Pi B + z uruchomionym Raspbian. Każdy strumień 1280x1024 zajmuje około 8-10% czasu procesora, a udało mi się uruchomić do ośmiu kamer na RPi, zapisując pliki w pamięci NAS. Kolejne RPi przetwarza ukończone pliki za pomocą ffmpeg, szukając ruchu i generując indeksowe PNG tych ramek, aby pomóc w wykrywaniu włamań.

Ta ostatnia część ma otwarty program o nazwie SourceMinder, ale nie udało mi się uruchomić go z moimi aparatami. Obsługa ONVIF jest nowa i rodzi się w ZM, i wydaje się, że nie konkuruje dobrze z nierównymi strumieniami RTSP produkowanymi przez moją menażerię kamer IP poniżej 100 USD.

Pomyślałem, że dodam dwa centy i uzupełnię odpowiedź BjornR.

Zamiast uruchamiać zadanie cron, aby okresowo zabijać proces VLC, można powiedzieć VLC, aby działał przez określony czas, a następnie zamknął się.

Oto polecenie, które uruchamiam na moim urządzeniu:

/usr/bin/vlc -vvv rtsp://192.168.1.128:1554/11 --sout=file/ts:/media/path/to/save/location/recording-$(date +"%Y%m%d%H%M%S").ts -I dummy --stop-time=480 vlc://quit

To uruchamia VLC przez określony czas, a następnie kończy pracę. Parametr vlc: // quit jest wymagany, ponieważ VLC zatrzyma nagrywanie i pozostanie otwarty. To polecenie musi być umieszczone w pętli.

Jedynym problemem, jaki do tej pory znalazłem, jest to, że za każdym razem, gdy rozpoczyna się nowe nagranie, może minąć kilka sekund.

Jeśli poprawnie wykonam twoje pytanie, dlaczego nie wypróbujesz następującego polecenia w systemie Linux (RPi):

ffmpeg -i rtsp://192.168.0.21:554/mpeg4 -vcodec copy -acodec copy -map 0 -f segment -segment_time 300 -segment_format mp4 "ffmpeg_capture-%03d.mp4"

To powinno zapisać wideo w kawałkach po 300 sekund. (Pamiętaj, że długość klipu będzie zależeć od liczby klatek na sekundę na wejściu i wyjściu)

VLC wygląda na idealnego kandydata do przetworzenia Twojego strumienia. Podstawowe metody przechwytywania strumienia opisano na stronie internetowej Videolan. Z powodzeniem nagrałem dane wyjściowe mojej kamery sieciowej D-Link DCS-5222 za pomocą następującego polecenia:

vlc rtsp://user:password@ip/play1.sdp --sout=file/ogg:mystream.ogv

W twoim przypadku może to działać lokalnie, aby zapisać dane wyjściowe:

vlc rtsp://192.168.0.21:554/mpeg4 --sout=file/ts:mystream.mpg

Sugeruję uruchomienie skryptu, który kończy ten proces VLC i uruchamianie nowej instancji co 30 minut, ponieważ nie jestem pewien, czy VLC jest w stanie to zrobić.

Jeśli chodzi o przechowywanie na serwerze NAS, wystarczy zamontować go w lokalnym systemie plików.