原文鏈接：
https://zhuanlan.zhihu.com/p/393863592

1、背景介紹
GB28181協議指的是國家標準GB/T 28181—2016《公共安全視頻監控聯網系統信息傳輸、交換、控制技術要求》1，該標準規定了公共安全視頻監控聯網系統的互聯結構， 傳輸、交換、控制的基本要求和安全性要求， 以及控制、傳輸流程和協議接口等技術要求，是視頻監控領域的國家標準。GB28181協議信令層面使用的是SIP（Session Initiation Protocol）協議2，流媒體傳輸層面使用的是實時傳輸協議（Real-time Transport Protocol，RTP）協議3，因此可以理解為GB28181是在國際通用標準的基礎之上進行了私有化定制以滿足視頻監控聯網系統互聯傳輸的標準化需求。本文旨在說明在FFmpeg中增加對GB28181協議的支持，使其可以與支持GB28181協議的設備進行通信與控制，實現設備的注冊、保活以及流媒體的傳輸。

2、相關技術介紹
2.1 GB28181協議
GB28181協議會話通道實際上使用的是SIP協議，并且在SIP協議的基礎之上做了些私有化處理。SIP是一個由IETF MMUSIC工作組開發的協議，作為標準被提議用于創建，修改和終止包括視頻，語音，即時通信，在線游戲和虛擬現實等多種多媒體元素在內的交互式用戶會話。SIP中一個比較重要的概念是用戶代理（User Agent），指的是一個SIP邏輯網絡端點，用于創建、發送、接收SIP消息并管理一個SIP會話。SIP用戶代理又可分為用戶代理客戶端UAC（User Agent Client）和用戶代理服務端UAS（User Agent Server）。UAC創建并發送SIP請求，UAS接收處理SIP請求，發送SIP響應。SIP協議會與許多其它的協議協同工作，如SIP報文內容發送會話描述協議（Session Description Protocol，SDP）4，SDP協議描述了會話所使用流媒體細節，如：使用哪個IP端口，采用哪種編解碼器等等。SIP的一個典型用途是：SIP會話傳輸一些簡單的經過報文的實時傳輸協議流，RTP本身才是語音或視頻的載體。在GB28181協議中，聯網系統在進行視音頻傳輸及控制時應建立兩個傳輸通道: 會話通道和媒體流通道。會話通道用于在設備之間建立會話并傳輸系統控制命令; 媒體流通道用于傳輸視音頻數據， 經過壓縮編碼的視音頻流采用流媒體協議RTP/RTCP傳輸。GB28181協議中具體通信協議結構圖如下圖1所示：

會話通道中，注冊、實時視音頻點播、歷史視音頻的回放等應用的會話控制采用SIP協議IETF RFC3261中規定的REGISTER、INVITE等請求和響應方法實現， 歷史視音頻回放控制采用SIP擴展協議IETF RFC29765規定的INFO方法實現，前端設備控制、信息查詢、報警事件通知和分發等應用的會話控制采用SIP擴展協議IETF RFC34287規定的MESSAGE方法實現。下面詳細介紹下注冊、保活和實時視音頻點播的SIP消息結構。

2.1.1 注冊
注冊指的是設備或系統進入聯網系統時向SIP服務器（SIP UAS）進行注冊登記的工作模式，在本文中FFmpeg即為一個SIP服務器，設備向FFmpeg發送注冊請求，FFmpeg在接收到設備的注冊請求后返回相應的回復消息，則完成設備注冊流程。GB28181協議中基于數字摘要的挑戰應答式安全技術進行注冊流程如下圖2所示：

注冊流程描述如下:

(a) SIP代理向SIP服務器發送Register請求;

(b) SIP服務器向SIP代理發送響應401，并在響應的消息頭WWW_Authenticate字段中給出適合SIP代理的認證體制和參數;

? SIP代理重新向SIP服務器發送REGISTER請求， 在請求的Authorization字段給出信任書，包含認證信息;

(d) SIP服務器對請求進行驗證，如果檢查出SIP代理身份合法，向SIP代理發送成功響應200OK，如果身份不合法則發送拒絕服務應答。

注冊的請求消息內容范例如下：

1 REGISTER sip:34020000002000000001@3402000000 SIP/2.0

