IP摄像机的质量参差不齐,根据我的经验,有些摄像机的行为不稳定。处理它们的RTSP流需要一定的容错能力。
Live555项目提供了一个相对容错的RTSP客户端实现openRTSP,用于通过CLI拉取RTSP音频/视频流: http://www.live555.com/openRTSP/
例如,要将摄像机的RTSP音频/视频保存为QuickTime格式的文件(也有AVI和MP4),每15分钟一个文件。
$ 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客户端并不能发现这些小毛病。所以我选择在Python中使用 “subprocesses "模块来编写一个控制器,以调用和监视每个openRTSP客户端实例的stdout,同时检查文件是否在继续增长。
这似乎是CCTV行业低端产品在标准上玩得过快过松的副产品,RTSP和ONVIF是最经常被滥用的两种。
幸运的是,您通常可以解决这些问题。除非你的IP摄像机和控制器都被设计成可以很好地一起使用,否则只使用ONVIF进行一次发现和设置管理。
我在一些运行Raspbian的Raspberry Pi B+上使用openRTSP。每个1280x1024的流大约占用CPU的8-10%的时间,我已经成功地在每个RPi上运行了多达8个摄像头,将文件写入NAS存储。另一个RPi用ffmpeg处理完成的文件,搜索运动并生成这些帧的索引PNG,以协助发现闯入。
有一个叫做ZoneMinder的开源工作,它可以完成后一部分的工作,但我无法让它与我的摄像机一起工作。ONVIF支持在ZM中是新的,而且是新生的,它似乎不能很好地与我的100美元以下的IP摄像机产生的不稳定的RTSP流相抗衡。