一、什么是 RTSP?協議

1.1 RTSP 協議簡介?

RTSP，全稱實時流傳輸協議（Real Time Streaming Protocol），是一種位于應用層的網絡協議。它主要用于在流媒體系統中控制實時數據（如音頻、視頻等）的傳輸，并不直接負責媒體數據的傳輸，而是像一個 “遙控器”，通過發送一系列指令（如播放、暫停、快進、后退等）來對媒體流的傳輸過程進行管理和控制。?

1.2 RTSP傳輸基本原理

我們所說的RTSP傳輸并不是只依靠RTSP協議，還要依賴RTP、RTCP、SDP協議共同實現媒體數據流的傳輸和控制。

1.2.1 RTSP?

• 作用：RTSP 主要負責對實時媒體流的傳輸進行控制，協調客戶端和服務器之間的交互。它可以建立和終止媒體會話，以及對媒體流的播放狀態進行控制。?

• 傳輸方式：RTSP 本身通常使用 TCP 進行傳輸。這是因為 RTSP 的控制指令需要可靠的傳輸，確保指令能夠準確無誤地到達對方，避免因指令丟失或錯誤而導致的控制混亂。?

1.2.2 RTP

• 作用：RTP（Real-time Transport Protocol，實時傳輸協議）主要負責實時媒體數據（如音頻、視頻）的實際傳輸，RTP包是音視頻數據的載體。它能夠為實時數據提供時間戳、序列號等信息，幫助接收端正確地重組和播放媒體數據。?
• 傳輸方式：RTP 通常基于 UDP 進行傳輸。由于 UDP 具有傳輸速度快、延遲低的特點，能夠很好地滿足實時媒體數據對實時性的要求。雖然 UDP 不保證數據傳輸的可靠性，可能會出現數據包丟失的情況，但對于音頻、視頻等實時數據來說，少量的數據包丟失對播放效果的影響相對較小，而實時性更為重要。

1.2.3 RTCP

• 作用：RTCP（Real-time Transport Control Protocol，實時傳輸控制協議）與 RTP 配合使用，主要用于監控 RTP 數據傳輸的質量。它可以收集和反饋諸如數據包丟失率、延遲抖動、網絡擁塞等信息，以便發送端和接收端根據這些信息調整傳輸策略，從而保證媒體流的傳輸質量。?
• 傳輸方式：RTCP 一般也基于 UDP 進行傳輸，并且通常與 RTP 共享同一個端口對（RTCP使用對應的RTP端口號+1的端口，例如某一視頻流RTP端口號31590，該視頻流RTCP端口號31591），以便更好地與 RTP 協同工作，及時獲取和反饋傳輸質量信息。?

（注意！！！ 音頻和視頻流的rtp與rtcp分開發送，假設一場直播中有一個音頻流和一個視頻流，那么音頻RTP發送端口A，音頻RTCP發送端口A+1,視頻RTP發送端口B，視頻RTCP發送端口B+1， A != B）

1.2.4 SDP?

• 作用：SDP（Session Description Protocol，會話描述協議）用于描述媒體會話的相關信息，如媒體類型（音頻、視頻）、編碼格式、傳輸地址、端口號等。它為通信雙方提供了協商媒體會話參數的基礎，讓接收端能夠了解如何正確接收和解析媒體數據。?

• 傳輸方式：SDP 本身并不負責數據的傳輸，它通常作為其他協議（?RTSP）消息的一部分進行傳輸。例如，在 RTSP 的會話建立過程中，服務器會通過 RTSP 消息將包含 SDP 信息的數據發送給客戶端，客戶端根據 SDP 信息來準備接收和播放媒體流。?

1.3 TCP、UDP 傳輸區別?

