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