rtp包抖動計算公式_關于RTSP_RTP_RTCP協定的深刻初步介紹

前記

作為一個軟體工程師，特别是偏向安防應用或者網際網路對接，都應該聽說RTSP，RTP，RTCP等協定的概念。本篇博文詳細介紹一下關于RTSP等協定，讓讀者更加友善的了解透徹。另外後續還會從RTSP的應用方面繼續編寫。

三個協定簡單描述

RTSP（Real Time Streaming Protocol），RFC2326，實時流傳輸協定，是TCP/IP協定體系中的一個應用層協定，由哥倫比亞大學、網景和RealNetworks公司送出的IETF RFC标準。該協定定義了一對多應用程式如何有效地通過IP網絡傳送多媒體資料。RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或UDP完成資料傳輸。

Real-time Transport Protocol或簡寫RTP，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的。RTP協定詳細說明了在網際網路上傳遞音頻和視訊的标準資料包格式。它是建立在UDP協定上的。

Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP）是實時傳輸協定（RTP）的一個姐妹協定。RTCP由RFC 3550定義（取代廢棄的RFC 1889）。RTP 使用一個 偶數 UDP port ；而RTCP 則使用 RTP 的下一個 port，也就是一個奇數 port。RTCP與RTP聯合工作，RTP實施實際資料的傳輸，RTCP則負責将控制包送至電話中的每個人。其主要功能是就RTP正在提供的服務品質做出回報。

簡單的說，以上三個協定就是負責以下圖檔内容：

三個協定其實相輔相成，隻是讀完簡單介紹其實并不能深刻了解其協定的深刻内涵或者使用方法以及其架構。下面我們對其協定進行詳細拆分深刻挖掘。

RTP詳解

背景知識：

流（Streaming）是近年在Internet上出現的新概念，其定義非常廣泛，主要是指通過網絡傳輸多媒體資料的技術總稱。

流式傳輸分為兩種

• • 順序流式傳輸 (Progressive Streaming)
  • 實時流式傳輸 (Real time Streaming)

實時流式傳輸是實時傳送，特别适合現場事件。“實時”（real time）是指在一個應用中資料的傳遞必須與資料的産生保持精确的時間關系，這需要相應的協定支援，這樣RTP和RTCP就相應的出現了

RTP協定原理：

較簡單，負責對流媒體資料進行封包并實作媒體流的實時傳輸，即它按照RPT資料包格式來封裝流媒體資料，并利用與它綁定的協定進行資料包的傳輸。

RTP在端口号1025到65535之間選擇一個未使用的偶數UDP端口号，而在同一次會話中的RTCP則使用下一個基數UDP端口号。RTP預設端口号5004，是以RTCP端口号預設為5005，姊妹協定背景有說。

從下圖可看出RTP被劃分在傳輸層，它建立在UDP上。同UDP協定一樣，

為了實作其實時傳輸功能，RTP也有固定的封裝形式。RTP用來為端到端的實時傳輸提供時間資訊和流同步，但并不保證服務品質。服務品質由RTCP來提供。

RTP協定封裝

詳細見下：

• 填充位（1bit）若p=1則在該封包的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分。填充可能用于某些具有固定長度的加密算法或者用在底層資料單元中傳輸多個RTP包
• 擴充（X）：1個比特，置“1”表示RTP報頭後緊随一個擴充報頭
• 參與源數（CSRC計數（CC） ）4位，CSRC計數包括緊接在固定頭後CSRC辨別符個數。
• 标記（M）：1個比特，其具體解釋由應用文檔來定義。例如，對于視訊流，它表示一幀的結束，而對于音頻，則表示一次談話的開始
• 有效載荷類型，7個比特，它訓示在使用者資料字段中承載資料的載荷類别，記錄後面資料使用哪種編碼，接收端找出相應的 decoder 解碼出來。

音頻：μ律PCM(0),GMS(3)

A律PCM(8),G.722(9),G728(1)

視訊：活動JPEG(26)、H.261(31)、

MPEG1(32)、MPEG2(33)等

