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中编写一个控制器,以调用和监视每个openRTSP客户端实例的标准输出,并检查文件的大小是否继续增长。
这似乎是闭路电视行业低端市场迅速而宽松地采用标准的副产品,RTSP和ONVIF是最常被滥用的两个标准。
幸运的是,您通常可以解决这些问题。除非您的IP摄像机和控制器都设计为可以很好地配合使用,否则请仅使用ONVIF进行仅一次的发现和设置管理。
我在一些运行Raspbian的Raspberry Pi B +上使用openRTSP。每个1280x1024的流占用CPU时间的8-10%,并且我已经成功地为每个RPi运行多达八台摄像机,并将文件写入NAS存储。另一个RPi使用ffmpeg处理完成的文件,搜索运动并生成这些帧的索引PNG,以帮助发现入侵。
后一部分要做一个名为ZoneMinder的开源工作,但是我无法在我的相机上使用它。ZM中对ONVIF的支持是新的和新生的,而且与我的不足100美元的IP摄像机的管理者所产生的RTSP流似乎并不完美。