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.