-
Notifications
You must be signed in to change notification settings - Fork 146
Cameras: Geovision
RTSP urls:
- main stream:
rtsp://camera.ip.address.here/media/video1 - sub stream:
rtsp://camera.ip.address.here/media/video2 - ext stream:
rtsp://camera.ip.address.here/media/video3
In early tests, this looks like a good camera to use with Moonfire NVR:
- No parts from manufacturers who support the Uyghur genocide and/or are banned from US government contracts under the NDAA.
- Reasonable price.
- Decent (although imperfect) RTSP support.
- Configurable video streams. Eg, a full-resolution/high-fps main stream, a 720P/5fps stream for on-NVR analytics, and a 640x360/10fps stream for live view over low-bandwidth connections.
- Supports audio, although only with the G.711 codec. Moonfire NVR has no audio support yet (see #33). Support for this camera is likely to come after others because we'll have to add support to Moonfire NVR to transcoding on-NVR to AAC. However, it should be possible, and I believe AAC encoding is fairly inexpensive.
- Untested: claims to have on-camera analytics for intrusion and human body detection.
As of firmware V1.02_2021_04_08.
Audio/UI oddity: the camera ships with audio disabled, although its ONVIF GetProfiles response says otherwise. You must enable audio in the web UI. Unfortunately when using a modern web browser, the audio settings are hidden. You'll have to log in with an old version of Internet Explorer and GeoVision's plugin. Once you enable audio in the UI, the camera will send G.711 audio over RTSP.
SDP compliance: scottlamb/retina#33: RFC 8866 section 9 mandates that the session description include at least one t= line. The SDP in this camera's DESCRIBE response doesn't. It skip directly from "c=" to "a=", which is not allowed. With Moonfire NVR 0.6.4, use --rtsp-library=ffmpeg to work around this bug. This won't be necessary with the next Moonfire NVR release.
RTP compliance: after the final H.264 RTP packet of each IDR frame, the camera sends another RTP packet with the same sequence number, payload type 50 (invalid/unassigned), and data I don't know how to interpret. RFC 3550 section 5.1 mandates that the sequence number increase with each packet. The next version of Moonfire NVR will work around this problem by explicitly discarding packets with payload type 50 prior to checking sequence numbers.
RTSP compliance: when using RTP/AVP/TCP, after a client's TCP window has been filled for several seconds and then empties, the camera sends invalid data. (This scenario might happen due to an unreliable network link or due to slow processing on either side of the connection.) By invalid data, I mean binary data that is not a valid message according to RFC 2326. It may be part of a section 10.12 interleaved data message, notably without the important "$" prefix. Perhaps the camera discards part of a message when its socket buffer fills or on some kind of send timeout, then continues.
RTSP compliance: the camera omits the (mandatory) RTP-Info: header from its PLAY response. This header is used to match the streams to the NPT ("normal play time") timeline. Audio/video sync may be off by up to 1 audio packet as a result. Audio packets appear to come every 32 ms (8 kHz audio, 256 samples per packet), so this is likely to be too minor to notice.