When LiveNVR build a free plug-in program broadcast, common protocol uses industry-standard RTSP / Onvif access camera IPC camera / NVR DVR equipment; Onvif is found and the camera control management protocol, Onvif also use streaming protocols RTSP, the camera NVR access the streaming media, it is the direct access unified RTSP protocol;
In the RTSP protocol, since each manufacturer has a different processing methods, such as: Kang, UOB male step, depending on the buildings, and other manufacturers Albert world RTSP address rules differ.
RTSP configuration rules
Dahua products rtsp: // username: password @ ip :? Port / cam / realmonitor channel = 1 & subtype = 0
- username: Username
- password: password
- ip: IP for the device
- port: The default port number is 554, not fill the default 554
- channel: channel number, starting at 1. E.g. 2 channels, for the channel = 2
- subtype: Stream Type, the main stream (subtype = 0), the secondary stream (subtype = 1)
示例： rtsp://admin:[email protected]:554/camera/monitor?channel=1&subtype=1
Kang - Preview taken Stream - Older rule (until 2012 only support legacy equipment rules) rtsp: // <username>: <password> @ <ipaddress>: <Port> / <VideoType> / CH <the above mentioned id> / < streamtype> / av_stream
- username: Username
- password: password
- ipaddress: IP equipment
- port: The default port number is 554, the default not fill
- videotype: video encoding format, such as: h264, mpeg4
- ch: channel number, starting at 1. For example channel 1, for the ch1
- streamtype: Stream Type, the main stream (main), a secondary stream (Sub)
示例： rtsp://admin:[email protected]:554/h264/ch1/main/av_stream
示例： rtsp://admin:[email protected]:554/mpeg4/ch2/sub/av_stream
Kang - Preview taken Stream - The new rules rtsp: // <username>: < password> @ <ipaddress>: <port> / Streaming / Channels / <id> (parm1 = value1 & parm2 = value2?)
- username: Username
- password: password
- ipaddress: IP equipment
- port: The default port number is 554, the default not fill
- id: Channel number +0+ Stream Type Stream Type: l- main stream, sub stream 2-, 3- third stream; as 1202 represents a first sub-stream passage 12
- Other parameters such as the parms transportmode = unicast (Unicast default) transportmode = multicast (multicast)
示例：rtsp://admin:[email protected]:554/Streaming/Channels/101
Kang - taken playback stream rtsp: // <username>: < password> @ <ipaddress>: <port> / Streaming / tracks / <id> (parm1 = value1 & parm2 = value2?)
- username: Username
- password: password
- ipaddress: IP equipment
- port: The default port number is 554, the default not fill
- id: Channel number +0+ Stream Type Stream Type: l- main stream, sub stream 2-, 3- third stream; as 1202 represents a first sub-stream passage 12
- parms other parameters into such starttime = 20131013t093812z & endtime = 20131013t104816z; specific format YYYYMMDD "T" HHmmSS.fraction "Z", Y is In, M is the month, D is day, T is the time ruled breaks, H is hour, M is minutes, S is the second, Z is optional, represents Zulu (GMT) time
示例：rtsp://admin:[email protected]:554/Streaming/tracks/101?starttime=20180902t123812z&endtime=20180902t124816z
OPTIONS question sent
RTSP access aspects, and live555 FFmpeg, compatibility is the strongest market two components, the length of each, live555 complex structure, huge overall FFmpeg; live555 camera as RTSP to access the program, it can be very easy to implement some of the features custom, will encounter problems OPTIONS sent:
When using RTP over UDP / TCP mode during take stream, RTSPClient (live555) may take a long time in the flow from the RTSPServer (IPC / NVR), but there is no missing packet to send keep-alive RTSPServer, if the server started Session keepalive detection mechanism (see the RTSPServer live555 implemented in noteliveness), the server does not receive a long packets sent by the client, the client connection will be considered false connector terminating a connection with the client (client matter whether the flow is taken);
In order to solve the above problems, the majority of clients will RTSPClient timed (eg 30s) to send OPTIONS RTSPServer (some may also be transmitted is GET_PARAMETER) command, similar to the keep-alive packets, so the server can send live normally the data stream;
Not all RTSPServer are doing so well, like on some of Kang IPC / NVR models, when RTSPClient in the process of drawing stream, suddenly sending OPTIONS keep-alive packet is sent as a junk data, the RTSPServer whole RTSP connection will be automatically disconnected, resulting in RTP stream is also taken as a stop, we can in such devices, OPTIONS choose to not send keep-alive packets;
LiveNVR security RTSP free plug-in program broadcast
LiveNVR solve the above problems, an Internet-based traditional security solutions:
- Support PC side / Android Andrews end / iOS Apple client / micro-channel end of the free plug-in to watch;
- Support micro-channel two-dimensional code scanning to watch;
- Based on web pages / no plug-in player;
- Support Kang / UOB and other market access almost all of the network camera;
- Real-time IP Camera / NVR live images in real-time live monitoring;
- Support video and video look back;
- Compatible with windows and linux dual system;
- Private cloud deployments build their own business scenarios;
For more information
Live Streaming Internet Security -QQ exchange group: 615 081 503
GB GB28181 no plug-ins LiveGBS-QQ exchange group: 947 137 753
WEB：www.liveqing.com
Tel: 189-5515-0114 (the same micro-channel)
Copyright © LiveQing.com 2016-2019