1. 連接方式：TCP 是面向連接的協議，在數據傳輸之前需要通過三次握手建立連接，數據傳輸完成后需要通過四次揮手釋放連接；而 UDP 是無連接的協議，通信雙方在傳輸數據之前不需要建立連接，可以直接發送數據。?
2. 可靠性：TCP 具有可靠傳輸的特點，它通過序列號、確認應答、重傳機制等確保數據能夠準確、完整地到達接收端，并且數據傳輸的順序與發送順序一致；UDP 不提供可靠性保障，它不保證數據的到達，也不保證數據傳輸的順序，可能會出現數據包丟失、重復或亂序的情況。?
3. 傳輸速度：由于 TCP 需要進行連接建立、確認應答、重傳等操作，會增加額外的開銷，因此傳輸速度相對較慢；UDP 不需要這些額外的操作，開銷較小，傳輸速度更快，實時性更好。?
4. 適用場景：TCP 適用于對可靠性要求較高的場景，如文件傳輸、電子郵件、網頁瀏覽等，這些場景中數據的準確性和完整性至關重要；UDP 適用于對實時性要求較高的場景，如音頻、視頻傳輸、實時游戲、視頻會議等，這些場景中少量的數據丟失對整體效果影響不大，但對傳輸延遲有較高的要求。

下面對RTP,RTCP,RTSP,SDP分開詳解

二、RTP 協議

2.1 RTP 報文頭部

RTP 報文的核心設計目標是讓實時媒體數據在網絡中跑得又快又準。它的結構分為?固定頭部（12 字節）?和?媒體數據負載，固定頭部字段包括：

?除此之外還有貢獻信源(CSRC)標識符（長度可變，所以不屬于固定頭部）：每個CSRC標識符占32位，可以有0～15個。每個CSRC標識了包含在該RTP 報?有效載荷中的所有貢獻信源。

對于Timestamp，SSRC和CSRC，這里詳細解釋一下：

時間戳（Timestamp）：
想象你在錄制一段視頻：

• 每按下一次快門（采樣），時間戳就增加一個固定值。比如 30fps 的視頻，每幀增加3000（90kHz 時鐘下的單位），就像每過 33.3ms 給幀打個標記；
• 接收端根據這些標記，就能知道幀該按什么順序播放，以及如何與音頻同步（比如說話的聲音和嘴型同時出現）。

?同步源（SSRC）
假設一場多人直播：

• 主播的攝像頭（SSRC_A）和嘉賓的攝像頭（SSRC_B）是兩個獨立的視頻流；
• 即使它們通過同一個網絡傳輸，接收端也能通過 SSRC_A 和 SSRC_B 把畫面分開顯示；
• SSRC 是隨機生成的，如果兩個設備不巧生成了相同的 SSRC，就像兩個人進了同一間房，需要重新分配（沖突概率極低）。

貢獻源（CSRC）
想象一個在線合唱比賽：

• 每個歌手的麥克風都是獨立的 SSRC（SSRC1、SSRC2、SSRC3）；
• 混音器把他們的聲音合并成一個流（新的 SSRC_M），并在 CSRC 列表中記錄原始的 SSRC1、SSRC2、SSRC3；
• 聽眾收到這個合并流時，通過查看CSRC就能知道每個聲音來自誰。

RTP 之所以要設計這些頭部字段就是為了：

• 序列號解決順序問題（包是否丟失或亂序）；
• 時間戳解決時間問題（媒體數據何時該播放）；
• SSRC解決來源問題（數據是誰發的）；
• CSRC解決混音問題（合并后的數據來自哪里）。

這種設計讓 RTP 在 UDP 上實現了低延遲、高可控性的實時傳輸，即使網絡不穩定，也能通過 RTCP 反饋（見下文）動態調整，確保音視頻流暢。

2.2?RTP 報文有效載荷

2.2.1 H264裸碼流封包解包

（一）H.264 碼流的基本結構：NALU

H.264 視頻流的核心單元是NALU（Network Abstraction Layer Unit），它像快遞包裹一樣包含視頻數據和元信息。每個 NALU 由兩部分組成（不考慮startcode）：