2 Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1371463273

3 From: sip:34020000001320000003@3402000000;tag=2043466181

4 To: sip:34020000001320000003@3402000000

5 Call-ID: 1011047669

6 CSeq: 1 REGISTER

7 Contact: sip:34020000001320000003@192.168.137.11:5060

8 Max-Forwards: 70

9 User-Agent: IP Camera

10 Expires: 3600

11 Content-Length: 0

第1行表明這條SIP消息的方法（Method）是REGISTER，34020000002000000001是SIP服務器的國標ID，國標ID指的是由中心編碼(8位) 、行業編碼(2位) 、類型編碼(3位)和序號(7位)四個碼段共20位十進制數字字符構成，具體國標ID的編碼方法可以參考GB/T 28181—2016中的附錄D。3402000000指的是SIP服務器的域國標ID，SIP/2.0指的是SIP協議版本。
第2行為Via頭，Via頭中包含了發送請求方的相關信息，后續需要使用這些信息進行回復。SIP/2.0/UDP表示使用的是2.0版本的SIP協議，使用的傳輸協議是UDP，也可以使用TCP協議。192.168.137.11:5060為請求發送方的IP地址和端口號。Via頭中必須包含branch參數，具體值是一個在整個SIP通信過程中不重復的數值。branch是一個事務ID（Transaction ID），用于區分同一個UA所發起的不同Transaction，它不會對未來的request或者是response造成影響，對于遵循IETF RFC3261規范的實現，這個branch參數的值必須用”z9hG4bK”打頭. 其它部分是對To， From, Call-ID頭域和Request-URI按一定的算法加密后得到。rport字段表示使用rport機制路由響應，即發送的響應時，按照rport中的端口發送SIP響應，也就是說IP和端口均完全遵照從哪里來的，發回哪里去的原則，如果沒有rport字段時，服務端的策略是IP使用UDP包中的地址，即從哪里來回哪里去，但是端口使用的是via中的端口，詳情見IETF RFC35818。
第3行為From頭，From頭中包含了請求發送方的邏輯標識，在GB28181協議中是發送請求的設備國標ID和域國標ID信息。tag參數是為了身份認證的，值為隨機數字字符。
第4行為To頭，To頭在SIP協議中是為了標明請求接收方的邏輯標識的，在GB28181協議中填寫的是發送請求的設備國標ID和域國標ID信息。
第5行為Call-ID頭，Call-ID頭是全局唯一的，在同一個session中保持一致，在不同session中不同。
第6行為CSeq頭，CSeq頭又叫Command Seqence（命令隊列），用于標識命令順序，值為序號+Method，序號部分為無符號整數，最大值為2^31。序號起始值是隨機的，后續在同一個session中依次遞增，比如發1 REGISTER沒返回—>再發2 REGISTER—>沒返回—>再發3 REGISTER—>這時返回了2 REGISTER就知道是第2個請求得到了響應。對于ACK和CANCLE中的CSeq與INVITE中的Cseq保持一致。
第7行為Contact頭，Contact頭包含源的URI信息，用來給響應消息直接和源建立連接用。在GB28181協議中為SIP設備編碼@源IP地址端口。
第8行為Max-Forwards頭，Max-Forwards頭用于設置包最大中轉次數，默認是70。
第9行為User-Agent頭，User-Agent頭用于設置關于UA的信息，用戶可以自定義。
第10行為Expires頭，Expires頭表示超時時間。
第11行為Content-Length頭，Content-Length頭表示SDP消息的長度，因為REGISTER消息不需要SDP，因此為0。
注冊的回復消息內容范例如下，各頭信息含義見上面：

1SIP/2.0 200 OK2Via: SIP/2.0/UDP192.168.137.11:5060;rport;branch=z9hG4bK13714632733From: sip:34020000001320000003@34020000004To: sip:34020000001320000003@34020000005CSeq: 1 REGISTER6Call-ID: 10110476697Contact: sip:34020000001320000003@192.168.137.11:50608User-Agent: FFmpeg GB28181 v1.09Expires: 360010Content-Length: 0

