RTP 傳輸核心解析：負載類型與時間戳的正確設定指南

前言：一週除錯換來的深刻教訓

近期在 RTP 專案中遭遇棘手問題，耗時近一週才定位根因：對 RTP 協定中 Payload Type（負載類型）與 Timestamp（時間戳）的語義理解不夠透徹。雖有 jrtplib、oRTP 等成熟函式庫加持，但若不掌握底層原理，問題一發生便無從下手。本文將這些核心概念系統化整理，助你避開同樣陷阱。

負載類型：媒體格式的身分證

RTP 封包標頭中的 PT 欄位

RTP 標頭第 10~16 位元為 PT（Payload Type）欄位，定義封包承載資料的媒體編碼格式（如 G.729、H.264、MPEG-4）。接收端依此欄位選擇對應解碼器，是媒體協商的關鍵。

oRTP 函式庫中的負載類型定義

oRTP (v0.9.1) 內建主流媒體類型常數，涵蓋 PCMU、G.729、H.263、MPEG-4 等。早期版本缺 H.264 定義，新版已補齊。jrtplib 亦有對應定義。關鍵操作：必須根據實際媒體流呼叫庫提供的 set_payload_type() 等介面正確設定。筆者曾因疏忽使用預設 PCMU 音訊類型傳送 H.264 視訊，導致傳輸異常難以排查。

時間戳：媒體同步的心跳

核心概念釐清

• 時間戳單位：非秒等絕對單位，而是 1 / 採樣頻率。例：音訊 8kHz → 單位 1/8000 秒。
• 時間戳增量：相鄰兩個 RTP 封包間的時間差（以時間戳單位計）。
• 採樣頻率：每秒取樣次數（音訊常 8000Hz，視訊常 90000Hz）。
• 幀率：每秒傳輸/顯示幀數（如 25 fps）。

協定定義與實務運算

RFC 3550 規定：時間戳反映 RTP 封包中第一個位元組的採樣時刻；會話啟動時初值隨機；靜默期間時間戳仍須遞增。接收端用於消除抖動、音視同步。

視訊時間戳增量計算實例

• 視訊採樣頻率：90000 Hz → 時間戳單位 = 1/90000 秒
• 幀率：25 fps → 每幀間隔 = 1/25 秒
• 時間戳增量 = (1/25) / (1/90000) = 3600

即每發送一幀視訊，時間戳遞增 3600。此值直接決定網路發送節奏：增量越小發送越快，需與採集速率匹配以均衡頻寬。

函式庫行為差異

• jrtplib：內部自動管理時間戳遞增，開發者介入較少。
• oRTP：每次發送需手動傳入時間戳值，開發者必須自行累加增量。筆者初期因誤設增量導致傳輸失敗，深感理解原理的重要性。

總結與建議

1. 負載類型必須與實際編碼格式嚴格對應，切勿沿用預設值。
2. 時間戳單位由採樣頻率決定，視訊通常 90kHz，音訊 8kHz。
3. 時間戳增量 = 幀間隔 / 時間戳單位，確保網路發送速率匹配媒體採集速率。
4. 動手編碼前，務必研讀 RFC 3550 並驗證函式庫預設行為。

磨刀不誤砍柴工，掌握協定本質才能高效解決疑難雜症。