1. NALU 頭（1 字節）：
   • F（1 位）：錯誤標志，通常為 0（正常傳輸）；
   • NRI（2 位）：重要性等級（00 = 可丟棄，11 = 最高優先級），比如 I 幀的 NRI 通常為 11；
   • Type（5 位）：標識 NALU 類型（如5=IDR幀，7=SPS參數集）。
2. NALU 負載：實際的視頻數據（如 I 幀像素、P 幀殘差等）。

關于NALU詳細可以參考：萬字長文詳解 H.264 編碼原理與 NALU 格式:走進視頻壓縮世界_h264-CSDN博客

關鍵問題：

• 一個 NALU 可能非常大（如 1080P 的 I 幀可達 200KB），而 UDP 包最大負載約 1500 字節（MTU限制），必須分片傳輸；
• 多個小 NALU（如 SPS、PPS、SEI）可以合并成一個 RTP 包，減少傳輸開銷。

（二）RTP 封包策略

RTP 封裝 H.264 的核心是將 NALU 適配到網絡傳輸單元，主要有三種模式：

1. 單一 NALU 模式（Single NALU Packet）

• 適用場景：NALU 大小 ≤ 1400 字節（如 P 幀、B 幀、SPS/PPS）。
• 封包結構：

  RTP頭（12字節） + NALU頭（1字節） + NALU負載  
  

  ?
  • 示例：SPS（25 字節）直接封裝為一個 RTP 包，RTP 頭的PT取H.264 負載類型。
• 優勢：簡單高效，接收端無需重組；
• 局限：無法處理大 NALU（如 I 幀）。

2. 組合包模式（Aggregation Packet）

將多個小 NALU 合并到一個 RTP 包中，分為兩種類型：

• STAP-A（單時間聚合包）：
  • 適用場景：同一時間生成的多個小 NALU（如 SPS+PPS+SEI）。
  • 封包結構：

    RTP頭 + STAP-A頭（1字節） + [NALU長度（2字節） + NALU頭 + NALU負載] × N  
    

    ?
    • STAP-A 頭：Type=24，保留 F 和 NRI 與第一個 NALU 一致。
  • 示例：WebRTC 中常將 SPS 和 PPS 封裝在一個 STAP-A 包中，減少首幀延遲（WebRTC實際數據流傳輸也是RTP包）。
• MTAP（多時間聚合包）：
  • 適用場景：不同時間生成的 NALU（如跨幀的 SEI）。
  • 復雜點：需記錄每個 NALU 的時間戳偏移（如 MTAP16 用 16 位存儲偏移量）。

3. 分片模式（Fragmentation Unit）

將大 NALU 拆分為多個 RTP 包，核心是FU-A 分片單元：

• 適用場景：NALU > 1400 字節（如 1080P 的 I 幀）。
• 封包結構：

  RTP頭 + FU指示符（1字節） + FU頭（1字節） + NALU分片負載  
  

  ?
  • FU 指示符：
    • 前 3 位保留 F 和 NRI，與原始 NALU 頭一致；
    • Type=28（FU-A 類型）。
  • FU 頭：
    • S（1 位）：分片開始標志（僅第一個包為 1）；
    • E（1 位）：分片結束標志（僅最后一個包為 1）；
    • R（1 位）：保留位（0）；
    • Type（5 位）：原始 NALU 的 Type（如5=IDR幀）。
• 分片示例：
  • 一個 200KB 的 IDR 幀被拆分為 145 個 RTP 包，第一個包S=1,E=0，最后一個包S=0,E=1。

這里對FU指示符和FU頭展開解釋一下：

FU指示符（FU indication）

+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI|   Type  |
+---------------+

+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R|  Type   |
+---------------+