2.1.2 保活
當UA發現工作異常時， 應立即向本SIP監控域的SIP服務器發送狀態信息; 無異常時，應定時向本SIP監控域的SIP服務器發送狀態信息。狀態信息報送采用IETF RFC3427中定義的方法MESSAGE實現。通過周期性的狀態信息報送，實現注冊服務器與源設備之間的狀態檢測即心跳機制。心跳發送方、接收方需統一配置“心跳間隔”參數，按照“心跳間隔”定時發送心跳消息，默認心跳間隔60s。心跳發送方、接收方需統一配置“心跳超時次數”參數，心跳消息連續超時達到“心跳超時次數”則認為對方下線，默認心跳超時次數3次。心跳接收方在心跳發送方上線狀態下檢測到心跳消息連續超時達到商定次數則認為心跳發送方離線; 心跳發送方在心跳接收方上線狀態下檢測到心跳消息響應消息連續超時達到商定次數則認為心跳接收方離線。具體命令流程如圖3：

命令流程描述如下:

(a) 源設備向SIP服務器發送設備狀態信息報送命令。設備狀態信息報送命令采用MESSAGE方法攜帶;

(b) SIP服務器收到命令后返回200 OK。

保活消息內容范例如下：

1 MESSAGE sip:34020000002000000001@3402000000 SIP/2.0

2 Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1066375804

3 From: sip:34020000001320000003@3402000000;tag=1925919231

4 To: sip:34020000002000000001@3402000000

5 Call-ID: 1185236415

6 CSeq: 20 MESSAGE

7 Content-Type: Application/MANSCDP+xml

8 Max-Forwards: 70

9 User-Agent: IP Camera

10 Content-Length: 175

11 <?xml version="1.0" encoding="UTF-8"?>

12

13 Keepalive

14 1

15 34020000001320000003

16 OK

17

18

19

MESSAGE消息頭Content-type頭為Content-type: Application/MANSCDP+xml。狀態信息報送命令采用MANSCDP（監控報警聯網系統控制描述協議，Monitoringand Alarming Network System Control Description Protocol）協議格式定義， 詳細描述見GB/T 28181—2016中A.2.5狀態信息報送。狀態信息報送命令應包括命令類型(CmdType)、設備/系統編碼(DeviceID)、是否正常工作(Status)等， 采用MESSAGE方法的消息體攜帶。Message消息的成功和錯誤應答均無消息體，Message回復消息內容范例如下：

1 SIP/2.0 200 OK

2 Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1066375804

3 From: sip:34020000001320000003@3402000000

4 To: sip:34020000002000000001@3402000000

5 CSeq: 20 MESSAGE

6 Call-ID: 1185236415

7 User-Agent: FFmpeg GB28181 v1.0

8 Content-Length: 0

2.1.3 實時音視頻播放
實時視音頻點播采用SIP協議中的INVITE方法實現會話連接，采用RTP/RTCP協議(IETF RFC3550)實現媒體傳輸。需要注意的是，實時視音頻點播需要上述的媒體流保活機制。客戶端主動發起的實時視音頻點播流程見圖4:

其中，信令1、8、9、10、11、12為SIP服務器接收到客戶端的呼叫請求后通過B2BUA代理方式建立媒體流接收者與媒體服務器之間的媒體流信令過程，信令2-7為SIP服務器通過三方呼叫控制建立媒體服務器與媒體流發送者之間的媒體流信令過程，信令13-16為媒體流接收者斷開與媒體服務器之間的媒體流信令過程，信令17-20為SIP服務器斷開媒體服務器與媒體流發送者之間的媒體流信令過程。

命令流程描述如下:

(a) 媒體流接收者向SIP服務器發送INVITE消息， 消息頭域中攜帶Subject字段， 表明點播的視頻源ID、發送方媒體流序列號、媒體流接收者ID、接收端媒體流序列號等參數，SDP消息體中s字段為“Play”代表實時點播。

(b) SIP服務器收到INVITE請求后，通過三方呼叫控制建立媒體服務器和媒體流發送者之間的媒體連接。向媒體服務器發送INVITE消息，此消息不攜帶SDP消息體。

? 媒體服務器收到SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體服務器接收媒體流的IP、端口、媒體格式等內容。

(d) SIP服務器收到媒體服務器返回的200 OK響應后，向媒體流發送者發送INVITE請求，請求中攜帶消息3中媒體服務器回復的200 OK響應消息體，s字段為“Play”代表實時點播， 增加y字段描述SSRC值，f字段描述媒體參數。

