簡介這份代碼包聚焦RTP承載H264的解析與落盤面向具備C和網(wǎng)絡(luò)編程基礎(chǔ)、正在做監(jiān)控視頻、流媒體轉(zhuǎn)發(fā)或UDP實(shí)時(shí)取流的開發(fā)者可用于把攝像頭RTP數(shù)據(jù)重組為可播放的H264文件。壓縮包共14個(gè)文件以6個(gè)h頭文件和4個(gè)cpp源文件為主體另含Visual Studio工程、篩選器、用戶配置及說明文檔整體約9KB體量輕便便于導(dǎo)入IDE查閱和調(diào)試。已有1032人學(xué)習(xí)下載適合作為協(xié)議解析與工程實(shí)現(xiàn)的對照參考。代碼圍繞服務(wù)端接收與公共工具模塊展開涵蓋RTP包頭解析、NAL單元邊界識別與重組、UDP數(shù)據(jù)接收以及H264 Annex B寫入等環(huán)節(jié)讀者可據(jù)此理解分包處理、順序恢復(fù)與丟失標(biāo)記修復(fù)思路并在此基礎(chǔ)上改造成自己的取流落盤工具。對于需要排查花屏、丟包與時(shí)間戳錯(cuò)位問題的讀者也能從代碼結(jié)構(gòu)中獲取可復(fù)用的處理線索。1. RTP 數(shù)據(jù)保存為 .h264 文件先分清收到的是流還是幀把 UDP 上的 rtp h264 數(shù)據(jù)保存成一個(gè)能雙擊播放的 .h264 文件看起來只是收包加寫文件實(shí)際最容易出問題的地方在載荷層RTP 頭、FU-A 分片、STAP-A 聚合、Annex-B 起始碼任何一處對不上文件就會(huì)“有體積、沒畫面”。這份資源適合兩類人一是做 IPC、錄播、無線圖傳的嵌入式或后端工程師手里有 RTP 流但需要一個(gè)最小可用的保存工具二是剛接觸 H.264 封裝、想從抓包一路走到可播放裸流的學(xué)習(xí)者。下面按“拆包、重組、寫盤、驗(yàn)收”的順序把可參考的腳本和實(shí)際踩過的坑一次講清。2. 拆 RTP 載荷12 字節(jié)頭、三種封裝與 NAL 邊界RTP 收到的是“包”H.264 解碼器要的是“NAL 單元”。中間這層轉(zhuǎn)換并不復(fù)雜但字段含義必須摳準(zhǔn)。我見過最常見的誤操作是把recvfrom收到的整段 buffer 直接追加到文件末尾結(jié)果文件里混進(jìn)了 RTP 頭、FU-A 分片頭播放器只能靠運(yùn)氣解出第一幀。2.1 RTP 固定頭里真正要用的四個(gè)字段RTP 固定頭最少 12 字節(jié)后面還可能跟 CSRC 列表、擴(kuò)展頭、填充字節(jié)。寫保存工具時(shí)不需要實(shí)現(xiàn)完整協(xié)議棧但下面幾個(gè)字段必須讀對字段位寬實(shí)際用途版本 V2 bit必須為 2不是 2 直接丟包填充 P1 bit末尾有填充最后一個(gè)字節(jié)是填充長度擴(kuò)展 X1 bit固定頭后有擴(kuò)展長度按 32 位字計(jì)算CSRC 計(jì)數(shù) CC4 bit固定頭實(shí)際長度 12 4×CC標(biāo)記 M1 bit常用來標(biāo)一幀的最后一個(gè)包但不能完全依賴載荷類型 PT7 bit動(dòng)態(tài)類型 96–127 常見要和 SDP 對上序列號16 bit判丟包、亂序回繞按 16 位處理時(shí)間戳32 bit同一幀內(nèi)相同幀間遞增H.264 常見 90 kHzSSRC32 bit同一端口多路流時(shí)用來過濾計(jì)算載荷偏移時(shí)先算12 cc * 4如果X1再讀擴(kuò)展頭前 4 個(gè)字節(jié)其中后 2 字節(jié)是擴(kuò)展長度單位是 32 位字所以還要加4 ext_len * 4。如果P1最后一個(gè)字節(jié)是填充長度載荷末尾要減掉。這個(gè)偏移算錯(cuò)后面所有 NAL 解析都會(huì)錯(cuò)位。序列號是 16 位無符號數(shù)從 65535 回到 0 是正?；乩@。判斷丟包不要寫seq ! last_seq 1而要用((seq - last_seq) 0xFFFF) ! 1。時(shí)間戳也不是毫秒H.264 常用 90 kHz 時(shí)鐘同一幀的多個(gè)分片時(shí)間戳相同換幀才遞增。標(biāo)記位 M 在 H.264 里通常表示一個(gè)接入單元結(jié)束但有些發(fā)送端按切片設(shè)置不能把它當(dāng)成唯一的幀邊界。2.2 單 NAL、STAP-A、FU-A三種封裝怎么識別H.264 的 RTP 載荷格式由 NAL 頭低 5 位決定常見就三類nal_type名稱處理方式1–23單 NAL直接加起始碼寫文件24STAP-A一個(gè) RTP 里聚合多個(gè) NAL按 2 字節(jié)長度切25STAP-B帶 DON少見不要按 STAP-A 硬解26MTAP16交織封裝少見27MTAP24交織封裝少見28FU-A分片首字節(jié)是指示第二字節(jié)含 S/E/類型29FU-B帶 DON 的分片少見單 NAL 最好處理載荷本身就是完整 NAL前面補(bǔ)00 00 00 01就能寫。STAP-A 的載荷第 1 字節(jié)是聚合頭后面重復(fù)“2 字節(jié)大端長度 NAL 數(shù)據(jù)”要循環(huán)切完。FU-A 最容易寫錯(cuò)第 1 字節(jié)的低 5 位是 28高 3 位是原始 NAL 的 F 和 NRI第 2 字節(jié)最高位 S 表示分片開始次高位 E 表示分片結(jié)束低 5 位才是原始 NAL 類型。重組時(shí)原始 NAL 頭是(fu_ind 0xE0) | (fu_hdr 0x1F)不是直接把兩個(gè)字節(jié)都塞進(jìn)去。FU-A 分片只在第一片寫一次 NAL 頭中間分片只追加數(shù)據(jù)最后一片收齊后整體加起始碼寫文件。很多人給每個(gè)分片都加起始碼解碼器會(huì)把每個(gè)分片當(dāng)成獨(dú)立 NAL第一幀之后基本就廢了。STAP-A 里如果帶 SPS/PPS也要按順序?qū)懗鰜聿灰蝗〉谝粋€(gè) NAL。2.3 用 Python 解出第一層UDP 收包與 RTP 頭解析先不寫文件只把 RTP 頭解析出來打印確認(rèn)序列號、時(shí)間戳、標(biāo)記位和 NAL 類型符合預(yù)期。這一步花十分鐘后面能省掉大量“文件為什么不能播”的排查。import socket import struct def parse_rtp(pkt): if len(pkt) 12: return None b0, b1 pkt[0], pkt[1] version b0 6 if version ! 2: return None padding (b0 5) 0x01 extension (b0 4) 0x01 cc b0 0x0F marker (b1 7) 0x01 pt b1 0x7F seq, ts, ssrc struct.unpack(!HII, pkt[2:12]) offset 12 cc * 4 if extension: if len(pkt) offset 4: return None ext_len struct.unpack(!H, pkt[offset 2:offset 4])[0] offset 4 ext_len * 4 end len(pkt) if padding: pad_len pkt[-1] end - pad_len payload pkt[offset:end] if not payload: return None nal_type payload[0] 0x1F return { seq: seq, ts: ts, ssrc: ssrc, pt: pt, marker: marker, nal_type: nal_type, payload: payload, } sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4 * 1024 * 1024) sock.bind((0.0.0.0, 5004)) while True: pkt, addr sock.recvfrom(65535) info parse_rtp(pkt) if not info: continue print( info[seq], info[ts], info[marker], info[pt], info[nal_type], len(info[payload]) )這段代碼的重點(diǎn)不在print而在三個(gè)邊界cc決定固定頭后面有沒有 CSRCextension決定要不要跳過擴(kuò)展頭padding決定末尾要不要減掉填充。少算一個(gè)payload[0] 0x1F拿到的就不是 NAL 類型。SO_RCVBUF設(shè)在bind之前才生效Linux 下內(nèi)核會(huì)把設(shè)置值翻倍實(shí)際可用大小可以用getsockopt再看一眼。跑起來后觀察輸出如果nal_type長期是 28說明這路流大量使用 FU-A 分片如果出現(xiàn) 24說明有 STAP-A 聚合如果一直是 1–23說明是單 NAL 打包。marker1的包通常是一幀的最后一個(gè)包但先別急著依賴它下一步寫文件時(shí)還要結(jié)合時(shí)間戳變化。3. 寫 Annex-B起始碼、SPS/PPS 與寫盤順序RTP 拆出來的 NAL 不能直接拼成.h264。裸流文件需要 Annex-B 格式每個(gè) NAL 前面有起始碼而且 SPS/PPS 必須出現(xiàn)在 IDR 之前。很多“文件有大小、播放器不識別”的問題根源不是收包而是寫盤格式不對。3.1 裸流為什么必須是 Annex-BH.264 有兩種常見封裝Annex-B 用00 00 00 01或00 00 01分隔 NALAVCC 用 4 字節(jié)大端長度前綴。.h264裸流一般按 Annex-B 處理.mp4里的視頻軌才用長度前綴。你把 AVCC 格式直接寫成.h264ffplay 可能報(bào)“Invalid NAL unit size”因?yàn)榻獯a器把長度字段當(dāng)成起始碼在找。起始碼用 4 字節(jié)更穩(wěn)00 00 00 01。3 字節(jié)也合法但和某些 NAL 數(shù)據(jù)開頭的00 00 01容易混淆調(diào)試時(shí)不好判斷。寫文件時(shí)統(tǒng)一用 4 字節(jié)讀的時(shí)候兩種都認(rèn)能減少一半玄學(xué)問題。還有一個(gè)細(xì)節(jié)不要在每個(gè) RTP 包前加起始碼而要在每個(gè)完整 NAL 前加。單 NAL 包好辦FU-A 必須等最后一片收齊再寫STAP-A 要拆成多個(gè) NAL 分別寫。這個(gè)順序錯(cuò)了文件看起來很大實(shí)際解碼器只能認(rèn)出第一幀。3.2 SPS/PPS 從哪來SDP、帶內(nèi)與首包緩存SPS/PPS 是解碼器的“說明書”沒有它們IDR 幀也解不出來。常見來源有三個(gè)SDP 里的sprop-parameter-sets。例如afmtp:96 packetization-mode1;profile-level-id42e01f;sprop-parameter-setsZ0LgH...,aM48g...逗號前是 SPS 的 Base64逗號后是 PPS。帶內(nèi)發(fā)送。有些編碼器在 IDR 前先發(fā) SPS/PPSRTP 里能看到nal_type7和nal_type8。抓包工具里手動(dòng)提取。只有前兩種都拿不到時(shí)才用容易抄錯(cuò)。從 SDP 解參數(shù)集可以這樣寫import base64 # 從 SDP 的 fmtp 行里取逗號前后分別是 SPS 和 PPS 的 Base64 sprop base64_sps,base64_pps sps_b64, pps_b64 sprop.split(,) sps base64.b64decode(sps_b64) pps base64.b64decode(pps_b64) with open(out.h264, wb) as f: f.write(b\x00\x00\x00\x01 sps) f.write(b\x00\x00\x00\x01 pps)如果 SDP 里沒有sprop-parameter-sets就在收流時(shí)緩存nal_type7和nal_type8等第一個(gè) IDR 到來前補(bǔ)寫。帶內(nèi)參數(shù)集可能會(huì)變比如分辨率切換遇到新的 SPS/PPS 要重新寫不要只認(rèn)第一次。提示profile-level-id只能說明檔次和級別不能代替 SPS/PPS。只寫這個(gè)字段解碼器仍然沒有完整的參數(shù)集。3.3 完整的收流寫文件腳本下面這個(gè)腳本把 UDP 收包、RTP 解析、FU-A 重組、STAP-A 拆分、Annex-B 寫盤串在一起。它不依賴第三方庫適合先跑通最小鏈路再按項(xiàng)目需要加隊(duì)列、切片和重連。import socket import struct import sys START_CODE b\x00\x00\x00\x01 class H264Writer: def __init__(self, path, spsNone, ppsNone): self.f open(path, wb) self.sps sps self.pps pps # 如果 SDP 已經(jīng)給了參數(shù)集先寫文件頭 if self.sps and self.pps: self.f.write(START_CODE self.sps) self.f.write(START_CODE self.pps) self.param_written True else: self.param_written False self.fu_buf None self.last_seq None def _write_nal(self, nal): if not nal: return nal_type nal[0] 0x1F if nal_type 7: self.sps nal elif nal_type 8: self.pps nal # 沒有 SDP 參數(shù)集時(shí)在第一個(gè) IDR 前補(bǔ)寫緩存的 SPS/PPS if nal_type 5 and not self.param_written and self.sps and self.pps: self.f.write(START_CODE self.sps) self.f.write(START_CODE self.pps) self.param_written True self.f.write(START_CODE nal) # 帶內(nèi)收到 SPS/PPS 也算已寫參數(shù)集 if nal_type in (7, 8) and self.sps and self.pps: self.param_written True def push(self, pkt): if len(pkt) 12: return b0, b1 pkt[0], pkt[1] if (b0 6) ! 2: return cc b0 0x0F extension (b0 4) 0x01 padding (b0 5) 0x01 marker (b1 7) 0x01 seq, ts, ssrc struct.unpack(!HII, pkt[2:12]) offset 12 cc * 4 if extension: if len(pkt) offset 4: return ext_len struct.unpack(!H, pkt[offset 2:offset 4])[0] offset 4 ext_len * 4 end len(pkt) if padding: end - pkt[-1] payload pkt[offset:end] if not payload: return # 序列號不連續(xù)只記錄不在這里直接丟流 if self.last_seq is not None: gap (seq - self.last_seq) 0xFFFF if gap ! 1: print(fseq gap: {self.last_seq} - {seq}, gap{gap}, filesys.stderr) self.last_seq seq nal_type payload[0] 0x1F if nal_type 28: # FU-A fu_ind payload[0] fu_hdr payload[1] start (fu_hdr 7) 0x01 end_flag (fu_hdr 6) 0x01 real_type fu_hdr 0x1F if start: self.fu_buf bytearray() # 重建原始 NAL 頭F/NRI 來自 fu_ind類型來自 fu_hdr self.fu_buf.append((fu_ind 0xE0) | real_type) if self.fu_buf is None: return self.fu_buf.extend(payload[2:]) if end_flag: self._write_nal(bytes(self.fu_buf)) self.fu_buf None elif nal_type 24: # STAP-A i 1 while i 2 len(payload): size struct.unpack(!H, payload[i:i 2])[0] i 2 nal payload[i:i size] i size if nal: self._write_nal(nal) elif 1 nal_type 23: self._write_nal(payload) if marker: self.f.flush() def close(self): # 不完整的 FU-A 直接丟棄避免寫壞幀 self.fu_buf None self.f.close() if __name__ __main__: listen_ip 0.0.0.0 listen_port 5004 out_path out.h264 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 8 * 1024 * 1024) sock.bind((listen_ip, listen_port)) # 參數(shù)集可從 SDP 解出來后傳進(jìn)來這里留空表示依賴帶內(nèi) SPS/PPS writer H264Writer(out_path) print(flistening {listen_ip}:{listen_port} - {out_path}) try: while True: pkt, _ sock.recvfrom(65535) writer.push(pkt) except KeyboardInterrupt: pass finally: writer.close() sock.close()代碼里的參數(shù)不多但每個(gè)都影響結(jié)果參數(shù)作用建議listen_ip監(jiān)聽網(wǎng)卡本機(jī)測試用0.0.0.0生產(chǎn)可綁定具體網(wǎng)卡listen_portRTP 端口常用偶數(shù)端口5004 只是示例SO_RCVBUF內(nèi)核收包緩沖2–8 MB先設(shè)再 bindout_path輸出裸流先用短文件名避免路徑權(quán)限問題sps/pps參數(shù)集能從 SDP 拿就從 SDP 拿拿不到靠帶內(nèi)_write_nal里做了兩件事遇到 SPS/PPS 就緩存遇到 IDR 且參數(shù)集還沒寫就補(bǔ)寫。這樣即使發(fā)送端沒有在 IDR 前發(fā)參數(shù)集只要之前收到過 SPS/PPS文件頭也能補(bǔ)上。STAP-A 分支按 2 字節(jié)長度循環(huán)注意i 2和i size不能漏否則會(huì)死循環(huán)或切出錯(cuò)誤 NAL。FU-A 分支只在start1時(shí)新建 bufferend1時(shí)寫盤中間分片只追加數(shù)據(jù)。marker1時(shí) flush是為了讓文件在錄制過程中也能被播放器讀到完整幀不是必須但調(diào)試方便。4. 避坑與排查文件有大小卻沒畫面的五種現(xiàn)場4.1 文件幾十 MB播放器只顯示第一幀現(xiàn)象.h264文件體積不小ffplay 能出第一幀之后黑屏或卡住。原因最常見的是把 RTP 頭一起寫進(jìn)了文件或者給每個(gè) FU-A 分片都加了起始碼。解碼器在第一幀碰巧能同步后面讀到的是“起始碼 FU-A 指示字節(jié) 分片數(shù)據(jù)”NAL 類型對不上直接停止。解決用十六進(jìn)制工具看文件頭正常應(yīng)該是00 00 00 01 67或00 00 00 01 65開頭。如果看到80 60這類 RTP 頭字節(jié)說明偏移算錯(cuò)如果每個(gè)分片前都有00 00 00 01把起始碼移到 FU-A 重組完成之后。4.2 畫面下半部綠塊幾秒后花屏現(xiàn)象能播但畫面局部綠塊、馬賽克運(yùn)動(dòng)場景更明顯。原因FU-A 丟包或亂序。一個(gè) FU-A 幀少一個(gè)分片整幀數(shù)據(jù)不完整如果腳本還把不完整的分片寫進(jìn)文件解碼器會(huì)繼續(xù)用壞幀預(yù)測后面幾幀也跟著花。解決按序列號做小窗口重排窗口不用大2–4 個(gè)包足夠發(fā)現(xiàn)丟包時(shí)當(dāng)前 FU-A 直接丟棄等到下一個(gè)start1或下一個(gè) IDR 再繼續(xù)寫。寧可少一幀不要把半幀寫進(jìn)文件。日志里記錄seq gap方便判斷是網(wǎng)絡(luò)丟包還是處理太慢。4.3 ffplay 報(bào) Invalid NAL unit size 或直接退出現(xiàn)象ffplay 打不開文件ffprobe 報(bào) “Invalid data found when processing input”。原因?qū)懗闪?AVCC 長度前綴或者起始碼字節(jié)序?qū)戝e(cuò)。比如把00 00 00 01寫成01 00 00 00或者把 NAL 長度當(dāng)成起始碼寫進(jìn)去。解決確認(rèn)每個(gè) NAL 前是00 00 00 01不是 4 字節(jié)長度。用xxd -l 64 out.h264看一眼前幾個(gè)字節(jié)應(yīng)該是0000 0001 67或0000 0001 68。如果是0000 001f 67這種說明寫的是長度字段。4.4 收流幾分鐘后開始丟包文件時(shí)間軸斷裂現(xiàn)象剛開始正常幾分鐘后花屏增多日志里seq gap密集出現(xiàn)。原因recvfrom處理太慢或者收包循環(huán)里做了阻塞寫盤、打印、加鎖。UDP 沒有重傳內(nèi)核緩沖區(qū)一滿就丟包。SO_RCVBUF設(shè)得太小也會(huì)提前丟。解決收包線程只做recvfrom和入隊(duì)寫盤放到單獨(dú)線程減少收包循環(huán)里的printSO_RCVBUF調(diào)到 4–8 MB并在bind之前設(shè)置。如果還丟檢查網(wǎng)卡中斷和 CPU 占用不要先懷疑協(xié)議。4.5 同一端口換一路流文件里混進(jìn)別的畫面現(xiàn)象一個(gè)端口上跑多路 RTP保存出來的文件畫面跳來跳去。原因沒有按 SSRC 或載荷類型過濾。RTP 允許同一端口多個(gè) SSRC動(dòng)態(tài) PT 也可能不同。腳本如果見包就收自然會(huì)把兩路流拼在一起。解決從 SDP 或首包確定目標(biāo) SSRC后續(xù)只處理相同 SSRC 的包同時(shí)校驗(yàn) PT 是否在預(yù)期范圍。多路流最好分端口實(shí)在要復(fù)用就在腳本里加過濾條件別等文件壞了再回頭查。5. 驗(yàn)收用 ffprobe 和 ffmpeg 把“能播”拆成可檢查項(xiàng)文件寫完不等于任務(wù)完成。我一般會(huì)跑三步驗(yàn)收ffprobe 看流參數(shù)ffmpeg 解碼看錯(cuò)誤抓包對照看包數(shù)。三步都過再交給別人用。5.1 ffprobe 看 profile、分辨率、幀數(shù)先看基礎(chǔ)信息ffprobe -v error -select_streams v:0 \ -show_entries streamcodec_name,profile,width,height,pix_fmt,level \ -of defaultnw1 out.h264正常輸出會(huì)包含codec_nameh264、profileHigh或Constrained Baseline、width/height、pix_fmtyuv420p。如果 ffprobe 直接報(bào)錯(cuò)優(yōu)先查起始碼和 SPS/PPS如果 profile 顯示unknown說明參數(shù)集沒寫對。再看幀數(shù)ffprobe -v error -count_frames -select_streams v:0 \ -show_entries streamnb_read_frames -of csvp0 out.h264這個(gè)數(shù)字要和發(fā)送端大致對得上。如果只有 1 幀說明 IDR 之后的數(shù)據(jù)沒被識別如果幀數(shù)明顯偏少回查 FU-A 重組和丟包處理。裸流沒有容器時(shí)間戳ffprobe 的幀率是猜的所以不要拿它判斷實(shí)際幀率幀數(shù)更有參考價(jià)值。5.2 ffmpeg 轉(zhuǎn) mp4 與解碼核對把裸流轉(zhuǎn)成 mp4能快速判斷是文件問題還是播放器問題ffmpeg -fflags genpts -r 25 -i out.h264 -c copy out.mp4-r 25是給裸流一個(gè)輸入幀率因?yàn)?h264本身不攜帶幀率。實(shí)際幀率不是 25 就換成對應(yīng)的值否則 mp4 的時(shí)長會(huì)不準(zhǔn)。-c copy不重新編碼只換容器能播說明碼流基本正常不能播再回頭查 Annex-B。再做一次完整解碼專門看錯(cuò)誤輸出ffmpeg -v error -i out.h264 -f null -這條命令不生成文件只解碼。如果終端不斷刷 “error while decoding” 或 “no frame”說明碼流有壞幀或參數(shù)集缺失。少量錯(cuò)誤可能是丟包導(dǎo)致大量錯(cuò)誤就要查重組邏輯。檢查項(xiàng)命令或觀察點(diǎn)異常含義文件頭xxd -l 32 out.h264不是00000001開頭起始碼錯(cuò)流參數(shù)ffprobe 看 profile/分辨率unknown 或缺失SPS/PPS 沒寫幀數(shù)-count_frames只有 1 幀F(xiàn)U-A 重組或 IDR 丟失解碼錯(cuò)誤ffmpeg -v error大量報(bào)錯(cuò)壞幀或丟包容器轉(zhuǎn)換轉(zhuǎn) mp4 后播放裸流能播、mp4 不能播查時(shí)間戳或幀率5.3 抓包對照用 tshark 驗(yàn)證 RTP 包數(shù)有 pcap 的話直接對比 RTP 序列號和標(biāo)記位tshark -r rtp.pcap -Y rtp \ -T fields -e rtp.seq -e rtp.timestamp -e rtp.marker -e rtp.p_type \ | head -n 20看三件事序列號是否連續(xù)時(shí)間戳是否按幀遞增標(biāo)記位是否在預(yù)期位置。序列號缺口和腳本日志里的seq gap對得上說明丟包發(fā)生在網(wǎng)絡(luò)或內(nèi)核緩沖區(qū)對不上可能是腳本解析偏移錯(cuò)了。rtp.p_type用來確認(rèn)動(dòng)態(tài)載荷類型別把 96 和 97 兩路流混在一起。6. 把腳本變成工具丟包、亂序與長流的三個(gè)硬約束最小腳本跑通之后真正決定能不能長期用的是三個(gè)約束丟包策略、亂序窗口、長流切片。這三個(gè)點(diǎn)不處理錄十分鐘可能沒問題錄兩小時(shí)一定出狀況。約束常見做法代價(jià)丟包丟到下一個(gè) IDR或記錄空洞繼續(xù)寫前者少一段畫面后者可能花屏亂序2–4 個(gè)包的小重排窗口延遲增加幾毫秒長流按大小或時(shí)長切片每片重寫 SPS/PPS文件變多但可定位、可恢復(fù)丟包策略沒有標(biāo)準(zhǔn)答案。做監(jiān)控回放我一般選擇“丟到下一個(gè) IDR”因?yàn)榛ㄆ翈M(jìn)了文件后面幾秒都跟著壞回放體驗(yàn)更差做鏈路質(zhì)量分析反而要保留空洞并記錄序列號方便定位是哪一段網(wǎng)絡(luò)出了問題。關(guān)鍵是別默默把半幀寫進(jìn)去至少打一條日志。亂序窗口不要開太大。RTP 走 UDP真正亂序通常發(fā)生在幾包之內(nèi)2–4 個(gè)包足夠窗口太大收包線程要等延遲上來實(shí)時(shí)性就沒了。實(shí)現(xiàn)上可以用一個(gè)按序列號排序的小字典收到連續(xù)包就往上寫超時(shí)或缺口太大就跳過。長流切片建議按 200–500 MB 或 10–30 分鐘切一次每片重新寫 SPS/PPS。這樣即使某一片損壞其他片還能單獨(dú)播。切片時(shí)注意不要在 FU-A 中間切等一個(gè)完整幀寫完再換文件。文件名帶上序號或時(shí)間后面排查會(huì)輕松很多。從那以后我每次接一路新流都先跑一遍 ffprobe 看 profile 和分辨率再抽前 200 幀做完整解碼最后才把保存腳本掛到長時(shí)間任務(wù)上。這個(gè)習(xí)慣不高級但能擋住大部分“文件有大小、畫面不對”的返工。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取