?RTCP（Real-time Transport Control Protocol，實時傳輸控制協議）是 RTP 的 “孿生兄弟”——RTP 負責 “送貨”（傳輸媒體數據），RTCP 則負責 “監控物流”（反饋質量、同步時鐘、管理會話）。RTCP與RTP聯合?作，RTP實施實際數據的傳輸，RTCP則負責將控制包送?參與中的每個?。其主要功能是就RTP正在提供的服務質量做出反饋。

要注意的是，RTCP 不直接描述單個 RTP 包，它描述的是整個發送方或接收方的狀態以及一段時間內的統計信息。關聯性通過?SSRC?和?時間窗口?來實現。

(一）RTCP 的核心功能

RTCP 的設計目標是為 RTP 傳輸提供 “雙向溝通機制”，核心功能可概括為四類：

1. 質量反饋：接收端通過 RTCP 向發送端報告丟包率、延遲抖動等數據，發送端據此調整碼率或重傳策略（比如視頻會議中卡頓后自動降低清晰度）。
2. 時鐘同步：通過 NTP（網絡時間協議）時間戳將不同媒體流（如音頻、視頻）對齊到同一時間軸，解決 “唇音不同步” 問題。
3. 會話管理：標識參與者身份（如用戶名、設備 ID），并處理加入 / 離開會話的通知（比如直播中觀眾退出時發送信號）。
4. 擴展能力：支持自定義消息（如傳輸額外的元數據），為特殊場景（如 VR 直播的姿態數據）預留擴展空間。

傳輸特性：RTCP 與 RTP 共用 UDP 端口對，RTCP 端口固定為 “RTP 端口 + 1”（如 RTP 用 5004，則 RTCP 用 5005）。

(二) RTCP 報文類型

RTCP 通過 5 種報文類型實現上述功能，每種報文都有統一的頭部格式和專屬的 payload 結構：

1. 發送方報告（SR）

SR 由媒體發送端（如攝像頭）定期發送，包含自身的發送統計和時鐘信息，是同步音視頻的關鍵。

結構解析（共 28 字節起）：

• 固定頭部：版本（V=2）、填充位（P）、報告數（RC，最多 31 個）；
• 核心字段：
  • NTP 時間戳（64 位?符號整數）：當前（報告發出）的絕對時間（如2024-05-20 12:00:00.123），用于跨設備同步（該時間戳的?32 bites以NTP格式表示，從1900年1?1?開始計數，以秒為單位。低32 bites表示秒后?的?數。如果需要轉化Unix時間到NTP時間，在Unix時間加上2,208,988,800即可。）；
  • RTP 時間戳（32 位）：與 RTP 包中時間戳同源（如視頻 90kHz 時鐘下的計數）；
  • 時間戳 (NTP Timestamp,?RTP Timestamp) 在 SR 中協同工作，提供媒體時鐘與掛鐘時間的映射關系。
  • 發送統計：表示這個同步源從這個會話開始到現在總發包數、總字節數（用于計算碼率）。

實例：某攝像頭的 SR 顯示 “NTP 時間 = 1629408000.123，RTP 時間 = 12345678，總發包數 = 1000”，接收端可據此計算 “1 個 RTP 時間單位≈多少毫秒”，實現時鐘對齊。

2. 接收方報告（RR）

RR 由媒體接收端（如播放器）發送，反饋 RTP 包的接收質量，幫助發送端調整策略。

結構解析（共 24 字節起）：

• 固定頭部：與 SR 相同，RC 表示反饋的發送源數量；
• 報告塊（每個 32 字節）：
  • 丟包率（8 位）：0~255 表示 0~100%（如 64=25% 丟包）；
  • 累計丟包數（24 位）：從會話開始至今丟失的總包數；
  • 抖動（32 位）：網絡延遲波動的統計值（值越大，畫面越可能卡頓）；
  • 最后接收的 SR 時間（LSR）：用于計算往返延遲。

實例：播放器發送 RR，丟包率 = 128（50%），抖動 = 100ms，發送端收到后可能降低碼率或啟用 FEC（前向糾錯）。

3. 源描述報告（SDES）

SDES 用于傳遞會話參與者的元信息，確保多方通信時能識別彼此。

必選字段：

• CNAME（規范名）：唯一且永久的標識（如user123@domain.com），即使設備重啟（SSRC 變化）也能關聯到同一用戶；
• 可選字段：NAME（昵稱）、EMAIL（郵箱）、PHONE（電話）等。

實例：視頻會議中，SDES 報文攜帶 “CNAME=alice@company.com，NAME=Alice”，其他參與者能在界面顯示 “Alice 正在發言”。

4. 離開通知（BYE）

當設備退出會話（如關閉播放器、斷網），BYE 報文會通知其他參與者 “我已離開”，避免資源浪費。

結構：包含退出的 SSRC 列表，可選 “離開原因”（如 “用戶主動退出”）。

注意：BYE 可能丟失（如網絡中斷），接收端需通過 “超時未收到 RTP/RTCP” 判斷對方離線。

5. 應用自定義（APP）

APP 允許應用自定義消息格式，用于標準 RTCP 未覆蓋的場景（如 VR 直播中的設備姿態同步）。

結構：4 字節 ASCII 標識（如 “VRTP”）+ 自定義數據，接收端不認識的 APP 報文會被忽略。

四、總結一下RTP和RTCP如何協同

（一）RTCP 如何“描述” RTP 數據？

• SSRC?(Synchronization Source Identifier) 是核心紐帶：

  • 每個 RTP 流（通常來自一個源，如攝像頭或麥克風）在 RTP 會話中被分配一個唯一的 32 位?SSRC?標識符。

  • 這個?SSRC?值出現在每個屬于該流的 RTP 包的頭部。

  • 關鍵的關聯點：?RTCP 數據包（特別是 Sender Report - SR 和 Receiver Report - RR）也包含這個?SSRC?標識符。

  • 因此，接收端收到一個 RTCP SR 包時，它看到包里的?SSRC = X，就知道這個報告描述的是所有?SSRC = X?的 RTP 包的發送方狀態（在 SR 中）或者接收方對該流的接收狀態（在 RR 中）。

• 時間窗口：

  • RTCP 報告（SR/RR）不是為單個 RTP 包生成的。它們周期性地發送（通常每 5 秒左右，或至少占會話帶寬的 5%）。

  • SR 報告包含發送方在上一個報告間隔期間發送的所有 RTP 包的累積統計信息（發送的包總數、發送的字節總數）。

  • RR 報告包含接收方在上一個報告間隔期間接收到的來自特定?SSRC（在 RR 塊中指定）的所有 RTP 包的累積統計信息（如丟包數、累計丟包數、最高接收序列號、抖動等）。

• 序列號 (sequence number) 的作用：

  • 每個 RTP 包都有一個單調遞增的 16 位序列號。

  • RTCP RR 報告中包含?extended highest sequence number received（接收到的最高序列號的擴展形式）和?cumulative number of packets lost（累計丟包數）。

  • 接收端通過比較預期應接收到的序列號范圍（基于之前的最高序列號和包間隔）和實際接收到的序列號，可以計算出在報告間隔內的丟包情況。雖然報告是累積的，但結合序列號信息，接收端能知道在哪個大致的序列號范圍內發生了丟包。

• 總結關聯性：?RTCP 通過共享?SSRC?將報告與特定的 RTP 流關聯起來。報告提供的是該流在前一個時間窗口內的整體發送或接收性能的統計摘要，而不是針對單個 RTP 包。接收端利用序列號信息可以推斷出大致的丟包位置。

（二）?RTCP 和 RTP 中的事件戳如何協同控制音視頻同步？

建立媒體時間與真實時間的映射關系

音視頻同步的本質是：讓屬于同一時刻采集的音頻樣本和視頻幀，在播放端也于同一時刻播放出來。問題在于：

• 音頻和視頻是獨立的 RTP 流：它們有各自獨立的?SSRC、獨立的 RTP 序列號、獨立的 RTP 時間戳序列（基于各自的采樣率）。

• RTP 時間戳是相對的：音頻時間戳基于音頻采樣率（如 48000 Hz，每樣本時間戳增量為 1），視頻時間戳基于視頻時鐘頻率（如 90000 Hz，每幀時間戳增量取決于幀率）。兩者單位不同，無法直接比較。

• 設備時鐘不同步：發送端和接收端的系統時鐘（掛鐘時間）可能不同步，且各自存在漂移。

RTCP SR 包 (NTP Timestamp?+?RTP Timestamp) 解決了這個問題！?它為每個獨立的媒體流提供了一個將自身媒體時間戳 (RTP Timestamp) 映射到絕對真實世界時間 (NTP Timestamp) 的基準點。

協同控制音視頻同步的步驟：

假設有一個視頻會議場景，包含一個音頻流 (SSRC_A) 和一個視頻流 (SSRC_V)。

1. 發送端捕獲與標記

   • 當發送端決定為音頻流?SSRC_A?發送一個 SR 包時：

     • 原子性操作：?它瞬間同時完成以下動作：

       • 捕獲當前 NTP 時間 (NTP_TS_A):?獲取精確的掛鐘時間（理想情況下與 NTP 服務器同步）。

       • 捕獲當前音頻 RTP 時間戳 (RTP_TS_A):?讀取此刻音頻采樣時鐘計數器的值。這個值代表了捕獲設備在?NTP_TS_A?這個絕對時間點正在處理的音頻樣本的時間戳。

   • 同樣，當為視頻流?SSRC_V?發送 SR 包時：

     • 原子性操作：?瞬間同時捕獲：

       1. 捕獲當前 NTP 時間 (NTP_TS_V)。?(注意：NTP_TS_A?和?NTP_TS_V?可能不同，因為 SR 發送時間不同)

       2. 捕獲當前視頻 RTP 時間戳 (RTP_TS_V)。

2. 發送端打包 SR:

   • 對于音頻 SR (SSRC_A): 將?NTP_TS_A?和?RTP_TS_A?打包進 SR 包發送。

   • 對于視頻 SR (SSRC_V): 將?NTP_TS_V?和?RTP_TS_V?打包進 SR 包發送。

3. 接收端接收與計算映射關系?

   • 接收端收到音頻流的 SR (SSRC_A)：

     • 記錄?NTP_TS_A?(發送端在發送此 SR 時的絕對時間)。

     • 記錄?RTP_TS_A?(在?NTP_TS_A?時刻，音頻流的媒體時間戳)。

     • 建立音頻流映射：?RTP_TS_A?(音頻時間) <==>?NTP_TS_A?(絕對時間)

   • 接收端收到視頻流的 SR (SSRC_V)：

     • 記錄?NTP_TS_V。

     • 記錄?RTP_TS_V。

     • 建立視頻流映射：?RTP_TS_V?(視頻時間) <==>?NTP_TS_V?(絕對時間)

   • 關鍵點：?接收端現在知道如何把音頻時間戳轉換成絕對時間，也知道如何把視頻時間戳轉換成絕對時間。絕對時間 (NTP Timestamp) 成為了一個公共的、統一的時間軸！

4. 接收端同步播放：

   • 假設接收端要播放一個音頻包：

     • 該音頻包有自己的 RTP 時間戳?audio_ts。

     • 接收端利用音頻流的映射關系?(RTP_TS_A?<==>?NTP_TS_A)，計算出?audio_ts?對應的絕對時間?target_ntp_audio。計算原理：

       • 計算音頻時間差：delta_audio_ts = audio_ts - RTP_TS_A

       • 計算對應的絕對時間差 (基于音頻采樣率)：delta_ntp = delta_audio_ts / audio_sample_rate?(例如?audio_sample_rate = 48000)

       • 目標絕對時間：target_ntp_audio = NTP_TS_A + delta_ntp

   • 假設接收端要播放一個視頻幀：

     • 該視頻幀有自己的 RTP 時間戳?video_ts。

     • 接收端利用視頻流的映射關系?(RTP_TS_V?<==>?NTP_TS_V)，計算出?video_ts?對應的絕對時間?target_ntp_video。計算原理：

       • 計算視頻時間差：delta_video_ts = video_ts - RTP_TS_V

       • 計算對應的絕對時間差 (基于視頻時鐘頻率)：delta_ntp = delta_video_ts / video_clock_rate?(例如?video_clock_rate = 90000)

       • 目標絕對時間：target_ntp_video = NTP_TS_V + delta_ntp

   • 同步決策：

     • 播放器有一個統一的播放時間軸，基于接收端本地估算的 NTP 時間?(接收端本地時鐘最好也同步到 NTP)。

     • 播放器計算當前本地估算的 NTP 時間?current_ntp_local。

     • 對于即將播放的音頻樣本和視頻幀：

       • 它計算音頻樣本的目標絕對時間?target_ntp_audio。

       • 它計算視頻幀的目標絕對時間?target_ntp_video。

       • 播放準則：?當?current_ntp_local?達到或略晚于?target_ntp_audio?時，播放該音頻樣本；當?current_ntp_local?達到或略晚于?target_ntp_video?時，播放該視頻幀。

     • 效果：?因為?target_ntp_audio?和?target_ntp_video?都是根據發送端同一個物理時刻（分別由各自的 SR 捕獲）映射出來的絕對時間，所以原本在發送端同一物理時刻采集的音頻和視頻，它們的?target_ntp?值會非常接近（理想情況下相等）。播放器在相同的?current_ntp_local?時間播放它們，就實現了音畫同步！

想象兩個跑步者（音頻流和視頻流）在不同的跑道上（不同的時間戳序列）。裁判（發送端）在特定時刻（NTP_TS_A/V）分別記錄下他們各自跑了多遠（RTP_TS_A/V）。在終點（接收端），另一個裁判根據這些記錄，可以推算出兩個跑步者在裁判記錄的那個共同時刻各自的位置。這樣，終點裁判就能知道，當第一個跑步者到達某個位置時（某個音頻時間戳），第二個跑步者應該在哪里（對應的視頻時間戳），從而判斷他們是否“齊頭并進”（音畫同步）。

五、RTSP協議

（一）RTSP 是什么：不止于 “傳輸” 的控制協議

RTSP 是一種基于文本的應用層協議，語法類似 HTTP，但專為實時媒體控制設計。它的核心作用是：

• 協調會話：讓客戶端（如播放器）和服務器（如直播服務器）達成共識（如媒體格式、傳輸方式）；
• 控制流傳輸：通過 “播放”“暫停”“錄制” 等指令管理 RTP 流（音視頻數據由 RTP 實際傳輸）；
• 維護狀態：全程跟蹤會話進度（如當前播放位置、傳輸端口），類似打電話時保持通話狀態。

一句話總結：RTSP 是 “指揮官”，RTP 是 “運輸兵”，前者發號施令，后者運送數據。

（二）RTSP 與 HTTP：看似相似，實則不同

RTSP 常被比作 “HTTP 的親戚”，但兩者在核心機制上有本質區別：

舉例：用 RTSP 看直播時，你可以隨時發送 “暫停” 指令，服務器會記住當前播放位置；而用 HTTP 下載視頻，暫停后需重新請求，服務器不會保留你的進度。

（三）推流流程：如何把視頻 “上傳” 到服務器？

推流（如主播直播）是將本地音視頻通過 RTSP 發送到服務器的過程，核心步驟分六步：

1. 第一步：OPTIONS——“問問服務器支持啥功能”

• 客戶端→服務器：發送OPTIONS請求，詢問服務器支持哪些操作（如能否錄制、能否暫停）。

• 服務器→客戶端：回復Public字段，列出支持的方法（如OPTIONS, DESCRIBE, RECORD等）。

• 作用：避免客戶端發送服務器不支持的指令，浪費資源。

2. 第二步：ANNOUNCE——“告訴服務器我要發啥”

• 客戶端→服務器：發送ANNOUNCE請求，攜帶 SDP（會話描述協議）信息，說明要推的媒體格式（如視頻用 H.264、音頻用 AAC）、采樣率等。

• 服務器→客戶端：回復確認，并返回Session ID（會話標識，后續操作需攜帶）。

• 作用：讓服務器提前準備好接收特定格式的媒體流。

3. 第三步：SETUP——“約定傳輸通道”

• 客戶端→服務器：發送SETUP請求，指定傳輸方式（如 UDP）和客戶端端口（如 RTP 用 31590，RTCP 用 31591）。

• 服務器→客戶端：回復確認，告知服務器端口（如 RTP 用 59472），并綁定Session ID。

• 細節：如果推流包含視頻和音頻，需分別SETUP（各自用獨立端口）。
• 作用：打通客戶端和服務器的 “數據高速公路”，確保 RTP 流能準確傳輸。

4. 第四步：RECORD——“推流開始”

• 客戶端→服務器：發送RECORD請求，指令服務器開始接收 RTP 流。

• 服務器→客戶端：回復確認，開始等待 RTP 數據。

• 作用：正式啟動推流，此時客戶端會通過 RTP 端口發送音視頻數據。

5. 第五步：RTP 傳輸 ——“數據真正開始流動”

• 客戶端通過SETUP約定的 UDP 端口，持續發送 RTP 包（視頻用一個端口，音頻用另一個）。

?

• 同時定時發送 RTCP 包反饋傳輸質量（如丟包率），服務器據此調整策略。

6. 第六步：TEARDOWN——“結束會話”

• 客戶端→服務器：發送TEARDOWN請求，告知 “推流結束”。

• 服務器→客戶端：回復確認，釋放端口和會話資源。

• 作用：優雅關閉連接，避免資源浪費。

總結：

（四）拉流流程：如何從服務器 “拉取” 視頻？

拉流（如觀眾看直播）是客戶端從服務器獲取媒體流的過程，步驟與推流類似，但部分關鍵指令不同：

舉例：拉流時，DESCRIBE就像觀眾問 “你這有什么節目？”，服務器用 SDP 回復 “有 H.264 視頻和 AAC 音頻”；PLAY則像說 “開始播放吧”，服務器隨后通過 RTP 發送數據。

（五）總結

1. Session ID：

• 由服務器在ANNOUNCE或SETUP時生成（如ditmIrW4Z20X），后續所有操作必須攜帶。
• 作用：服務器通過它識別 “哪個客戶端在操作哪個流”，避免混淆。

2. Transport 字段：

格式示例：Transport: RTP/AVP/UDP;unicast;client_port=31590-31591;server_port=59472-59473

• RTP/AVP：用 RTP 傳輸，采用 AVP（音頻視頻配置文件）；
• unicast：單播（一對一傳輸）；
• client_port/server_port：客戶端和服務器的 RTP/RTCP 端口對（RTP 用前一個，RTCP 用后一個）。
• 作用：明確數據走哪條 “路”，用什么 “規則” 傳輸。

3. CSeq：

• 每個 RTSP 請求 / 響應都有一個遞增的序列號（如CSeq: 1、CSeq: 2）。
• 作用：匹配請求和響應（避免混亂），比如客戶端發CSeq:3的請求，服務器必須用CSeq:3回復。

4. SDP協議作用（key-value）：

• 包含媒體類型（視頻 / 音頻）、編碼格式（H.264/AAC）、采樣率等關鍵信息。
• 推流時由客戶端通過ANNOUNCE發送，拉流時由服務器通過DESCRIBE返回。
• 作用：讓雙方對 “要傳輸的媒體是什么樣的” 達成共識。