(e) 媒體流發送者收到SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流發送者發送媒體流的IP、端口、媒體格式、SSRC字段等內容。

(f) SIP服務器收到媒體流發送者返回的200 OK響應后，向媒體服務器發送ACK請求，請求中攜帶消息5中媒體流發送者回復的200 OK響應消息體， 完成與媒體服務器的INVITE會話建立過程。

(g) SIP服務器收到媒體流發送者返回的200 OK響應后，向媒體流發送者發送ACK請求，請求中不攜帶消息體，完成與媒體流發送者的INVITE會話建立過程。

(h) 完成三方呼叫控制后，SIP服務器通過B2BUA代理方式建立媒體流接收者和媒體服務器之間的媒體連接。在消息1中增加SSRC值，轉發給媒體服務器。

(i) 媒體服務器收到INVITE請求，回復200OK響應，攜帶SDP消息體，消息體中描述了媒體服務器發送媒體流的IP、端口、媒體格式、SSRC值等內容。

(j) SIP服務器將消息9轉發給媒體流接收者。

(k) 媒體流接收者收到200 OK響應后，回復ACK消息，完成與SIP服務器的INVITE會話建立過程。

(l) SIP服務器將消息11轉發給媒體服務器，完成與媒體服務器的INVITE會話建立過程。

(m) 媒體流接收者向SIP服務器發送BYE消息，斷開消息1、10、11建立的同媒體流接收者的INVITE會話。

(n) SIP服務器收到BYE消息后回復200 OK響應， 會話斷開。

(o) SIP服務器收到BYE消息后向媒體服務器發送BYE消息，斷開消息8、9、12建立的同媒體服務器的INVITE會話。

§ 媒體服務器收到BYE消息后回復200 OK響應， 會話斷開。

(q) SIP服務器向媒體服務器發送BYE消息,斷開消息2、3、6建立的同媒體服務器的INVITE會話。

? 媒體服務器收到BYE消息后回復200 OK響應,會話斷開。

(s) SIP服務器向媒體流發送者發送BYE消息，斷開消息4、5、7建立的同媒體流發送者的INVITE會話。

(t) 媒體流發送者收到BYE消息后回復200 OK響應, 會話斷開。

上述流程較為復雜，原因是在實際視頻監控系統中，用戶不是直接跟前端監控設備交互，而是與監控管理平臺交互。媒體流接收者通常是用戶的客戶端，SIP服務器是單獨的服務器，媒體服務器通常是監控系統中的媒體網關，媒體流發送者為前端攝像機。本文中FFmpeg既作為SIP服務器，也作為用戶客戶端向前端設備發送INVITE請求，因此可以簡化為FFmpeg向前端設備發送INVITE請求后，前端設備向FFmpeg回復200OK，然后FFmpeg再向前端設備回復ACK，這樣前端設備即開始發送媒體流。

INVITE消息范例如下：

1 INVITE sip:34020000001320000003@3402000000 SIP/2.0

2 Via: SIP/2.0/UDP 39.100.155.146:15063;rport;branch=z9hG4bK34208805

3 From: sip:34020000002000000001@39.100.155.146:15063;tag=512358805

4 To: sip:34020000001320000003@3402000000

5 Call-ID: 200008805

6 CSeq: 20 INVITE

7 Content-Type: Application/SDP

8 Contact: sip:34020000001320000003@3402000000

9 Max-Forwards: 70

10 User-Agent: FFmpeg GB28181 v1.0

11 Subject: 34020000001320000003:630886,34020000002000000001:0

12 Content-Length: 164

13 v=0

14 o=34020000001320000003 0 0 IN IP4 39.100.155.146

15 s=Play

16 c=IN IP4 39.100.155.146

17 t=0 0

18 m=video 9000 RTP/AVP 96

19 a=recvonly

20 a=rtpmap:96 PS/90000

21 y=630886

SIP消息頭部分上述已經解釋過了，這里解釋下SDP相關字段含義。

