簡介這是一份面向Linux環(huán)境的RTSP客戶端C語言實現(xiàn)源碼包適用于網(wǎng)絡(luò)流媒體開發(fā)者、嵌入式工程師及協(xié)議學(xué)習(xí)者解決在Linux下啟動、暫停、快進等實時流控制及RTP視頻流獲取問題。壓縮包共4個文件3個C源文件加1個頭文件整體僅5KB代碼精簡便于閱讀C文件分別對應(yīng)RTSP命令交互、RTP數(shù)據(jù)接收以及測試驗證邏輯頭文件集中定義協(xié)議狀態(tài)機與關(guān)鍵數(shù)據(jù)結(jié)構(gòu)。目前已有952人學(xué)習(xí)/下載適合需要快速理解RTSP/RTP協(xié)議棧的讀者。通過源碼可掌握基于socket的RTSP會話建立流程理解OPTIONS、DESCRIBE、SETUP、PLAY等指令的實際構(gòu)造與解析方法并借助測試程序驗證客戶端收發(fā)邏輯為后續(xù)二次開發(fā)或移植到嵌入式平臺提供可直接引用的實現(xiàn)范式。1. RTSP客戶端不是“發(fā)個 PLAY 就完事”一個 Linux C 實現(xiàn)到底該怎么拆做嵌入式或者 Linux 平臺上的視頻接入大概率都繞不過 RTSP 拉流。你在網(wǎng)上搜“RTSPClient”“rtsp 客戶端 linux”能找到的代碼不少但真正能拿過來編譯、跑通、抓到 RTP 數(shù)據(jù)包的卻沒幾個。這個名叫 rtspclient 的源碼包就是這類稀缺資源用純 C 實現(xiàn)不依賴任何第三方庫核心代碼只有 rtsp.c、rtspclient.c、testrtsp.c 加一個頭文件。它解決的問題很直接——在 Linux 下用 socket 向攝像頭或流媒體服務(wù)器發(fā)送 RTSP 命令協(xié)商出媒體通道然后接收 RTP 數(shù)據(jù)。適合那些需要二次開發(fā)、想在嵌入式板卡上做私有拉流邏輯的人。我先說結(jié)論這套代碼最值錢的地方不是它能不能拉流而是它把 RTSP 命令交互的完整順序、RTP 接收地址的協(xié)商過程、以及各個狀態(tài)節(jié)點的處理邏輯都攤開放在你面前了。2. 先拆源碼包四個文件的職責(zé)邊界與構(gòu)建順序拿到源碼包不要急著直接編譯。先把四個文件的職責(zé)理清楚后面排錯會省很多時間。這個包的劃分很典型頭文件定義數(shù)據(jù)結(jié)構(gòu)rtsp.c 負(fù)責(zé) RTSP 消息的解析和組裝rtspclient.c 實現(xiàn)命令交互流程testrtsp.c 是測試入口。2.1 rtsp.h數(shù)據(jù)結(jié)構(gòu)和函數(shù)原型的契約層rtsp.h 是整個項目的“接口契約”。你如果編譯時遇到函數(shù)未聲明的報錯第一反應(yīng)應(yīng)該回來檢查這個頭文件是否被正確包含。它里面通常會定義 RTSP 相關(guān)的數(shù)據(jù)結(jié)構(gòu)比如解析后的響應(yīng)信息、RTP 接收端口號、CSeq 序號等。一般常見的定義會包含類似下面的內(nèi)容#define RTSP_DEFAULT_PORT 554 #define RTSP_BUFFER_SIZE 4096 typedef struct { int cseq; int rtp_port; int rtcp_port; char session_id[128]; char server_info[256]; } rtsp_session_t; int rtsp_parse_response(const char *response, rtsp_session_t *session); int rtsp_build_request(char *buffer, int size, const char *method, const char *url, int cseq, const char *extra);邏輯說明rtsp_parse_response負(fù)責(zé)解析服務(wù)器返回的響應(yīng)文本把 CSeq、session_id、端口號等關(guān)鍵信息提取出來。rtsp_build_request用于拼裝客戶端要發(fā)送的請求消息。參數(shù)說明rtsp_buffer_size建議不小于 4096如果服務(wù)器返回的 SDP 較長這個值太小會導(dǎo)致解析截斷。rtp_port和rtcp_port在 SETUP 階段從服務(wù)器響應(yīng)中提取后續(xù)接收 RTP 數(shù)據(jù)時要用。2.2 rtsp.cRTSP 消息的解析與組裝底層rtsp.c 處理的是最底層的文本消息。RTSP 協(xié)議和 HTTP 類似是基于文本的請求行、頭部字段、空行、消息體都有嚴(yán)格的格式約定。代碼里面會包含查找頭字段、解析數(shù)字、復(fù)制字符串這類操作。你可能會在代碼里看到類似strstr定位字段然后做偏移解析的寫法char *p strstr(response, Session:); if (p) { p strlen(Session:); while (*p ) p; sscanf(p, %s, session-session_id); }邏輯說明先在響應(yīng)文本中定位Session:字段跳過可能的空格然后用sscanf提取會話標(biāo)識。類似地server_port字段要從 SETUP 的響應(yīng)中解析通常格式是server_port8000-8001需要分別解析 RTP 和 RTCP 端口。這個文件的調(diào)試價值在于RTSP 服務(wù)器返回的響應(yīng)格式差異很大有的用Session: abc123有的帶timeout參數(shù)有的字段名大小寫不統(tǒng)一。如果發(fā)現(xiàn)某項參數(shù)解析不出來優(yōu)先檢查這里。2.3 rtspclient.c命令狀態(tài)機的核心實現(xiàn)這是整個客戶端最核心的部分負(fù)責(zé)按順序發(fā)送 OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN 這些命令并在每個階段處理服務(wù)器的響應(yīng)。這個文件里面通常會有類似狀態(tài)機的結(jié)構(gòu)或者至少是一連串順序執(zhí)行的函數(shù)調(diào)用。核心代碼邏輯通常長這樣int rtsp_play(const char *url, int *rtp_port) { int sock socket(AF_INET, SOCK_STREAM, 0); // ... 連接服務(wù)器 ... rtsp_build_request(buf, sizeof(buf), OPTIONS, url, 1, NULL); send(sock, buf, strlen(buf), 0); recv(sock, response, sizeof(response), 0); rtsp_build_request(buf, sizeof(buf), DESCRIBE, url, 2, NULL); send(sock, buf, strlen(buf), 0); recv(sock, response, sizeof(response), 0); rtsp_parse_response(response, session); // SETUP 階段協(xié)商端口 // PLAY 階段開始播放 // 然后綁定本地端口接收 RTP 數(shù)據(jù) }邏輯說明socket創(chuàng)建用的是SOCK_STREAM因為 RTSP 命令交互走 TCPRTP 數(shù)據(jù)可以走 UDP 也可以走 TCP當(dāng)前實現(xiàn)一般是 UDP。每次請求的 CSeq 必須遞增從 1 開始。服務(wù)器用這個字段來匹配請求和響應(yīng)。DESCRIBE的響應(yīng)里包含 SDP 信息其中mvideo行的RTP/AVP 96這類參數(shù)標(biāo)明了負(fù)載類型后續(xù)收 RTP 包時要檢查。一個常見的理解誤區(qū)是RTSP 的 PLAY 命令發(fā)出去了視頻就開始傳了。實際上 PLAY 只是通知服務(wù)器開始發(fā)送真正的視頻數(shù)據(jù)走的是 SETUP 階段協(xié)商出來的 RTP 端口和 RTSP 命令的 TCP 連接是分開的。2.4 構(gòu)建順序先跑通 testrtsp.c 驗證鏈路testrtsp.c 是一個典型的測試程序里面大概率包含main函數(shù)入口示例化了拉流的完整流程。建議先用它做驗證確認(rèn)鏈路通了你再去改業(yè)務(wù)邏輯。gcc -o rtsp_test testrtsp.c rtspclient.c rtsp.c -Wall ./rtsp_test rtsp://192.168.1.64:554/stream1編譯參數(shù)說明-Wall打開所有警告這個包是幾年沉淀的老代碼編譯時看到警告不要忽略特別是關(guān)于隱式函數(shù)聲明的警告往往是頭文件包含順序不對。運行時 URL 是完整的 RTSP 地址注意用戶名密碼要用rtsp://user:passip:port/path格式。跑通 testrtsp.c 之后你再去看 rtspclient.c 就會覺得清晰很多因為它本質(zhì)上就是一個被拆成多個函數(shù)的 testrtsp.c。3. 把 RTSP 命令交互跑通OPTIONS 到 PLAY 的完整流程與參數(shù)協(xié)商RTSP 命令交互看起來就是簡單地發(fā)幾個請求、收幾個響應(yīng)但真正涉及線上環(huán)境時細(xì)節(jié)都在參數(shù)協(xié)商里。整個流程是固定的OPTIONS 探路DESCRIBE 獲取媒體描述SETUP 協(xié)商傳輸通道PLAY 觸發(fā)數(shù)據(jù)流最后 TEARDOWN 收尾。3.1 OPTIONS 與 DESCRIBE協(xié)商能力與拿 SDPOPTIONS 是客戶端發(fā)送的第一條命令用來查詢服務(wù)器支持哪些方法。響應(yīng)里會有Public:字段列出服務(wù)器支持的方法例如OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE。這個字段的主要價值不是讓客戶端做判斷而是確認(rèn)當(dāng)前連接的服務(wù)確實支持 RTSP 協(xié)議。DESCRIBE 是真正開始工作的命令。它返回的信息用 SDP 格式組織里面有媒體類型、編碼格式、碼率、分辨率等關(guān)鍵參數(shù)。對于 H.264 編碼的流SDP 里會有類似下面這樣的內(nèi)容mvideo 0 RTP/AVP 96 artpmap:96 H264/90000 acontrol:track1這段 SDP 的意思是視頻軌道使用 RTP 傳輸負(fù)載類型編號是 96編碼格式是 H.264時鐘頻率是 90000Hz控制路徑是track1。后續(xù)的 SETUP 請求要帶上track1這個控制路徑才能正確關(guān)聯(lián)到視頻軌道。實際抓包時會發(fā)現(xiàn)有些服務(wù)器尤其是國產(chǎn) IPC的 SDP 格式并不完全規(guī)范。比如有的在m行用98作為負(fù)載類型有的甚至不寫rtpmap行。遇到這種情況代碼里的解析邏輯就需要有兜底處理。3.2 SETUPTransport 頭的 UDP 端口協(xié)商SETUP 是整個 RTSP 交互中最容易出錯的環(huán)節(jié)因為傳輸參數(shù)在這里協(xié)商。客戶端要發(fā)送的請求頭類似這樣SETUP rtsp://192.168.1.64:554/stream1/track1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP/UDP;unicast;client_port8000-8001這里的client_port8000-8001是客戶端自己選擇的端口8000 用于接收 RTP 數(shù)據(jù)8001 用于接收 RTCP 數(shù)據(jù)。服務(wù)器收到后會在響應(yīng)中告訴客戶端它選擇的服務(wù)器端口Transport: RTP/AVP/UDP;unicast;client_port8000-8001;server_port9000-9001關(guān)鍵邏輯說明客戶端必須先綁定本地端口 8000 和 8001然后才能發(fā)送 SETUP 請求。如果先發(fā) SETUP 再綁定端口會丟失第一批到達的 RTP 數(shù)據(jù)。server_port9000-9001是服務(wù)器發(fā)送 RTP 數(shù)據(jù)的源端口通常用于后續(xù)的 RTCP 收發(fā)和 NAT 穿透判斷但接收 RTP 數(shù)據(jù)本身只依賴于客戶端綁定的 8000 端口。部分服務(wù)器要求Transport頭中攜帶moderecord或者modeplay參數(shù)如果缺少可能導(dǎo)致 461 錯誤。這塊代碼寫的時候最容易忽略的就是端口綁定的時機。很多人的第一次失敗經(jīng)歷是SETUP 發(fā)出的client_port是 8000但本地根本沒有 bind 這個端口。RTP 數(shù)據(jù)發(fā)過來時系統(tǒng)直接返回 ICMP 端口不可達表現(xiàn)在現(xiàn)象上就是命令交互全部成功但就是收不到數(shù)據(jù)。3.3 PLAY 與 TEARDOWN狀態(tài)推進與資源釋放PLAY 命令觸發(fā)服務(wù)器開始發(fā)送媒體流。它的請求頭相對簡單PLAY rtsp://192.168.1.64:554/stream1 RTSP/1.0 CSeq: 4 Session: abc123 Range: npt0.000-注意 Session 字段必須使用 SETUP 響應(yīng)中返回的會話標(biāo)識很多服務(wù)器要求這個字段和 SETUP 階段的一致否則返回 454 Session Not Found。TEARDOWN 的目的是釋放服務(wù)器資源。嵌入式設(shè)備的內(nèi)存有限如果客戶端異常退出但沒發(fā) TEARDOWN服務(wù)器上的會話會一直掛著直到超時。所以如果你的程序有信號處理邏輯在 SIGINT 或 SIGTERM 的 handler 里先發(fā) TEARDOWN 再退出這是應(yīng)有的技能儲備。3.4 一個最小可運行的測試序列用命令行的方式也可以模擬 RTSP 交互流程這樣可以驗證服務(wù)器端的連通性# 以 VLC 為例直接請求流地址后加 --rtsp-tcp 強制走 TCP vlc -v --rtsp-tcp rtsp://192.168.1.64:554/stream1 # 用 ffprobe 查看流信息確認(rèn)編碼格式 ffprobe -rtsp_transport tcp rtsp://192.168.1.64:554/stream1命令邏輯說明--rtsp-tcp和-rtsp_transport tcp都表示用 TCP 傳輸 RTP 數(shù)據(jù)。默認(rèn)是 UDP兩種模式對應(yīng)接收 RTP 數(shù)據(jù)的底層協(xié)議不同。如果你的客戶端只實現(xiàn)了 UDP 模式但實際網(wǎng)絡(luò)環(huán)境禁用了 UDP就會出現(xiàn)命令交互正常但收不到數(shù)據(jù)的問題。我建議你至少用 VLC 驗證一次服務(wù)器端的流是否正常再用 ffprobe 獲取流的基本信息。這能把問題范圍縮小如果 ffprobe 能拿到流信息但你的客戶端拿不到問題大概率出在代碼邏輯而不是服務(wù)器配置上。4. 避坑實踐RTSP 客戶端調(diào)試中常見的問題、現(xiàn)象、原因與解法這部分內(nèi)容來自實際調(diào)試中的經(jīng)驗積累。我也看過不少類似的 RTSP 客戶端代碼發(fā)現(xiàn)問題點高度一致尤其是都在下面幾個位置。每一條都是實際遇到過的格式統(tǒng)一為現(xiàn)象、原因、解決。4.1 現(xiàn)象SETUP 成功后收不到 RTP 數(shù)據(jù)現(xiàn)象DESCRIBE、SETUP 都返回 200 OKPLAY 也發(fā)出去了但 recvfrom 一直阻塞收不到任何 UDP 數(shù)據(jù)。原因最常見的兩個原因。第一是本地沒有提前 bind UDP 端口RTP 數(shù)據(jù)到達時找不到對應(yīng)端口而丟棄。第二是代碼里解析服務(wù)器響應(yīng)時把server_port和client_port搞混了綁定到了錯誤的地址。解決在發(fā)送 SETUP 之前就創(chuàng)建 UDP socket 并 bind 到自選的 client_port 上例如bind(sock, (struct sockaddr *)addr, sizeof(addr))其中addr.sin_port htons(8000)。然后用真實的抓包結(jié)果對比 SETUP 請求中聲明的端口和本地綁定端口是否一致。4.2 現(xiàn)象第二次連接總是失敗現(xiàn)象程序第一次拉流一切正常殺掉進程重啟后第一次連接也正常但是程序內(nèi)部做二次連接時SETUP 階段返回錯誤或者數(shù)據(jù)流接收異常。原因RTP socket 綁定端口后沒有被正確關(guān)閉導(dǎo)致端口被占用。Linux 下 UDP socket 默認(rèn)不啟用SO_REUSEADDR端口處于 TIME_WAIT 狀態(tài)時無法再次綁定。除此之外也可能是因為上一次會話沒有發(fā) TEARDOWN服務(wù)器端的會話沒有釋放后續(xù) SETUP 請求到達時服務(wù)器返回 455 Method Not Valid In This State。解決在所有斷開路徑上釋放資源。socket 用 close 關(guān)閉同時調(diào)用rtsp_send_request(TEARDOWN)通知服務(wù)器清理會話。如果你不發(fā)送 TEARDOWN就需要等待服務(wù)器端的會話超時這個時間通常是 60 秒左右你會在 60 秒時間內(nèi)不斷重試失敗。4.3 現(xiàn)象播放幾分鐘后卡死沒有任何報錯現(xiàn)象程序運行正常視頻播放流暢但運行 3 到 5 分鐘之后接收線程突然卡住CPU 占用 100%或者沒有任何數(shù)據(jù)輸出。原因這通常是因為 recvfrom 默認(rèn)是阻塞模式?jīng)]有設(shè)置超時時間。當(dāng)網(wǎng)絡(luò)抖動或服務(wù)器暫緩發(fā)送時線程會一直阻塞在 recvfrom 上。如果此時主線程等待這個接收線程的結(jié)果就會出現(xiàn)整個程序卡死。更嚴(yán)重的是如果 RTP 序列號發(fā)生跳變代碼里的數(shù)據(jù)重組邏輯進入死循環(huán)。解決給接收 socket 設(shè)置超時時間用setsockopt配合SO_RCVTIMEOstruct timeval tv; tv.tv_sec 3; tv.tv_usec 0; setsockopt(rtp_sock, SOL_SOCKET, SO_RCVTIMEO, tv, sizeof(tv));參數(shù)說明超時設(shè)為 3 秒recvfrom 如果 3 秒內(nèi)沒有數(shù)據(jù)會返回 -1errno 置為EAGAIN或EWOULDBLOCK。外層循環(huán)依據(jù)這個錯誤碼判斷是繼續(xù)等還是走重連邏輯。不要設(shè)置為 0永不超時除非你的重連邏輯完全不依賴接收線程的反饋。在 RTP 時間戳重組邏輯里加上序列號跳變檢測如果seq差值大于一個閾值比如 1000直接對齊到新的序列號而不是等待補齊。4.4 現(xiàn)象DESCRIBE 響應(yīng)里的 SDP 解析不完整現(xiàn)象打印解析后的 SDP 內(nèi)容時發(fā)現(xiàn)只有前三行或者m行后面的屬性丟失。用 VLC 拉同一個地址卻是正常的。原因rtsp.c 里的響應(yīng)緩沖區(qū)長度不夠。有些服務(wù)器的 DESCRIBE 響應(yīng)可能長達幾 KB如果緩沖區(qū)只有 1024 字節(jié)數(shù)據(jù)被截斷。另一個常見的原因是接收時只調(diào)用了一次 recv但一次 recv 并沒有拿完所有數(shù)據(jù)。TCP 是流式協(xié)議一次 recv 不能保證拿到完整的應(yīng)用層消息。解決接收并檢查是否到達消息邊界。沒有 Content-Length 時以空行\(zhòng)r\n\r\n作為頭部結(jié)束標(biāo)志有 Content-Length 時按長度接收完整個消息體。緩沖區(qū)建議按RTSP_BUFFER_SIZE配置在 8KB 以上。int total 0; while (total content_length) { int n recv(sock, buf total, sizeof(buf) - total, 0); if (n 0) break; total n; }這段循環(huán)的邏輯很直白沒湊夠 Content-Length 就繼續(xù) recv直到數(shù)據(jù)完整。4.5 現(xiàn)象啟動時綁定端口失敗顯示 Address already in use現(xiàn)象每次啟動程序都要等待幾秒鐘或者直接報bind: Address already in use換一個端口就好了。原因上一次運行沒有干凈地關(guān)閉 UDP socket端口被內(nèi)核占用。雖然程序退出后 socket 會自動關(guān)閉但如果沒有設(shè)置SO_REUSEADDR偶爾會碰到端口被占用的情況特別是快速重啟的場景。解決在 bind 之前設(shè)置 set reuse 屬性int reuse 1; setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, reuse, sizeof(reuse));這樣即使 socket 處于 TIME_WAIT 狀態(tài)也能在同一端口重新綁定。如果你是在做服務(wù)端開發(fā)一般會建議開啟SO_REUSEPORT但作為 RTSP 客戶端SO_REUSEADDR已經(jīng)完全夠用。5. 進階技巧用 RTP 載荷類型校驗實現(xiàn)弱網(wǎng)情況下的故障定位把 demo 變成能上線的客戶端testrtsp.c 能跑通只能證明你的代碼和服務(wù)器之間建立了正確的溝通方式。但從能跑到穩(wěn)定運行之間還差一個關(guān)鍵檢測手段對 RTP 數(shù)據(jù)包的載荷類型和序列號進行校驗。這能幫助你快速判斷問題是出在網(wǎng)絡(luò)丟包、編碼器異常、還是服務(wù)器負(fù)載過高導(dǎo)致的發(fā)送端丟幀。5.1 RTP 頭解析與負(fù)載類型校驗RTP 頭的長度固定為 12 字節(jié)結(jié)構(gòu)是固定的。你可以在接收循環(huán)中解析出每個包的負(fù)載類型和序列號unsigned char *rtp_packet buffer; int payload_type rtp_packet[1] 0x7F; unsigned short seq (rtp_packet[2] 8) | rtp_packet[3]; if (payload_type ! expected_pt) { printf(Payload type mismatch: expected %d, got %d\n, expected_pt, payload_type); }邏輯說明rtp_packet[1]的高字節(jié)是標(biāo)記位低 7 位是負(fù)載類型所以要與 0x7F 做與運算。SDP 里常見RTP/AVP 96這里的96就是負(fù)載類型和payload_type一一對應(yīng)。序列號由第 2、3 字節(jié)組成大端序存儲。如果你發(fā)現(xiàn)序列號跳變超過一定范圍說明中間發(fā)生了丟包。在實際項目里我一般會把接收循環(huán)設(shè)計成帶狀態(tài)輸出的形式static int last_seq -1; int gap (last_seq 0) ? (seq - last_seq) : 1; if (gap 1 last_seq 0) { printf(Packet loss detected: %d packets lost (seq %d - %d)\n, gap - 1, last_seq, seq); // 在這里可以觸發(fā)重連或上報異常 } last_seq seq;這種實現(xiàn)的價值在于它讓“視頻卡了”從一個模糊的感覺變成了一個可量化的證據(jù)鏈。當(dāng)現(xiàn)場反饋“視頻花屏、卡頓”時你可以直接看打印的丟包統(tǒng)計判斷是網(wǎng)絡(luò)鏈路的問題還是對端設(shè)備編碼器的問題。5.2 斷線重連機制的設(shè)計TCP 連接長時間沒有數(shù)據(jù)接收可能已經(jīng)被對端靜默關(guān)閉。當(dāng)你的接收循環(huán)碰到recvfrom返回ETIMEDOUT或ECONNRESET時嘗試恢復(fù)連接會比等待下一次正常收到數(shù)據(jù)更可靠。常見做法是三層恢復(fù)機制層次觸發(fā)條件處理方式第一層recv 超時一次發(fā)起 RTSP OPTIONS 探測確認(rèn)連接是否活著第二層連續(xù) 3 次探測失敗主動斷開釋放所有資源回到初始狀態(tài)第三層重連超過 3 次提升日志級別輪詢等待下一次重試間隔 10 秒重連時最容易犯的錯誤是在舊 socket 沒有關(guān)閉的情況下直接創(chuàng)建新連接。一定要先把 TCP socket、UDP socket 全部關(guān)閉再走一次完整的 OPTIONS - DESCRIBE - SETUP - PLAY 流程。這個邏輯放在獨立的線程里跑不要阻塞主業(yè)務(wù)線程。5.3 從 testrtsp.c 到生產(chǎn)代碼的改造清單testrtsp.c 是一個線性執(zhí)行的示例生產(chǎn)環(huán)境需要加的內(nèi)容包括SDP 解析器增強自動識別多軌流視頻音頻為每個軌道建立獨立的 SETUP 會話。當(dāng)前代碼只處理單路視頻軌遇到多軌流時需要擴展。RTP 接收線程獨立播放命令發(fā)出后RTP 數(shù)據(jù)的接收不能占用命令發(fā)送線程。用 pthread 創(chuàng)建獨立的接收線程并使用環(huán)形緩沖區(qū)緩存數(shù)據(jù)。超時與錯誤統(tǒng)計維護一個狀態(tài)結(jié)構(gòu)體記錄重連次數(shù)、累計丟包數(shù)、最近一次錯誤碼。這個結(jié)構(gòu)體既用于調(diào)試也用于上報到業(yè)務(wù)層做告警。內(nèi)存管理檢查RTSP 響應(yīng)解析過程中如果用了malloc確保所有路徑上都有對應(yīng)的free包括出錯跳轉(zhuǎn)的路徑。這套代碼我實際用下來在嵌入式 Linux 板卡上拉?？?、大華的 RTSP 流都沒有問題但也因為碰過上面說的幾個坑所以后面每次集成新的平臺都會先按這個順序做一輪驗證先跑通命令交互再校驗 RTP 接收最后才進業(yè)務(wù)邏輯。希望這些經(jīng)驗?zāi)軒偷侥阒辽倌茏屇闵僮邘讉€我之前走過的彎路。本文還有配套的精品資源點擊獲取