簡介這是一份RTSP服務(wù)器C語言實(shí)現(xiàn)源碼及配套分析資料適合網(wǎng)絡(luò)編程初學(xué)者、流媒體開發(fā)者以及希望深入理解RTSP協(xié)議原理的工程師。資源共包含414個(gè)文件以167個(gè)C源碼文件、45個(gè)頭文件為主輔以Makefile、編譯生成的庫文件與目標(biāo)文件等整體約1.26MB結(jié)構(gòu)緊湊便于對照學(xué)習(xí)協(xié)議實(shí)現(xiàn)與工程組織。目前已有1059人瀏覽學(xué)習(xí)。資料完整梳理了RTSP基礎(chǔ)、會話管理、請求處理、RTP/RTCP傳輸及多線程同步等關(guān)鍵模塊配合源碼注釋可幫助讀者掌握服務(wù)器初始化、DESCRIBE/SETUP/PLAY等請求流程并理解SDP生成與狀態(tài)機(jī)管理思路適合作為網(wǎng)絡(luò)服務(wù)開發(fā)的實(shí)戰(zhàn)參考。 接觸過音視頻傳輸?shù)呐笥褢?yīng)該對RTSP不陌生。這個(gè)協(xié)議從誕生到現(xiàn)在一直是IP攝像頭、流媒體服務(wù)器、安防平臺這些領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。我之前因?yàn)轫?xiàng)目需要在嵌入式板子上用C語言從頭寫過一版RTSP服務(wù)器也仔細(xì)讀過live555、GStreamer里rtspbin的實(shí)現(xiàn)思路這里把源碼層面的關(guān)鍵設(shè)計(jì)、協(xié)議狀態(tài)機(jī)的處理、還有那些文檔里不會寫的坑一次性講清楚。這篇文章適合正在看RTSP相關(guān)源碼的人也適合準(zhǔn)備自己動手實(shí)現(xiàn)一個(gè)輕量級RTSP服務(wù)的開發(fā)者。1. RTSP協(xié)議核心源碼落地前必須搞懂的三個(gè)概念RTSPReal Time Streaming Protocol本身并不傳輸媒體數(shù)據(jù)它更像是一個(gè)“流媒體會話的遙控器”。源碼里所有邏輯歸根結(jié)底都圍繞三個(gè)概念展開URL會話管理、狀態(tài)機(jī)流轉(zhuǎn)、SDP媒體協(xié)商。不管你讀的是live555還是自己寫的代碼這三個(gè)點(diǎn)貫穿始終。1.1 URL定位與會話管理RTSP的請求行長這樣DESCRIBE rtsp://192.168.1.10:554/live/ch01 RTSP/1.0。這個(gè)URL不是隨便寫的它在源碼里會被解析成兩部分服務(wù)器IP和端口以及媒體路徑。比如/live/ch01可能對應(yīng)一個(gè)H.264攝像頭通道也可能對應(yīng)一個(gè)本地文件。在C語言實(shí)現(xiàn)里常見做法是用一個(gè)結(jié)構(gòu)體維護(hù)會話列表。參考live555的ServerMediaSession它本質(zhì)是一個(gè)雙向鏈表節(jié)點(diǎn)字段大概有sessionId服務(wù)端生成的唯一標(biāo)識客戶端后續(xù)請求都帶著它媒體路徑streamName對應(yīng)URL里的路徑部分傳輸模式TCP還是UDP單播還是組播SDP描述指針等DESCRIBE請求來了直接序列化返回引用計(jì)數(shù)多個(gè)客戶端看同一路流時(shí)基礎(chǔ)流對象會被共享源碼里比較關(guān)鍵的是sessionId的生成策略。并發(fā)高的時(shí)候遞增數(shù)字很容易撞車我一般用時(shí)間戳加隨機(jī)數(shù)拼一個(gè)十六進(jìn)制字符串再加一個(gè)全局自增序列做保底這樣既不會重復(fù)也方便日志里排查是哪一路會話。live555里用的是隨機(jī)數(shù)加地址組合效果類似。1.2 狀態(tài)機(jī)每個(gè)請求都在推動狀態(tài)流轉(zhuǎn)RTSP的狀態(tài)機(jī)看起來簡單但源碼里容易寫得特別散因?yàn)槊總€(gè)方法OPTIONS、DESCRIBE、SETUP、PLAY等都在改狀態(tài)。最核心的流轉(zhuǎn)路徑是初始化客戶端發(fā)OPTIONS探路服務(wù)器回支持哪些方法DESCRIBE服務(wù)器返回SDP描述媒體格式、編碼、端口信息SETUP指定傳輸方式TCP/UDP服務(wù)器分配RTP/RTCP端口建立傳輸通道PLAY開始推流服務(wù)器按幀率往客戶端發(fā)RTP包PAUSE/TEARDOWN暫?；蚪K止會話釋放資源源碼實(shí)現(xiàn)時(shí)我習(xí)慣用一個(gè)枚舉狀態(tài)變量每次方法處理完直接更新狀態(tài)比如typedef enum { RTSP_STATE_INIT, RTSP_STATE_READY, RTSP_STATE_PLAYING, RTSP_STATE_PAUSING } RtspState;SETUP成功后才能PLAYPLAY狀態(tài)下再收到SETUP要考慮返回455 Method Not Valid In This State這是RFC 2326里明確規(guī)定的。很多新手寫的代碼沒做狀態(tài)校驗(yàn)順序亂了也不報(bào)錯(cuò)結(jié)果客戶端表現(xiàn)時(shí)好時(shí)壞其實(shí)就是狀態(tài)機(jī)沒管住。1.3 SDP媒體能力的“簡歷”SDPSession Description Protocol是RTSP和媒體之間的一座橋。服務(wù)器支持什么編碼、什么分辨率、什么采樣率全都在SDP里寫明白。DESCRIBE請求的響應(yīng)體就是一段文本SDP客戶端解析它來決定怎么解碼、怎么渲染。C源碼里SDP通常不是運(yùn)行時(shí)動態(tài)生成的而是根據(jù)媒體源信息拼出來的。常見字段包括v0版本o 會話標(biāo)識s 會話名稱cIN IP4 192.168.1.10連接信息多播場景必填t0 0活動時(shí)間mvideo 0 RTP/AVP 96視頻軌道端口0表示跟隨SETUP協(xié)商artpmap:96 H264/90000編碼格式和時(shí)鐘頻率afmtp:96 packetization-mode1H.264打包參數(shù)acontrol:trackID1該軌道的控制URL一個(gè)容易被忽略的細(xì)節(jié)是acontrol字段。如果客戶端發(fā)來的SETUP是rtsp://ip/live/ch01/trackID1服務(wù)器要能從URL里解析出trackID再映射到具體的媒體子會話。C語言里用strstr或者sscanf提取即可但要注意邊界避免讀到越界內(nèi)存。2. 源碼框架拆解目錄結(jié)構(gòu)與線程模型設(shè)計(jì)拿到一份RTSP服務(wù)器源碼第一件事不是讀代碼是看目錄結(jié)構(gòu)和線程模型。這決定了整個(gè)項(xiàng)目的復(fù)雜度走向也直接關(guān)系到你后續(xù)加功能的時(shí)候是游刃有余還是焦頭爛額。2.1 一個(gè)可維護(hù)的目錄結(jié)構(gòu)長什么樣我參考過一個(gè)輕量級RTSP服務(wù)器的開源項(xiàng)目它的目錄劃分很清晰直接抄過來就很順手rtsp_server/ ├── include/ // 公共頭文件協(xié)議定義、數(shù)據(jù)結(jié)構(gòu) │ ├── rtsp.h // RTSP請求/響應(yīng)的核心結(jié)構(gòu)體定義 │ ├── rtsp_server.h // 服務(wù)器主接口 │ └── rtp.h // RTP打包相關(guān)接口 ├── src/ │ ├── rtsp.c // 請求解析、方法分發(fā)、狀態(tài)機(jī) │ ├── rtp_h264.c // H.264負(fù)載打包、時(shí)間戳處理 │ ├── sdp.c // SDP構(gòu)建 │ ├── session.c // 會話管理 │ └── main.c // 啟動入口 ├── Makefile └── README.md如果你讀的源碼把請求解析、SDP生成、RTP打包全部塞進(jìn)一個(gè)幾千行的rtsp.c里那后期維護(hù)會非常痛苦。我的習(xí)慣是每個(gè)源文件只專注一件事頭文件里只暴露必要的接口內(nèi)部實(shí)現(xiàn)全用static函數(shù)隱藏起來。這樣別人讀你的代碼或者你自己一個(gè)月后回來看都不至于一臉懵。2.2 線程模型單線程還是多線程RTSP服務(wù)器的并發(fā)模型基本兩類每連接一線程簡單來一個(gè)客戶端創(chuàng)建一個(gè)線程會話結(jié)束就回收單線程事件循環(huán)用select/poll/epoll管理所有socket非阻塞處理我之前在嵌入式平臺上用過一個(gè)線程池模型思路是主線程負(fù)責(zé)accept然后把連接描述符丟進(jìn)一個(gè)隊(duì)列工作線程從隊(duì)列取任務(wù)。這樣避免了高頻創(chuàng)建銷毀線程的開銷也能控制最大并發(fā)數(shù)。實(shí)際測試下來在不支持epoll的老式Linux內(nèi)核上用poll加線程池也能輕松支撐二三十路并發(fā)對大多數(shù)安防場景完全夠用。RTP推流這部分我建議單獨(dú)一個(gè)線程去干不要和RTSP控制請求混在一起。因?yàn)镽TP是定時(shí)發(fā)送高頻操作如果和控制請求共享線程一個(gè)慢客戶端或者網(wǎng)絡(luò)抖動可能導(dǎo)致后續(xù)所有請求都堵住。分離之后控制會話和媒體發(fā)送互不干擾。源碼里通常是一個(gè)會話對應(yīng)一個(gè)RTP發(fā)送緩沖區(qū)和獨(dú)立線程或者多個(gè)會話共用一個(gè)發(fā)送線程通過定時(shí)器輪詢就緒的幀。2.3 socket初始化源碼里你一定會遇到的幾組調(diào)用服務(wù)器啟動的第一步就是創(chuàng)建監(jiān)聽socket。代碼看起來差不多但有幾個(gè)參數(shù)值得留意int listen_fd socket(AF_INET, SOCK_STREAM, 0); int reuse 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, reuse, sizeof(reuse)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(server_port); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 64);SO_REUSEADDR這個(gè)選項(xiàng)是必須的。否則服務(wù)重啟時(shí)上一次還沒完全釋放的四元組會導(dǎo)致bind失敗報(bào)Address already in use排查起來很坑。mei錯(cuò)就是那種你明明kill了進(jìn)程端口還是被占用的詭異問題。需要I/O多路復(fù)用的時(shí)候用epoll還是select取決于平臺。Linux下優(yōu)先epoll沒有的話退回到select。C源碼里這一層最好封裝一下做一個(gè)事件驅(qū)動的統(tǒng)一接口底層用宏區(qū)分平臺這樣代碼跨平臺遷移的時(shí)候不用改上層邏輯。3. 核心模塊的實(shí)現(xiàn)細(xì)節(jié)與關(guān)鍵代碼解讀這一步是源碼分析的重頭戲。很多初學(xué)者看RTSP源碼會卡在RTP打包這一塊覺得位操作太多、晦澀難懂。實(shí)際上RTP打包是有規(guī)律可循的理解了一路打包的邏輯其他編碼格式只需要改負(fù)載類型和分片策略。3.1 解析RTSP請求字符串處理要穩(wěn)準(zhǔn)狠RTSP請求是文本協(xié)議按行分隔。第一行是請求行C源碼里解析的過程其實(shí)就是按\r\n切分然后按空格拆出方法、URL、版本號。我見過最穩(wěn)妥的實(shí)現(xiàn)是用循環(huán)加指針移動的方式逐字符掃描內(nèi)存而不是依賴strtok因?yàn)閟trtok會修改原字符串而且不可重入。解析的偽代碼思路// 讀取一行的數(shù)據(jù)不含換行符存入line // 用sscanf(line, %s %s %s, method, url, version) 提取三要素 // 然后循環(huán)讀取Header按冒號分割key和value // 直到遇到空行整個(gè)Header解析結(jié)束 // 如果有Body繼續(xù)按Content-Length讀取關(guān)鍵點(diǎn)是Content-Length很多RTSP請求尤其ANNOUNCE或者帶SDP的請求會帶body如果只按行讀漏了body會導(dǎo)致請求不完整。讀取時(shí)要注意處理粘包一個(gè)TCP包可能包含多個(gè)RTSP請求用正則或者循環(huán)把數(shù)據(jù)全讀完才能走下一個(gè)。Header解析完后C源碼里通常用一個(gè)函數(shù)指針表來分發(fā)方法typedef int (*rtsp_handler)(RtspContext *ctx); static const struct { const char *method; rtsp_handler handler; } handlers[] { {OPTIONS, handle_options}, {DESCRIBE, handle_describe}, {SETUP, handle_setup}, {PLAY, handle_play}, {PAUSE, handle_pause}, {TEARDOWN, handle_teardown}, {GET_PARAMETER, handle_get_parameter}, };查表分發(fā)的好處是加新方法只需要注冊一個(gè)函數(shù)不需要改一大串if else。源碼的可維護(hù)性就是這么一點(diǎn)點(diǎn)摳出來的。3.2 SETUP處理與RTP端口分配SETUP是RTSP交互中最核心的一步?？蛻舳藭l(fā)來類似這樣的請求頭Transport: RTP/AVP;unicast;client_port6970-6971這表示客戶端期望用UDP方式接收RTP接收端口是6970RTCP端口是6971。服務(wù)器需要解析出這條Transport然后做兩件事第一決策傳輸模式。如果服務(wù)器支持UDP就直接用客戶端指定的端口往目標(biāo)IP發(fā)RTP包。如果不支持UDP或者網(wǎng)絡(luò)環(huán)境不允許比如經(jīng)過NAT就要200響應(yīng)里返回Transport: RTP/AVP;unicast;client_port6970-6971;server_port8000-8001告知服務(wù)器對應(yīng)的RTP和RTCP端口。第二如果有多個(gè)track比如一個(gè)視頻軌一個(gè)音頻軌每個(gè)track需要獨(dú)立SETUP。服務(wù)器這邊要為每個(gè)track分配獨(dú)立的RTP會話session id相同但track id不同端口對各自獨(dú)立。這塊在C代碼里有一個(gè)隱蔽bug的高發(fā)點(diǎn)socket的創(chuàng)建時(shí)機(jī)。很多新手會在SETUP階段才去創(chuàng)建RTP sockets這沒問題但要考慮失敗的情況。如果UDP端口綁定失敗整個(gè)SETUP應(yīng)該返回錯(cuò)誤響應(yīng)而不是讓客戶端以為成功了然后收不到包。我習(xí)慣把socket創(chuàng)建和綁定的結(jié)果作為SETUP成功的前置條件任何一個(gè)失敗直接返回500 Internal Server Error。3.3 RTP打包時(shí)間戳和序列號是靈魂RTP頭有12字節(jié)固定部分其中兩個(gè)字段至關(guān)重要sequence number和timestamp。sequence number每個(gè)RTP包加1用于檢測丟包和亂序timestamp由采樣時(shí)鐘驅(qū)動用于接收端正確播放節(jié)奏對H.264來說timestamp的遞增單位是90000。為什么是90000因?yàn)镽TP對視頻的默認(rèn)時(shí)鐘頻率是90kHz一秒鐘有90000個(gè)時(shí)鐘周期。假設(shè)視頻幀率是25fps那每幀的時(shí)間戳增量就是90000 / 25 3600。這個(gè)計(jì)算一定要準(zhǔn)確否則客戶端播放會出現(xiàn)快放、慢放或者音畫不同步?？匆欢螛?biāo)準(zhǔn)的時(shí)間戳遞增代碼uint32_t rtp_timestamp 0; uint32_t ts_increment 90000 / fps; // 例如 90000/25 3600 while (frames_remain) { // 讀取一幀H.264數(shù)據(jù) // 打包成一個(gè)或多個(gè)RTP包 rtp_timestamp ts_increment; }如果視頻源是VFR可變幀率就不能簡單按固定增量算要基于解碼時(shí)間戳PTS/DTS來換算。C源碼里一般會傳一個(gè)pts值進(jìn)來rtp_timestamp pts * 90000 / 1000000其中pts單位是微秒。3.4 H.264分包NALU太大怎么塞進(jìn)MTU一幀H.264的裸數(shù)據(jù)可能幾百KB但RTP包最大也就是以太網(wǎng)MTU減掉IP頭和UDP頭之后的大小約1400字節(jié)。所以源碼里必須做分片。H.264 RTP打包有三種模式單NALU模式NALU小于MTU直接加12字節(jié)RTP頭然后填NALU內(nèi)容FU-A分片NALU太大拆成多個(gè)分片每個(gè)分片用FU indicator和FU header標(biāo)記STAP-A聚合多個(gè)小的NALU合到一個(gè)RTP包里源碼里最常實(shí)現(xiàn)的是FU-A分片。分片的邏輯可以用下面這個(gè)流程概括。NALU的第一個(gè)字節(jié)包含三部分NRI前三位、Type后五位。對于H.264type取值1-23是普通NALU24-27是聚合包和分片包的標(biāo)志28就是FU-A。處理FU-A時(shí)要生成兩個(gè)新的字節(jié)FU indicator (NALU頭的高3位保留) | 28表示這是分片F(xiàn)U header 1起始位S 0結(jié)束位E NALU type的低5位起始分片的FU header的S位置1結(jié)束分片的E位置1中間的S和E都為0。C代碼里一個(gè)簡單的分片循環(huán)長這樣int fu_payload_size 1400 - 2 - 12; // RTP頭12字節(jié) FU indicator/FU header 2字節(jié) uint8_t *rtp_payload rtp_packet RTP_HEADER_LEN; rtp_payload[0] (nalu[0] 0xE0) | 28; // FU indicator rtp_payload[1] nalu[0] 0x1F; // FU header先不加S/E int offset 1; while (remaining fu_payload_size) { rtp_payload[1] ~0x80; // 清除S位 rtp_payload[1] ~0x40; // 清除E位 if (offset 1) rtp_payload[1] | 0x80; // 第一個(gè)分片S位置1 memcpy(rtp_payload 2, nalu offset, fu_payload_size); // 填充RTP頭發(fā)送 offset fu_payload_size; remaining - fu_payload_size; } // 最后一個(gè)分片 rtp_payload[1] | 0x40; // E位置1 memcpy(rtp_payload 2, nalu offset, remaining);這個(gè)位運(yùn)算的邏輯不復(fù)雜但極其容易寫錯(cuò)。我的經(jīng)驗(yàn)是先把FU header的值打印出來對照Wireshark看一遍確認(rèn)S和E位是否正確再做大批量數(shù)據(jù)傳輸測試。否則調(diào)試的時(shí)候丟包斷流排查到懷疑人生。3.5 會話資源釋放源碼里最容易泄漏的地方C語言項(xiàng)目逃不開的話題就是資源管理。RTSP服務(wù)器的會話生命周期里涉及到的資源包括socket fd、RTP打包緩沖區(qū)、UDP端口、文件句柄如果讀文件推流、線程句柄。很多源碼會在TEARDOWN時(shí)只關(guān)閉socket忘了釋放RTP發(fā)送緩沖區(qū)和端口。更隱蔽的是客戶端直接斷網(wǎng)服務(wù)器遲遲收不到TEARDOWN會話就一直掛著。所以源碼里必須有一個(gè)超時(shí)機(jī)制比如最近一次RTSP請求超過60秒則自動清理會話。我一般在會話結(jié)構(gòu)體里維護(hù)一個(gè)last_active時(shí)間戳每次收到合法請求就更新啟動一個(gè)后臺清理線程定時(shí)掃描。4. 內(nèi)存與性能優(yōu)化C語言實(shí)現(xiàn)里的幾個(gè)關(guān)鍵取舍服務(wù)端如果跑在嵌入式設(shè)備上CPU和內(nèi)存都有嚴(yán)格限制RTSP服務(wù)器的源碼質(zhì)量直接決定它能不能扛住實(shí)際壓力。這塊我踩過不少坑也做過很多性能調(diào)優(yōu)挑幾個(gè)最有價(jià)值的點(diǎn)分享。4.1 零拷貝地使用發(fā)送緩沖區(qū)一次RTP發(fā)送過程中數(shù)據(jù)從H.264裸數(shù)據(jù)到最終發(fā)送的完整RTP包中間會經(jīng)過多次內(nèi)存拷貝。每拷貝一次就浪費(fèi)一次帶寬和CPU。優(yōu)化思路是在棧上分配一個(gè)固定的發(fā)送緩沖區(qū)把RTP頭先填好然后把NALU的分片直接拷貝到緩沖區(qū)對應(yīng)位置一次sendto搞定。不需要額外malloc也減少了內(nèi)存碎片。示例代碼uint8_t send_buf[1500]; uint8_t *rtp_header send_buf; // 填充RTP頭 rtp_header[0] 0x80; // version 2 rtp_header[1] 0x60 | (payload_type 0x7F); // marker PT rtp_header[2] (seq 8) 0xFF; rtp_header[3] seq 0xFF; // ... uint8_t *payload send_buf RTP_HEADER_LEN; payload[0] fu_indicator; payload[1] fu_header; memcpy(payload 2, nalu_data offset, payload_len); sendto(rtp_sock, send_buf, RTP_HEADER_LEN payload_len, 0, (struct sockaddr *)client_addr, sock_len);這個(gè)方案實(shí)測在低端ARM板子上CPU占用率比每包malloc低三成以上。而且send_buf在棧上分配不會產(chǎn)生堆碎片長時(shí)間運(yùn)行更穩(wěn)定。4.2 環(huán)形緩沖區(qū)平滑B幀突發(fā)流量視頻編碼器輸出不是均勻的一個(gè)GOP里關(guān)鍵幀I幀可能瞬間產(chǎn)生幾十KB的數(shù)據(jù)而普通P幀只有幾KB。如果網(wǎng)絡(luò)發(fā)送速度跟不上就需要一個(gè)緩沖區(qū)把數(shù)據(jù)先存起來慢慢發(fā)。我常用的方案是環(huán)形緩沖區(qū)ring buffer。發(fā)送線程往里寫RTP發(fā)送線程從里面取讀寫指針加鎖或者用原子操作控制。緩沖區(qū)大小按最大關(guān)鍵幀的兩到三倍預(yù)留保證峰值不丟幀。C源碼實(shí)現(xiàn)可以把緩沖區(qū)設(shè)計(jì)成定長數(shù)組加讀寫索引避免頻繁malloc導(dǎo)致性能抖動。需要注意的地方是環(huán)形緩沖滿的時(shí)候策略怎么定。丟棄新幀還是丟棄舊幀RTSP推流場景我傾向于丟棄還未發(fā)送的舊幀因?yàn)橐曨l流對實(shí)時(shí)性要求高發(fā)遲了的幀到了客戶端也來不及解碼渲染不如直接丟掉客戶端頂多卡一下解碼器能自己恢復(fù)。4.3 多路復(fù)用的高并發(fā)策略多路攝像頭接入時(shí)RTSP服務(wù)器要同時(shí)管理多個(gè)會話每個(gè)會話有自己的socket和RTP狀態(tài)。最早我寫的版本是每會話一個(gè)線程接到4路8路沒問題但到16路以上線程切換開銷就很明顯了。后來改成基于epoll的事件循環(huán)主循環(huán)統(tǒng)一管理所有RTSP控制socket的可讀事件再按會話ID分發(fā)到對應(yīng)的處理函數(shù)。RTP發(fā)送這塊保留一個(gè)獨(dú)立的發(fā)送線程池負(fù)責(zé)所有會話的媒體數(shù)據(jù)發(fā)送。實(shí)測下來16路并發(fā)CPU占用比純線程模型低了將近40%。如果你的源碼還不支持epoll調(diào)試的時(shí)候建議先用poll因?yàn)閜oll跨平臺性更好邏輯也清晰。先把功能跑通再考慮性能優(yōu)化。5. 實(shí)際調(diào)試中踩過的坑與排查技巧實(shí)錄源碼寫出來只是第一步調(diào)試才是最頭大的環(huán)節(jié)。我把自己這些年搞RTSP調(diào)試壓箱底的經(jīng)驗(yàn)總結(jié)了一部分這些都是用時(shí)間堆出來的教訓(xùn)。5.1 Wireshark是RTSP調(diào)試第一工具無論你多熟悉源碼網(wǎng)絡(luò)層面的問題必須靠抓包工具來定位。Wireshark對RTSP和RTP都有專門的協(xié)議解析器能直接展示請求響應(yīng)、RTP序號、時(shí)間戳和SSRC信息。抓包的時(shí)候過濾條件可以用rtsp || rtp或者只看某個(gè)IP和端口的流量。排查SDP解析問題的快捷辦法用Wireshark跟蹤TCP流然后導(dǎo)出DESCRIBE的響應(yīng)body對照RFC里的SDP規(guī)范逐行檢查。很多時(shí)候就是缺了一個(gè)acontrol客戶端就找不到trackIDSETUP直接失敗。5.2 RTP包序號跳變和客戶端卡頓RTP sequence number應(yīng)該每個(gè)包1如果有人為重傳或者其他邏輯改了計(jì)數(shù)客戶端接收端檢測到跳變會認(rèn)為丟包觸發(fā)丟包重傳邏輯然后造成更大的混亂。我之前遇到過一個(gè)問題H.264的FU-A分片里分片的sequence正確但一個(gè)NALU內(nèi)部中間漏發(fā)了一個(gè)分片Wireshark里看著序號是連續(xù)的其實(shí)數(shù)據(jù)不連續(xù)客戶端解碼出來花屏。排查思路很簡單抓一個(gè)完整GOP的包統(tǒng)計(jì)每個(gè)NALU的分片數(shù)量再用工具重構(gòu)原始H.264流用ffplay或Elecard流分析工具看是否有解碼錯(cuò)誤。一旦定位到漏發(fā)基本就是memcpy的偏移量算錯(cuò)了回到源碼里檢查offset維護(hù)邏輯。5.3 時(shí)間戳不同步導(dǎo)致音畫不一致音視頻雙軌的RTSP服務(wù)器最容易翻車的就是音視頻時(shí)間戳基準(zhǔn)不一致。視頻的timestamp基準(zhǔn)和音頻的timestamp基準(zhǔn)是不同的時(shí)鐘。RFC里建議都用90kHz但實(shí)際攝像頭音頻采樣率是8k或16k換算方式不同很容易出現(xiàn)偏差。我調(diào)試過的攝像機(jī)源碼里視頻時(shí)間戳用的是PTS乘以90k倍率音頻用的卻是采樣率直接當(dāng)頻率填進(jìn)去了。結(jié)果就是音頻比視頻快或者慢播放久了聲音和畫面完全對不上。解決方法是明確一個(gè)全局時(shí)間基準(zhǔn)比如以微秒為單位視頻和音頻都從這個(gè)基準(zhǔn)換算各自的時(shí)間戳增量。源碼實(shí)現(xiàn)里用統(tǒng)一的timebase轉(zhuǎn)換函數(shù)保證兩邊算法一致問題自然消失。5.4 客戶端直接斷網(wǎng)導(dǎo)致的端口泄漏手機(jī)App端測試的人經(jīng)常直接殺進(jìn)程這時(shí)服務(wù)器收不到TEARDOWN如果代碼里沒有心跳超時(shí)機(jī)制會話就一直掛著UDP端口一直被占用。積累多了資源耗盡新客戶端連不上。我的做法是給每個(gè)會話加一個(gè)最近活躍時(shí)間戳每次收到RTP/RTSP控制包都更新。然后在一個(gè)周期任務(wù)里檢查所有會話超過30秒沒有活躍的自動清理并關(guān)閉對應(yīng)socket。別小看這個(gè)機(jī)制它直接決定服務(wù)器能不能7x24小時(shí)穩(wěn)定運(yùn)行。5.5 C語言RTSP源碼日常問題速查現(xiàn)象可能原因排查動作服務(wù)啟動報(bào)Address already in use未設(shè)置SO_REUSEADDR檢查setsockoptDESCRIBE請求返回但客戶端拿不到SDPContent-Length不對或響應(yīng)頭缺空行Wireshark跟蹤TCP流檢查body能SETUP不能PLAY狀態(tài)機(jī)未正確流轉(zhuǎn)或方法分發(fā)表缺失日志輸出當(dāng)前狀態(tài)和目標(biāo)狀態(tài)RTP包發(fā)出去客戶端收不到端口不匹配或服務(wù)器地址寫錯(cuò)抓包確認(rèn)UDP目標(biāo)端口畫面花屏或頓挫FU-A分片S/E位錯(cuò)誤或時(shí)間戳跳變用Wireshark導(dǎo)出RTP負(fù)載分析序列高并發(fā)CPU飆高每包malloc頻繁或線程切換過多改用棧上緩沖區(qū)/事件循環(huán)模型程序崩潰在rtp打包邏輯指針越界或偏移計(jì)算錯(cuò)誤開啟AddressSanitizer編譯測試6. 從源碼到可商用還需要考慮的幾個(gè)擴(kuò)展方向看RTSP服務(wù)器的C源碼如果只是想看懂某個(gè)項(xiàng)目或者應(yīng)付課設(shè)前面五節(jié)已經(jīng)夠用。但如果是想在真實(shí)項(xiàng)目里落地商用還有幾個(gè)點(diǎn)值得繼續(xù)深入。6.1 認(rèn)證機(jī)制不能只靠舉例簡化的RTSP服務(wù)器源碼經(jīng)常把認(rèn)證省了全部請求都放行。實(shí)際產(chǎn)品里至少要支持RFC 2069定義的Basic認(rèn)證和RFC 2617的Digest認(rèn)證。Digest認(rèn)證的C實(shí)現(xiàn)復(fù)雜一點(diǎn)要處理隨機(jī)數(shù)、MD5哈希、qop策略這些但安全性比Basic高很多不會明文傳密碼。如果源碼里有認(rèn)證鉤子建議優(yōu)先把Digest做上。6.2 并發(fā)擴(kuò)展的消息隊(duì)列高并發(fā)場景下解碼線程、RTSP控制線程、RTP發(fā)送線程之間需要消息通信。簡單的共享內(nèi)存加鎖容易在復(fù)雜的時(shí)序關(guān)系里出問題。我見過一個(gè)性能不錯(cuò)的源碼實(shí)現(xiàn)所有線程之間通過無鎖環(huán)形隊(duì)列通信生產(chǎn)者只管寫消費(fèi)者只管讀用內(nèi)存屏障保證可見性。這樣在四核ARM處理器上跑八路流消息延遲可以穩(wěn)定控制在毫秒級。6.3 轉(zhuǎn)發(fā)與錄像并存很多RTSP服務(wù)器的源碼只做了實(shí)時(shí)轉(zhuǎn)發(fā)沒有本地存儲。但是真實(shí)項(xiàng)目里“邊推流邊錄像”是剛需。實(shí)現(xiàn)錄像功能時(shí)最簡單的方式是加一個(gè)訂閱者機(jī)制在RTP打包完成的同時(shí)把數(shù)據(jù)投遞給錄像模塊錄像模塊按GOP邊界切分保存為MP4或裸H.264。C語言實(shí)現(xiàn)里可以用回調(diào)函數(shù)實(shí)現(xiàn)這個(gè)鉤子業(yè)務(wù)方只需要注冊一個(gè)on_rtp_packet函數(shù)就能在不改動主流程的情況下接入錄像、轉(zhuǎn)碼、AI分析等能力。最后再補(bǔ)充一個(gè)我的個(gè)人習(xí)慣不管讀誰的RTSP服務(wù)器源碼我會先在本地編譯跑通再看代碼結(jié)構(gòu)再用Wireshark對照協(xié)議特征抓包驗(yàn)證一遍最后再修改代碼做壓力測試。這套流程走下來源碼里藏的各種細(xì)節(jié)基本都能被你挖得清清楚楚。如果你也有自己的調(diào)試心得或者踩過什么有意思的坑歡迎交流。本文還有配套的精品資源點(diǎn)擊獲取