v=表示的SDP版本，固定值，為0。
o=表示INVITE發起者的相關信息，后面的內容依次為設備國標ID、session ID、session版本、網絡類型（IN/OUT）、地址類型（IPV4/IPV6）、發起者IP。
s=表示session名稱，GB28181協議中規定實時點播必須填“Play”。
c=表示連接數據，依次是網絡類型（IN/OUT）、地址類型（IPV4/IPV6）、發起者IP。
t=表示起始時間和終止時間，由于是實時點播，沒有起始時間和終止時間，因此均為0.
m=表示的媒體流參數，m字段描述媒體的媒體類型、端口、傳輸層協議、負載類型等內容。媒體類型采用“video”標識傳輸視頻或視音頻混合內容,采用“audio”標識傳輸音頻內容; 傳輸方式采用“RTP/AVP”標識傳輸層協議為RTP over UDP,采用“TCP/RTP/AVP”標識傳輸層協議為RTP over TCP。例如:“m=video 6000 RTP/AVP 96”標識媒體類型為視頻或視音頻, 傳輸端口為6000,采用RTP over UDP傳輸方式,負載類型為96。“m=video 6000 TCP/RTP/AVP 96”標識媒體類型為視頻或視音頻,傳輸端口為6000,采用RTP over TCP傳輸方式, 負載類型為96。
a=可以用于表示媒體相關的參數，如啟用IETF RFC 4566中對a字段的定義a=rtpmap: / [/]中的， 利用該屬性攜帶編碼器廠商名稱(如:企業1或企業2編碼名稱DAHUA或HIKVISION)。該屬性表明該流為某廠商編碼器編碼且是不符合本標準規定的媒體流， 符合本標準規定的媒體流無需該屬性。recvonly表示僅接收媒體流，sendonly表示僅發送。
y=表示SSRC，可以在端口復用模式情況下區分不同路的媒體流，SSRC值全局唯一，用戶可以自定義。
INVITE回復消息范例如下：

1SIP/2.0 200 OK2Via: SIP/2.0/UDP39.100.155.146:15063;rport=15063;branch=z9hG4bK342088053From: sip:34020000002000000001@39.100.155.146:15063;tag=5123588054To: sip:34020000001320000003@3402000000;tag=10831113115Call-ID: 2000088056CSeq: 20 INVITE7Contact: sip:34020000001320000003@192.168.137.11:50608Content-Type: application/sdp9User-Agent: IP Camera10Content-Length: 26311v=012o=34020000001320000003 1073 1073 IN IP4 192.168.137.1113s=Play14c=IN IP4 192.168.137.1115t=0 016m=video 15060 RTP/AVP 9617a=setup:active18a=sendonly19a=rtpmap:96 PS/9000020y=0000630886

ACK消息范例如下：

1ACK sip:34020000001320000003@3402000000 SIP/2.02Via: SIP/2.0/UDP 39.100.155.146:15063;rport;branch=z9hG4bK342088053From: sip:34020000002000000001@39.100.155.146:15063;tag=5123588054To: sip:34020000001320000003@34020000005Call-ID: 2000088056CSeq: 20 ACK7Max-Forwards: 708User-Agent: FFmpeg GB28181 v1.09Content-Length: 0

BYE消息范例如下：

1BYE sip:34020000001320000003@3402000000 SIP/2.02Via: SIP/2.0/UDP 39.100.155.146:15063;rport;branch=z9hG4bK342088053From: sip:34020000002000000001@3402000000;tag=5123588054To: sip:34020000001320000003@3402000000;tag=10831113115Call-ID: 2000088056CSeq: 79 BYE7Max-Forwards: 708User-Agent: FFmpeg GB28181 v1.09Content-Length: 0

2.2 RTP協議

RTP是一個網絡傳輸協議，IETF RFC3550詳細描述了RTP協議內容。GB28181協議中規定了兩種方式傳輸媒體流，一種是將音視頻數據打包成MPEG2-PS流然后再通過RTP協議傳輸，另外一種是直接使用RTP傳輸裸的音視頻流，在實際應用中主要以第一種方式為主，因此本文著重介紹下第一種方式。基于RTP的PS封裝首先按照ISO/IEC13818-1:20008將視音頻流封裝成PES包，然后再將PES包封裝成PS包， 再將PS包以負載的方式封裝成RTP包。進行PS封裝時，應將每個視頻幀封裝為一個PS包，且每個關鍵幀的PS包中應包含系統頭(System Header)和PSM(Program Stream Map)，系統頭和PSM放置于PS包頭之后、第一個PES包之前。典型的視頻關鍵幀PS包結構如圖6所示，其中PESV為視頻PES包，PESA為音頻PES包，視頻非關鍵幀的PS包結構中一般不包含系統頭和PSM。PS包中各部分的具體數據結構參見ISO/IEC13818-1:2000中的相關描述。

