GB/T28181
The full name of the national standard GB/T28181 protocol, technical requirements for information transmission, exchange and control of security video surveillance networking system, is a white paper defining the standards for video networking transmission and equipment control. It is proposed by the science and Technology Information Bureau of the Ministry of public security. The standard specifies the interconnection structure, communication protocol structure, transmission Basic and security requirements for switching and control, as well as technical requirements for control, transmission process and protocol interface. It solves the problems of video interconnection, data sharing and equipment control. This problem solves the problem of video information fighting on its own from the top, and opens up the information island of video networking.
Advantages: compared with RTMP, GB28181 supports TCP and UDP modes. Signaling flow is responsible for session interaction and data flow is responsible for data transmission. It is suitable for platform level product docking of standard protocol specifications.
In addition to supporting conventional data access, it also supports PTZ control for cameras and standard 28181 service docking.
Disadvantages: there are not many external servers supporting GB28181. For example, the support of open source SRS servers for GB28181 is not commercial grade. We look forward to better support for subsequent versions.
Taking Haikang camera docking platform 281 as an example, the specific interaction process is as follows:
REGISTER sip:34020000002000000001@3402000000 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.120:15068;rport;branch=z9hG4bK1624213340 From: <sip:34020000001110000044@3402000000>;tag=2045629479 To: <sip:34020000001110000044@3402000000> Call-ID: 1367363228 CSeq: 1 REGISTER Contact: <sip:34020000001110000044@192.168.0.120:15068> Max-Forwards: 70 User-Agent: IP Camera Expires: 3600 Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.120:15068;rport=15068;received=192.168.0.120;branch=z9hG4bK1624213340 From: <sip:34020000001110000044@3402000000>;tag=2045629479 To: <sip:34020000001110000044@3402000000>;tag=993246605 CSeq: 1 REGISTER Call-ID: 1367363228 User-Agent: LiveGBS v210723 Contact: <sip:34020000001110000044@192.168.0.120:15068> Content-Length: 0 Date: 2021-08-13T10:14:11.789 Expires: 3600 MESSAGE sip:34020000001110000044@3402000000 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.199:15060;rport;branch=z9hG4bK796247609 From: <sip:34020000002000000001@3402000000>;tag=180247609 To: <sip:34020000001110000044@3402000000> Call-ID: 807247609 CSeq: 2 MESSAGE Content-Type: Application/MANSCDP+xml Max-Forwards: 70 User-Agent: LiveGBS v210723 Content-Length: 157 <?xml version="1.0" encoding="GB2312"?> <Query> <CmdType>Catalog</CmdType> <SN>552247609</SN> <DeviceID>34020000001110000044</DeviceID> </Query> SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.199:15060;rport=15060;branch=z9hG4bK796247609 From: <sip:34020000002000000001@3402000000>;tag=180247609 To: <sip:34020000001110000044@3402000000>;tag=1518451596 Call-ID: 807247609 CSeq: 2 MESSAGE User-Agent: IP Camera Content-Length: 0 MESSAGE sip:34020000002000000001@3402000000 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.120:15068;rport;branch=z9hG4bK138770826 From: <sip:34020000001110000044@3402000000>;tag=2116434170 To: <sip:34020000002000000001@3402000000> Call-ID: 111408894 CSeq: 20 MESSAGE Content-Type: Application/MANSCDP+xml Max-Forwards: 70 User-Agent: IP Camera Content-Length: 590 <?xml version="1.0" encoding="GB2312"?> <Response> <CmdType>Catalog</CmdType> <SN>552247609</SN> <DeviceID>34020000001110000044</DeviceID> <SumNum>1</SumNum> <DeviceList Num="1"> <Item> <DeviceID>34020000001320000001</DeviceID> <Name>Camera 01</Name> <Manufacturer>Hikvision</Manufacturer> <Model>IP Camera</Model> <Owner>Owner</Owner> <CivilCode>CivilCode</CivilCode> <Address>Address</Address> <Parental>0</Parental> <ParentID>34020000001110000044</ParentID> <SafetyWay>0</SafetyWay> <RegisterWay>1</RegisterWay> <Secrecy>0</Secrecy> <Status>ON</Status> </Item> </DeviceList> </Response> SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.120:15068;rport=15068;received=192.168.0.120;branch=z9hG4bK138770826 From: <sip:34020000001110000044@3402000000>;tag=2116434170 To: <sip:34020000002000000001@3402000000>;tag=514247616 CSeq: 20 MESSAGE Call-ID: 111408894 User-Agent: LiveGBS v210723 Content-Length: 0 MESSAGE sip:34020000002000000001@3402000000 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.120:15068;rport;branch=z9hG4bK1946244729 From: <sip:34020000001110000044@3402000000>;tag=1705757152 To: <sip:34020000002000000001@3402000000> Call-ID: 1030239866 CSeq: 20 MESSAGE Content-Type: Application/MANSCDP+xml Max-Forwards: 70 User-Agent: IP Camera Content-Length: 177 <?xml version="1.0" encoding="GB2312"?> <Notify> <CmdType>Keepalive</CmdType> <SN>11</SN> <DeviceID>34020000001110000044</DeviceID> <Status>OK</Status> <Info> </Info> </Notify> SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.120:15068;rport=15068;received=192.168.0.120;branch=z9hG4bK1946244729 From: <sip:34020000001110000044@3402000000>;tag=1705757152 To: <sip:34020000002000000001@3402000000>;tag=334251619 CSeq: 20 MESSAGE Call-ID: 1030239866 User-Agent: LiveGBS v210723 Content-Length: 0 MESSAGE sip:34020000002000000001@3402000000 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.120:15068;rport;branch=z9hG4bK1402863583 From: <sip:34020000001110000044@3402000000>;tag=754663007 To: <sip:34020000002000000001@3402000000> Call-ID: 187348500 CSeq: 20 MESSAGE Content-Type: Application/MANSCDP+xml Max-Forwards: 70 User-Agent: IP Camera Content-Length: 177 <?xml version="1.0" encoding="GB2312"?> <Notify> <CmdType>Keepalive</CmdType> <SN>12</SN> <DeviceID>34020000001110000044</DeviceID> <Status>OK</Status> <Info> </Info> </Notify> SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.120:15068;rport=15068;received=192.168.0.120;branch=z9hG4bK1402863583 From: <sip:34020000001110000044@3402000000>;tag=754663007 To: <sip:34020000002000000001@3402000000>;tag=959261639 CSeq: 20 MESSAGE Call-ID: 187348500 User-Agent: LiveGBS v210723 Content-Length: 0
RTSP push
There are few data and test software related to RTSP push, and RTSP TCP mode and UDP mode are supported. Unless connected to a third-party platform, RTSP push is not recommended.
The specific process is as follows:
1. rtsp push process
It is mainly divided into two parts: the first part sends signaling first; The second part sends rtp packets.
Signaling process:
one point one Send options first. Options is commonly used, so I won't explain it in detail.
1.2 send ANNOUNCE, which mainly transmits the audio and video information to be pushed to the server through sdp format. Refer to rfc6184 for h264 and rfc7798 for h265 for how to construct sdp information. Here are two examples
h264+aac ANNOUNCE:
ANNOUNCE rtsp://192.168.0.188:554/livexxxx.sdp RTSP/1.0
Content-Type: application/sdp
CSeq: 2
User-Agent: xxxyyy
Content-Length: 489
v=0
o=- 0 0 IN IP4 127.0.0.1
s=dddookkk
c=IN IP4 192.168.0.188
t=0 0
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z00AKp2oHgCJ+WbgICAoAAADAAgAAAMBlCA=,aO48gA==; profile-level-id=4D002A
a=control:streamid=0
m=audio 0 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/44100/1
a=fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3; config=1208
a=control:streamid=1
h265(hevc) + aac ANNOUNCE:
ANNOUNCE rtsp://192.168.0.174:554/live3.sdp RTSP/1.0
Content-Type: application/sdp
CSeq: 2
User-Agent: mmmmd
Content-Length: 364
v=0
o=- 0 0 IN IP4 127.0.0.1
s=uvsdewewe
c=IN IP4 192.168.0.174
t=0 0
m=video 0 RTP/AVP 96
a=rtpmap:96 H265/90000
a=control:streamid=0
m=audio 0 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/44100/1
a=fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3; config=1208
a=control:streamid=1
1.3 sending SETUP is basically the same as playback. Please refer to the playback process
1.4 sending After record and record, the signaling process is completed, and then the rtp packet can be sent.
For the construction of rtp packets, h264 refer to rfc6184. h265 reference rfc7798.
Taking Android platform as an example, the relevant interface design is as follows:
/*+++++++++++++++Push rtsp related interfaces+++++++++++++++*/ /* * Set push rtsp transmission mode * * @param transport_protocol: 1 Represents UDP transmission rtp packet; 2 means TCP transmits rtp packets. The default is 1. UDP transmits other values. SDK reports an error. * * @return {0} if successful */ public native int SetPushRtspTransportProtocol(long handle, int transport_protocol); /* * Set URL of push RTSP * * @param url: RTSP url pushed * * @return {0} if successful */ public native int SetPushRtspURL(long handle, String url); /* * Start pushing RTSP stream * * @param reserve: Reserved parameters, pass 0 * * @return {0} if successful */ public native int StartPushRtsp(long handle, int reserve); /* * Stop pushing RTSP stream * * @return {0} if successful */ public native int StopPushRtsp(long handle); /*---------------Push rtsp related interfaces---------------*/
RTMP push
RTMP adopts TCP transmission and self-developed framework, which is easy to expand. The adaptive algorithm makes the delay lower and the transmission efficiency of acquisition coding higher. Delay cooperating with Daniel live SDK( official )The player can still achieve milliseconds.
The cross platform design is as follows:
- [local preview] Windows platform supports real-time preview of camera / screen / synthetic data, and Android/iOS platform supports local front and rear camera preview;
- [camera inversion / rotation] Windows platform supports horizontal inversion, vertical inversion and 0 ° / 90 ° / 180 ° / 270 ° rotation of the camera;
- [camera acquisition] in addition to the conventional YUV format, the Windows platform also supports camera acquisition in MJPEG format;
- [microphone / speaker acquisition] the Windows platform audio input terminal supports microphone, speaker, or microphone and speaker mixed input;
- [RTMP streaming] RTMP protocol live streaming SDK with ultra-low delay (Windows/Android/iOS supports RTMP extension H.265 push);
- [video format] Windows/Android platform supports H.264/H.265 coding (Android H.265 hard coding), and iOS platform supports H.264 coding;
- [audio format] Windows/Android/iOS platform supports AAC coding, and Windows/Android platform supports Speex coding;
- [audio coding] Windows/Android platform supports Speex push and Speex coding quality settings;
- [volume adjustment] the acquisition terminal of Windows/Android platform supports real-time volume adjustment (among which, the volume of microphone and speaker can be controlled separately under the mixing mode of Windows platform);
- [H.264 hard coding] Windows/Android/iOS platform supports hard coding of H.264 specific models;
- [H.265 hard coding] Android/iOS platform supports hard coding of H.265 specific models;
- [hard coding adaptation] Android/iOS platform supports hard coding adaptation. If it is detected that hard coding is not supported, it will automatically switch to soft coding (iOS, such as H.265 hard coding, switch to H.264 hard coding first, and try H.264 soft coding if it is not supported);
- [soft and hard coding parameter configuration] support gop interval, frame rate and bit rate settings;
- [soft coding parameter configuration] supports soft coding profile, soft coding speed and variable bit rate settings;
- [multi instance push] support multi instance push (such as pushing screen / camera and external data at the same time);
- [RTMP extension H.265] the windows / Android/iOS push SDK supports RTMP extension H.265 push. Windows collects soft coding for cameras, uses H.265 variable bit rate, and saves bandwidth significantly. The effect is similar to that of traditional H.265 coded cameras. Android/iOS platform supports H.265 hard coding;
- [horizontal and vertical screen streaming] Android/iOS platform supports horizontal and vertical screen streaming;
- [multi resolution support] support multiple resolution settings of camera or screen;
- [Windows push screen] Windows platform supports screen clipping, window acquisition, screen / camera data synthesis and other push modes;
- [mobile terminal push screen] Android platform supports background service push screen (push screen requires version 5.0 +);
- [mobile terminal push screen] iOS platform supports background push screen (based on ReplayKit, iOS 10.0 + version is required);
- [event callback] supports real-time callback of various states;
- [watermark] Windows platform supports text watermark, png watermark and real-time occlusion, while Android platform supports text watermark and png watermark;
- [RTMP push mode] support RTMP push live|record mode setting (server support is required);
- [image] Android/iOS platform supports real-time image function of front camera;
- [real time switching between front and rear cameras] Android/iOS platform supports switching between front and rear cameras during acquisition;
- [complex network processing] support automatic adaptation of various network environments such as network disconnection and reconnection;
- [dynamic bit rate] supports automatic adjustment of streaming bit rate according to network conditions;
- [real time mute] support real-time mute / unmute during push;
- [real time snapshot] supports real-time snapshot during streaming;
- [pure audio streaming] supports the function of only collecting audio streaming and initiating streaming;
- [pure video streaming] supports pure video streaming in special scenes;
- [noise reduction] Windows/Android platform supports noise reduction, automatic gain and VAD detection caused by ambient sound and mobile phone interference;
- [echo cancellation] Android platform supports real-time transmission of remote PCM data to facilitate echo cancellation processing;
- [video data docking before external coding] support YUV data docking;
- [external coding front audio data docking] support PCM docking;
- [video data docking after external coding] support external H.264 data docking;
- [audio data docking after external coding] external AAC/PCMA/PCMU/SPEEX data docking;
- [push end sleep setting] the Windows platform supports the sleep interface (the CPU will be reduced appropriately after the sleep mode is set);
- [data output after coding] Android platform supports the output of coded H264/AAC data to the upper layer, which is convenient for docking with third-party platforms (such as GB28181);
- [extended recording function] perfect support for combined use with recording SDK. For recording related functions, see "Windows/Android/iOS recording SDK";
- [clipping mode] Android/iOS platform supports camera clipping mode setting of specific resolution;
- [server compatible] support self built servers (such as Nginx, SRS) or CDN.
Interested developers can refer to it by themselves.