IP 카메라는 품질이 다양하며 일부는 제 경험에서 잘못 작동합니다. RTSP 스트림을 처리하려면 약간의 내결함성이 필요합니다.
Live555 프로젝트는 CLI를 통해 RTSP 오디오 / 비디오 스트림을 가져 오기 위해 비교적 내결함성 RTSP 클라이언트 구현 인 openRTSP를 제공합니다. 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 클라이언트가 이러한 결함을 포착하지 못합니다. 그래서 'subprocesses'모듈을 사용하여 Python에서 컨트롤러를 코딩하여 각 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 스트림과 잘 맞지 않는 것 같습니다.