系統頭應包含對PS包中碼流種類的描述, 其中視頻和音頻的流ID(stream_id)取值如下:

(a) 視頻流ID:0xE0;

(b) 音頻流ID:0xC0。

針對幾種視音頻格式,PSM中流類型(stream_type)的取值如下:

(a) MPEG-4 視頻流:0x10;

(b) H.264 視頻流:0x1B;

? SVAC 視頻流:0x80;

(d) G.711 音頻流:0x90;

(e) G.722.1 音頻流:0x92;

(f) G.723.1 音頻流:0x93;

(g) G.729 音頻流:0x99;

(h) SVAC 音頻流:0x9B。

PS包的RTP封裝格式參照IETF RFC2250,RTP的主要參數設置如下:

(a) 負載類型(payloadtype):96;

(b) 編碼名稱(encoding_name):PS;

? 時鐘頻率(clockrate):90 kHz;

(d) SDP描述中“m”字段的“media”項:video。

3、方案實現
3.1 GB28181 demuxer
首先我們在FFmpeg中實現了GB28181協議的demuxer，方案的框架圖如圖6所示。主要包含兩個子模塊，一個是SIP stack模塊，負責SIP協議功能，一個GB28181 demuxer模塊，負責調用SIP接口與前端設備IPC進行交互，同時解析IPC通過RTP發送過來的MPEG2-PS流，得到音視頻數據流后以packet的形式返回給lavf上層，再依次往FFmpeg上層傳。SIP stack模塊提供單一功能的SIP接口，比如發送回復消息，發送INVITE/BYE/ACK請求；GB28181 demuxer模塊需要按照FFmpeg上層接口調用順序與IPC進行相關的交互，同時創建與設備之間的RTP鏈接，在拿到MPEG2-PS流后進行解析。

由于FFmpeg只有解析PS流封裝的本地視頻demuxer，并沒有解析PS流的demuxer，因此本文也在本地PS流封裝視頻demuxer的基礎之上實現了PS流的demuxer。核心思路是從RTP包中解析PS頭信息，再根據PS頭信息找到PES頭，從PES頭中取出每個PES包的長度。由于RTP長度限制，一個PES包會被切分成很多份分成多個RTP包傳輸過來，因此PS demuxer需要緩存這些PES切片，等一個完整的PES包湊齊后再解析取出音視頻流并以packet格式返回上FFmpeg上層模塊。由于IETF RFC22509并沒有規定PS流應該如何封裝到RTP中，因此PES頭可能出現在RTP包的任何位置，demuxer也針對不同的情況做了處理。

3.2 GB28181 Server
上述方案存在局限性，只能對單一設備進行管理和拉流，但實際場景中一個SIP域中存在眾多設備。因此在上述GB28181 demuxer的基礎之上，我們也實現了GB28181 server，方案的框架圖如下圖7所示。

GB28181 server功能包括：
1、作為SIP server，管理多設備的注冊、保活監控、拉流/停止拉流信令交互；
2、作為media server，對外提供HTTP接口，用戶可以獲取設備信息、對指定設備進行拉流并轉推RTMP、停止拉流等操作。
GB28181 server可以使用戶不感知GB28181協議的存在，用戶只需要對感興趣的設備進行操作即可。具體實現中，我們對上述GB28181 demuxer進行了功能擴展，使其具備兩種工作模式，一種就是上述的單一設備模式，一種就是多設備管理模式。后者將設備狀態信息、發送拉流/停止拉流接口暴露出來供GB28181 server調用。因此當GB28181 server運行后，其自動會對發出注冊請求的設備進行管理，監控設備是否在線或離線并更新設備信息。同時監聽用戶請求，當接收到用戶的HTTP請求時做相應的拉流/停止拉流等操作。

總結

以上是生活随笔為你收集整理的GB28181协议简介及实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。