IPカメラの品質はさまざまですが、私の経験では不規則に動作するものもあります。RTSPストリームを処理するには、フォールトトレランスが必要です。
Live555プロジェクトは、CLI経由でRTSPオーディオ/ビデオストリームをプルするための比較的フォールトトレラントなRTSPクライアント実装であるopenRTSPを提供します。http://www.live555.com/openRTSP/
たとえば、カメラのRTSPオーディオ/ビデオをQuickTime形式(AVIおよびMP4も使用可能)のファイルに保存するには、15分ごとに1つのファイルを保存します。
$ 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
これらのオプションの意味は次のとおりです。
-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
-tオプションを削除すると、openRTSPがデフォルトでUDPになります。これにより、ネットワークトラフィックを少し減らすことができます。自分に合った組み合わせを見つけるには、オプションを試す必要があります。
率直に言って、カメラ自体の信頼性が低い場合や、実装が異なる場合があります-ソケットを予期せず閉じることはそれほど珍しいことではありません。
openRTSPクライアントがこれらのグリッチをキャッチしない場合があります。そこで、「openprocess」モジュールを使用して各openRTSPクライアントインスタンスの標準出力を呼び出して監視し、ファイルのサイズが増え続けることを確認するために、Pythonでコントローラーをコーディングすることを選択しました。
これは、CCSP業界のローエンドが規格に迅速かつ緩い対応をしているため、RTSPとONVIFが最も頻繁に悪用されている副産物のようです。
幸いなことに、通常はこれらの問題を回避できます。IPカメラとコントローラーがすべて一緒にうまく動作するように設計されていない限り、ONVIFを使用するのは1回限りの検出と設定管理のみにしてください。
Raspbianを実行しているいくつかのRaspberry Pi B +でopenRTSPを使用しています。各1280x1024ストリームはCPU時間の約8〜10%を占有し、RPiごとに最大8台のカメラを正常に実行し、ファイルをNASストレージに書き込みました。別のRPiは、完了したファイルをffmpegで処理し、モーションを検索し、それらのフレームのインデックスPNGを生成して、侵入の発見を支援します。
この後の部分を行うZoneMinderと呼ばれるオープンソースの取り組みがありますが、カメラで動作させることができませんでした。ONVIFのサポートはZMで新しく生まれたばかりであり、$ 100未満のIPカメラのメナジェリーによって生成されたむらのあるRTSPストリームとはうまく競合していないようです。