• 序列号16比特 每發送一個RTP資料包,序列号加一,接收機可以據此檢測包損和重建包序列.序列号的初始值是随機的(不可預測),以使即便在源本身不加密時(有時包要通過翻譯器,它會這樣做),對加密算法泛知的普通文本攻擊也會更加困難
• 時間戳，32位，時标反映RTP資料包中第一個八進制數的采樣時刻，采樣時刻必須從單調、線性增加的時鐘導出，以允許同步與抖動計算。時标可以讓receiver端知道在正确的時間将資料播放出來。 隻有系列号而沒有時标，并不能完整按照順序的将data播放出來，因為如果data中間有一段是沒有資料的，隻有系列号的話會造成錯誤.
• SSRC ，32位，SSRC段辨別同步源。此辨別不是随機選擇的，目的在于使同一RTP包連接配接中沒有兩個同步源有相同的SSRC辨別。盡管多個源選擇同一個辨別的機率很低，所有RTP實作都必須探測并解決沖突。
• CSRC清單，0到15項，每項32位。CSRC清單表示包内的對載荷起作用的源。辨別數量由CC段給出。如超出15個作用源，也僅辨別15個。

RTCP協定詳解

RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制資訊，因而分組很短，是以可以将多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組類型。

RTCP協定詳細拆解：

1、SR：

發送端報告包，用于發送和接收活動源的統計資訊；

發送端報告分組SR（Sender Report）用來使發送端以多點傳播方式向所有接收端報告發送情況。SR分組的主要内容有：相應的RTP流的SSRC，RTP流中最新産生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的位元組數。SR包的封裝如下圖所示：

• 版本（V）：同RTP標頭域。
• 填充（P）：同RTP標頭域
• 接收報告計數器（RC）：5比特，該SR包中的接收報告塊的數目，可以為零。
• 包類型（PT）：8比特，SR包是200。

• 長度域（Length）：16比特，其中存放的是該SR包以32比特為機關的總長度減一。
• 同步源（SSRC of sender）：SR包發送者的同步源辨別符。與對應RTP包中的SSRC一樣。
• NTP Timestamp（Network time protocol）SR包發送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。
• RTP Timestamp：與NTP時間戳對應，與RTP資料包中的RTP時間戳具有相同的機關和随機初始值。
• Sendr’s packet count：從開始發送包到産生這個SR包這段時間裡，發送者發送的RTP資料包的總數. SSRC改變時，這個域清零。
• Sender`soctet count：從開始發送包到産生這個SR包這段時間裡，發送者發送的淨荷資料的總位元組數（不包括頭部和填充）。發送者改變其SSRC時，這個域要清零。
• 同步源n的SSRC辨別符：該報告塊中包含的是從該源接收到的包的統計資訊。
• 丢失率（Fraction Lost）：表明從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP資料包的丢失率。
• 累計的包丢失數目：從開始接收到SSRC_n的包到發送SR,從SSRC_n傳過來的RTP資料包的丢失總數。
• 收到的擴充最大序列号：從SSRC_n收到的RTP資料包中最大的序列号，
• 接收抖動（Interarrival jitter）：RTP資料包接受時間的統計方差估計
• 上次SR時間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。
• 上次SR以來的延時（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到發送本報告的延時。

2、RR：

接收者報告包，用于接收非活動站的統計資訊；

3、SDES：

源描述包，用于報告和站點相關的資訊，包括CNAME；

4、BYE：

斷開RTCP包，是站點離開系統的報告，表示結束；

5、APP：

應用特定函數。

RTP&&RTCP的協定關鍵技術 ：

時間戳

時間戳字段是RTP首部中說明資料包時間的同步資訊，是資料能以正确的

時間順序恢複

的關鍵。時間戳的值給出了分組中資料的第一個位元組的采樣時間，要求發送方時間戳的時鐘是

連續、單調增長

的，即使在沒有資料輸入或發送資料時也是如此。在靜默時，發送方不必發送資料，保持時間戳的增長，在接收端，由于接收到的資料分組的序号沒有丢失，就知道沒有發生資料丢失，而且隻要比較前後分組的時間戳的差異，就可以确定輸出的時間間隔。

RTCP 中的 SR (Sender Report發送端報告）控制分組包含NTP（網絡時間）時間戳和RTP時間戳可用于同步音視訊媒體流。

RTP時間戳是依據鄰近的RTP資料包中的時間戳結合NTP時間差得到的。

公式表達為：RTP_tsi = tsi + NTPi - NTP'i

RTP_tsi表示RTCP中的RTP時間戳；tsi表示鄰近的RTP包中的時間戳；NTPi表示RTCP的網絡時間戳；NTP'i表示鄰近的RTP包對應的網絡時間戳；下标表示第i個源

是以，i和源j之間的相對時差可以表示為

（RTP_tsi – tsi）-( RTP_tsj - tsj) = (NTPi –NTP'i) - （NTPj—NTP'j）

由于NTP同步，內插補點可以反映出兩個源的相對時差。因為要同步不同來源的媒體流，必須使得同步他們的絕對時間基準，而NTP時間戳正是這樣的絕對時間基準。應用RTP時間戳來保證同一來源的媒體流同步

時延:

影響時延的因素有多個方面：

• • • 編解碼
    • 網絡
    • 防抖動緩沖
    • 封包隊列

其中有些是固定時延，如編解碼網絡速率等；有些是變化的，如防抖動緩沖等，固定的時延可以通過改變編解碼方式和提高網絡速率來改變，而變化時延通常采用提高轉發效率來提高。

抖動

到達時刻

抖動J的定義

：一對包中接收機相對發射機的時間跨度內插補點的平均偏差。

該值等于兩個包相對傳輸時間的內插補點，相對傳輸時間是指包的RTP時間标志和到達時刻接收機時鐘，以同一機關的內插補點.若Si是包i的RTP時間标志，Ri是包i以RTP時間标志機關的到達時刻值。對于兩個包i和j，D可以表達為

D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)

到達時刻抖動可以在收到從源SSRC_n來的每個資料包i後連續計算,利用該包和前一包i-1的偏差D。

根據公式J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16計算

丢包率

丢包率是通過計算接收包數量和發送包數量的比率得到。

發送方：每間隔一定時間讀取每個發送通道的發包數量和資料長度，組成一個此通道的RTCP封包發送給接收方，同時将發送資料包計數清零。

接收方：收到RTCP包後，讀取接收通道接收到的包數量，并計算出丢包率，通過一個RTCP接收彙報包發送給發送方，同時對接收資料包計數清零

RTSP協定：

RTSP(Real-Time Stream Protocol)協定是一個基于文本的多媒體播放控制協定，屬于應用層。RTSP以用戶端方式工作，對流媒體提供播放、暫停、後退、前進等操作。該标準由IETF指定，對應的協定是RFC2326。RTSP作為一個應用層協定，提供了一個可供擴充的架構，使得流媒體的受控和點播變得可能，它主要用來控制具有實時特性的資料的發送，但其本身并不用于傳送流媒體資料，而必須依賴下層傳輸協定(如RTP/RTCP)所提供的服務來完成流媒體資料的傳送。RTSP負責定義具體的控制資訊、操作方法、狀态碼，以及描述與RTP之間的互動操作。RTSP媒體服務協定架構如下：

是以從上述架構圖中可以看出，RTSP和RTP，RTCP配合使用。

RTSP傳輸的一般是TS、MP4格式的流，其傳輸一般需要2~3個通道，指令和資料通道分離。使用RTSP協定傳輸流媒體資料需要有專門的媒體播放器和媒體伺服器，也就是需要支援RTSP協定的用戶端和伺服器。

用戶端要播放RTSP媒體流，就需要知道媒體源的URL，RTSP的URL格式一般如下：

rtsp://host[:port]/[abs_path]/content_name

host: 有效的域名或IP位址；

port: 端口号，預設為554，若為預設可不填寫，否則必須寫明。

例如，一個完整的RTSP URL可寫為：

rtsp://192.168.1.67:554/test

又如目前市面上常用的海康網絡攝像頭的RTSP位址格式為：

rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream

示例rtsp://admin:[email protected]:554/h264/ch1/main/av_stream

RTSP是一種基于文本的協定，用CRLF(回車換行)作為每一行的結束符，其好處是，在使用過程中可以友善地增加自定義參數，也友善抓包分析。從消息傳送方向上來分，RTSP的封包有兩類：請求封包和響應封包。請求封包是指從用戶端向伺服器發送的請求(也有少量從伺服器向用戶端發送的請求)，響應封包是指從伺服器到用戶端的回應。RTSP請求封包的常用方法與作用：

一次基本的RTSP互動過程如下，C表示用戶端，S表示服務端。

首先用戶端連接配接到流媒體伺服器并發送一個RTSP描述請求(DESCRIBE request)，伺服器通過一個SDP(Session DescriptionProtocol)描述來進行回報(DESCRIBEresponse)，回報資訊包括流數量、媒體類型等資訊。用戶端分析該SDP描述，并為會話中的每一個流發送一個RTSP連接配接建立請求(SETUPrequest)，該指令會告訴伺服器用于接收媒體資料的端口，伺服器響應該請求(SETUP response)并建立連接配接之後，就開始傳送媒體流(RTP包)到用戶端。在播放過程中用戶端還可以向伺服器發送請求來控制快進、快退和暫停等。最後，用戶端可發送一個終止請求(TEARDOWN request)來結束流媒體會話。

而實際使用中還會用到兩個協定

，SIP 和SDP

SIP協定

SIP（Session Initiation Protocol，會話初始協定）是由IETF（Internet Engineering Task Force，網際網路工程任務組）制定的多媒體通信協定。

它是一個基于文本的應用層控制協定，用于建立、修改和釋放一個或多個參與者的會話。SIP 是一種源于網際網路的IP 語音會話控制協定，具有靈活、易于實作、便于擴充等特點。SIP協定用于兩個或多個端點之間的網際網路電話和多媒體分發。例如，一個人可以使用SIP發起對另一個人的電話呼叫，或者有人可以與許多參與者建立電話會議。SIP協定的設計非常簡單，配置有限的指令。它也是基于文本的，是以任何人都可以讀取SIP會話中的端點之間傳遞的SIP消息。

有一些實體幫助SIP建立其網絡。在SIP中，每個網元由

SIP URI

（統一資源辨別符）來辨別，它像一個位址。以下是網絡元素

• 使用者代理
• 代理伺服器
• 注冊伺服器
• 重定向伺服器
• 位置伺服器

使用者代理

它是SIP網絡的端點和最重要的網絡元素之一。端點可以啟動，修改或終止會話。使用者代理是SIP網絡中最智能的裝置或網絡元件。它可以是軟電話，手機或筆記本電腦。

使用者代理在邏輯上分為兩部分 -

• 使用者代理用戶端（UAC） - 發送請求并接收響應的實體。
• 使用者代理伺服器（UAS） - 接收請求并發送響應的實體。

SIP基于客戶機 - 伺服器架構，其中呼叫者的電話充當發起呼叫的用戶端，被叫方的電話充當響應呼叫的伺服器。

代理伺服器

網絡元素接收來自使用者代理的請求并将其轉發給另一個使用者。

• 基本上代理伺服器的作用就像一個路由器。
• 它有一些智慧來了解SIP請求，并在URI的幫助下發送它。
• 代理伺服器位于兩個使用者代理之間。
• 源和目的地之間最多可以有70個代理伺服器。

有兩種類型的代理伺服器 -

• 無狀态代理伺服器 - 它隻是轉發收到的消息。這種類型的伺服器不存儲任何呼叫或交易的資訊。
• 有狀态代理伺服器 - 這種類型的代理伺服器可以跟蹤收到的每個請求和響應，并且如果需要，可以将來使用它。如果對方沒有響應，它可以重新發送請求。

注冊伺服器

注冊伺服器接受使用者代理的注冊請求。它可以幫助使用者在網絡中進行身份驗證。它将URI和使用者的位置存儲在資料庫中，以幫助同一域内的其他SIP伺服器。

看看下面的示例，顯示SIP注冊的過程。

這裡呼叫者想要向TMC域注冊。是以，它向TMC的Registrar伺服器發送REGISTER請求，并且伺服器在授權用戶端時傳回200 OK響應。

重定向伺服器

重定向伺服器接收請求，并在注冊器建立的位置資料庫中查找請求的預期收件人。重定向伺服器使用資料庫擷取位置資訊，并以3xx（重定向響應）響應給使用者。我們将在本教程的後面讨論響應代碼。

位置伺服器

位置伺服器提供有關呼叫者可能的位置到重定向和代理伺服器的資訊。隻有代理伺服器或重定向伺服器可以聯系位置伺服器。

下圖描繪了每個網絡元素在建立會話中所扮演的角色。

SIP - 系統架構

SIP被構造為分層協定，這意味着其行為根據一組相當獨立的處理階段來描述，隻有每個階段之間的松散耦合。

• SIP的最低層是其 文法和編碼 。其編碼使用增強的 Backus-Naur表格文法 （BNF）來指定。
• 第二層是 傳輸層 。它定義用戶端如何發送請求并接收響應，以及伺服器如何接收請求并通過網絡發送響應。所有SIP元素都包含傳輸層。
• 接下來是 事務層 。事務是由用戶端事務（使用傳輸層）發送到伺服器事務的請求，以及從伺服器事務發送回用戶端的對該請求的所有響應。使用者代理用戶端（UAC）完成的任何任務都将使用一系列事務進行。 無狀态代理 不包含事務層。
• 事務 層上面的 層 稱為事務使用者。除了 無狀态代理 之外，每個SIP實體都是一個事務使用者。

下圖顯示了SIP會話的基本呼叫流程。

以下是對上述呼叫流程的逐漸說明 -

• 發送到代理伺服器的INVITE請求負責啟動會話。
• 代理伺服器發送 100 嘗試 立即響應呼叫者（Alice）以停止INVITE請求的重新發送。
• 代理伺服器在位置伺服器中搜尋Bob的位址。擷取位址後，進一步轉發INVITE請求。
• 此後，Bob手機生成的 180 振鈴 （臨時響應）傳回給愛麗絲。
• 鮑勃拿起手機後一個 200 OK 響應很快産生。
• 一旦 200 OK 到達Alice，Bob 從Alice 收到一個 ACK。
• 同時，會話建立，RTP資料包（會話）從兩端開始流動。
• 會話結束後，任何參與者（Alice或Bob）都可以發送一個 BYE 請求來終止會話。
• BYE 直接從Alice到Bob繞過代理伺服器。
• 最後，Bob發送 200 OK 響應來确認BYE，會話終止。
• 在上述基本呼叫流程中，可以使用三個 事務 （标記為1，2，3）。

完整的呼叫（從INVITE到200 OK）稱為

對話Dialog

。

上述的架構中可以看出是SIP在先，RTP在後。下面再說一下SDP協定

SDP協定

SDP（Session Description Protocol）是一個用來描述多媒體會話的應用層控制協定，它是一個基于文本的協定，用于會話建立過程中的媒體類型和編碼方案的協商等。

Sdp是描述一個會話時SIP消息正文是一個會話描述協定

SDP消息，消息正文格式：

v=0

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

[email protected] (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

m=audio 3458 RTP/AVP 0 96 97

a=rtpmap:0 PCMU

a=rtpmap:96 G726-32/8000

a=rtpmap:97 AMR-WB

m=video 3400 RTP/AVP 98 99

a=rtpmap:98 MPV

a=rtpmap:99 H.261

v=0//該行訓示協定的版本。

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

0行中包含與會話所有者有關的參數

第一個參數表明會話發起者的名稱，該參數可不填寫，如填寫和SIP消息中，from消息頭的内容一緻。

第二個參數為主叫方的會話辨別符。

第三個參數為主叫方會話的版本，會話資料有改變時，版本号遞增。

第四個參數定義了網絡類型，IN表示Internet網絡類型，目前僅定義該網絡類型。

第五個參數為位址類型，目前支援IPV4和IPV6兩種位址類型。

第六個參數為位址：表明會話發起者的IP位址，該位址為信令面的IP位址，信令PDP激活時為手機配置設定。

s=SDP Seminar //表明本次會話的标題，或會話的名稱。

i=A Seminar on the session description protocol//會話的描述

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps//會話的URI，通過該位址可以查閱到會話的更多内容。

[email protected] (Mark Handley)//會話責任人的EMIAL位址

c=IN IP4 224.2.17.12/127

C行包含為多媒體會話而建立的連接配接的資訊，其中指出了真正的媒體流使用的IP位址。

第一個參數為網絡類型，目前僅定義INTERNET網絡類型。用“IN”表示。

第二個參數為位址類型，目前支援兩種位址類型：IPV4和IPV6。

第三個參數為位址，該位址為多媒體流使用的IP位址。

t=2873397496 2873404696//表示會話的開始時間和結束時間。

第一個參數表明會話的開始時間，數字表明從1900年1月1日00：00以來所經過的秒數。

第二個參數表明會話的結束時間，數字表明從1900年1月1日00：00以來所經過的秒數。

m=audio 3458 RTP/AVP 0 96 97

m行又稱媒體行，描述了發送方所支援的媒體類型等資訊。

第一個參數為媒體名稱：表明支援音頻類型。

第二個參數為端口号，表明UE在本地端口為3458上發送音頻流。

第三個參數為傳輸協定，一般為RTP/AVP協定。

四-七參數為所支援的四種淨荷類型編号。

a=rtpmap:0 PCMU

a=rtpmap:96 G726-32/8000

a=rtpmap:97 AMR-WB

a行為媒體的屬性行，以屬性的名稱：屬性值的方式表示。

格式為：a=rtpmap:<淨荷類型><編碼名稱>

淨荷類型0固定配置設定給了PCMU，

淨荷類型96對應的編碼方案為G.726,為動态配置設定的。

淨荷類型97對應的編碼方式為自适應多速率寬帶編碼（AMR-WB），為動态配置設定的。

m=video 3400 RTP/AVP 98 99

m行又稱媒體行，描述了發送方所支援的媒體類型等資訊。

第一個參數為媒體名稱：表明支援視訊類型。

第二個參數為端口号，表明UE在本地端口為3400上發送視訊流。

第三個參數為傳輸協定，一般為RTP/AVP協定。

四、五參數給出了兩種淨荷類型編号

格式為：a=rtpmap:<淨荷類型><編碼名稱>

a=rtpmap:98 MPV

a=rtpmap:99 H.261

淨荷類型98對應的編碼方案為MPV,為動态配置設定的。

淨荷類型97對應的編碼方式為H.261，為動态配置設定的。

總結了解

其實挺煩的！！！

大家沒必要糾結這麼細節的東西，協定終歸是協定

。協定裡面的字段細節不必追究，但是大概使用流程應該清楚。

SIP SDP RTSP RTP RTCP，就像他們出現的順序一樣，他們在實際應用中的啟用也是這個順序：

SIP（一般基于tcp）用于裝置或使用者(準确的說是 Internet endpoints)位址管理、裝置發現并初始化一個Session，并負責傳輸SDP包；而SDP(是一個資源描述協定，與傳輸無關，大多數時候隻能包含到其它協定中作為資源描述，更像是一個規範)包中描述了一個Session中包含哪些媒體資料，邀請的人等等；當需要被邀請的人都通過各自的終端裝置被通知到後，就可以使用RTSP(串流協定，一般基于tcp傳送，主要作用是使用sdp來描述流而非裝置的資訊)來控制特定Media的通信; 最後，若RTSP控制資訊要求開始Video的播放，那麼就開始使用 RTP（或者TCP）實時傳輸資料，

本文很多内容來自網際網路整理，後續會繼續學校live555開源項目，它是一個為流媒體提供解決方案的跨平台的C++開源項目，它實作了對标準流媒體傳輸是一個為流媒體提供解決方案的跨平台的C++開源項目，它實作了對标準流媒體傳輸協定如RTP/RTCP、RTSP、SIP等的支援。

作者水準比較菜，歡迎提建議稽核，thanks~