流媒體協(xié)議介紹(RTP/RTCP/RTSP/RTMP/MMS/HLS)

RTP

? ? ? ? ?Real-time Transport Protocol)是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸層協(xié)議。RTP協(xié)議詳細說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。RTP協(xié)議常用于流媒體系統(tǒng)(配合RTCP協(xié)議),視頻會議和一鍵通(Push to Talk)系統(tǒng)(配合H.323或SIP),使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎(chǔ)。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用,而且它是建立在UDP協(xié)議上的。?

? ? ? ? ?RTP 本身并沒有提供按時發(fā)送機制或其它服務(wù)質(zhì)量(QoS)保證,它依賴于低層服務(wù)去實現(xiàn)這一過程。 RTP 并不保證傳送或防止無序傳送,也不確定底層網(wǎng)絡(luò)的可靠性。 RTP 實行有序傳送, RTP 中的序列號允許接收方重組發(fā)送方的包序列,同時序列號也能用于決定適當(dāng)?shù)陌恢茫纾涸谝曨l解碼中,就不需要順序解碼。

? ? ? RTP 由兩個緊密鏈接部分組成: RTP ― 傳送具有實時屬性的數(shù)據(jù);RTP 控制協(xié)議(RTCP) ― 監(jiān)控服務(wù)質(zhì)量并傳送正在進行的會話參與者的相關(guān)信息。

RTCP

實時傳輸控制協(xié)議(Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP)是實時傳輸協(xié)議(RTP)的一個姐妹協(xié)議。RTCP為RTP媒體流提供信道外(out-of-band)控制。RTCP本身并不傳輸數(shù)據(jù),但和RTP一起協(xié)作將多媒體數(shù)據(jù)打包和發(fā)送。RTCP定期在流多媒體會話參加者之間傳輸控制數(shù)據(jù)。RTCP的主要功能是為RTP所提供的服務(wù)質(zhì)量(Quality of Service)提供反饋。

RTCP收集相關(guān)媒體連接的統(tǒng)計信息,例如:傳輸字節(jié)數(shù),傳輸分組數(shù),丟失分組數(shù),jitter,單向和雙向網(wǎng)絡(luò)延遲等等。網(wǎng)絡(luò)應(yīng)用程序可以利用RTCP所提供的信息試圖提高服務(wù)質(zhì)量,比如限制信息流量或改用壓縮比較小的編解碼器。RTCP本身不提供數(shù)據(jù)加密或身份認證。SRTCP可以用于此類用途。

SRTP & SRTCP

安全實時傳輸協(xié)議(Secure Real-time Transport Protocol或SRTP)是在實時傳輸協(xié)議(Real-time Transport Protocol或RTP)基礎(chǔ)上所定義的一個協(xié)議,旨在為單播和多播應(yīng)用程序中的實時傳輸協(xié)議的數(shù)據(jù)提供加密、消息認證、完整性保證和重放保護。它是由David Oran(思科)和Rolf Blom(愛立信)開發(fā)的,并最早由IETF于2004年3月作為RFC3711發(fā)布。

由于實時傳輸協(xié)議和可以被用來控制實時傳輸協(xié)議的會話的實時傳輸控制協(xié)議(RTP Control Protocol或RTCP)有著緊密的聯(lián)系,安全實時傳輸協(xié)議同樣也有一個伴生協(xié)議,它被稱為安全實時傳輸控制協(xié)議(Secure RTCP或SRTCP);安全實時傳輸控制協(xié)議為實時傳輸控制協(xié)議提供類似的與安全有關(guān)的特性,就像安全實時傳輸協(xié)議為實時傳輸協(xié)議提供的那些一樣。

在使用實時傳輸協(xié)議或?qū)崟r傳輸控制協(xié)議時,使不使用安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議是可選的;但即使使用了安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議,所有它們提供的特性(如加密和認證)也都是可選的,這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協(xié)議時,必須要用到其消息認證特性。

RTSP

? ? ? ??是由Real Networks和Netscape共同提出的。該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP提供了一個可擴展框架,使實時數(shù)據(jù),如音頻與視頻的受控、點播成為可能。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中的數(shù)據(jù)。該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接,為選擇發(fā)送通道,如UDP、多播UDP與TCP提供途徑,并為選擇基于RTP上發(fā)送機制提供方法。

RTSP(Real Time Streaming Protocol)是用來控制聲音或影像的多媒體串流協(xié)議,并允許同時多個串流需求控制,傳輸時所用的網(wǎng)絡(luò)通訊協(xié)定并不在其定義的范圍內(nèi),服務(wù)器端可以自行選擇使用TCP或UDP來傳送串流內(nèi)容,它的語法和運作跟HTTP 1.1類似,但并不特別強調(diào)時間同步,所以比較能容忍網(wǎng)絡(luò)延遲。而前面提到的允許同時多個串流需求控制(Multicast),除了可以降低服務(wù)器端的網(wǎng)絡(luò)用量,更進而支持多方視訊會議(Video Conference)。 因為與HTTP1.1的運作方式相似,所以代理服務(wù)器《Proxy》的快取功能《Cache》也同樣適用于RTSP,并因RTSP具有重新導(dǎo)向功能,可視實際負載情況來轉(zhuǎn)換提供服務(wù)的服務(wù)器,以避免過大的負載集中于同一服務(wù)器而造成延遲。

RTSP 和RTP的關(guān)系

? ? ? ?RTP不象http和ftp可完整的下載整個影視文件,它是以固定的數(shù)據(jù)率在網(wǎng)絡(luò)上發(fā)送數(shù)據(jù),客戶端也是按照這種速度觀看影視文件,當(dāng)影視畫面播放過后,就不可以再重復(fù)播放,除非重新向服務(wù)器端要求數(shù)據(jù)。

? ? ? RTSP與RTP最大的區(qū)別在于:RTSP是一種雙向?qū)崟r數(shù)據(jù)傳輸協(xié)議,它允許客戶端向服務(wù)器端發(fā)送請求,如回放、快進、倒退等操作。當(dāng)然,RTSP可基于RTP來傳送數(shù)據(jù),還可以選擇TCP、UDP、組播UDP等通道來發(fā)送數(shù)據(jù),具有很好的擴展性。它時一種類似與http協(xié)議的網(wǎng)絡(luò)應(yīng)用層協(xié)議。目前碰到的一個應(yīng)用:服務(wù)器端實時采集、編碼并發(fā)送兩路視頻,客戶端接收并顯示兩路視頻。由于客戶端不必對視頻數(shù)據(jù)做任何回放、倒退等操作,可直接采用UDP+RTP+組播實現(xiàn)。

RTP:實時傳輸協(xié)議(Real-time Transport Protocol)?

RTP/RTCP是實際傳輸數(shù)據(jù)的協(xié)議?

RTP傳輸音頻/視頻數(shù)據(jù),如果是PLAY,Server發(fā)送到Client端,如果是RECORD,可以由Client發(fā)送到Server?

整個RTP協(xié)議由兩個密切相關(guān)的部分組成:RTP數(shù)據(jù)協(xié)議和RTP控制協(xié)議(即RTCP)?

RTSP:實時流協(xié)議(Real Time Streaming Protocol,RTSP)?

RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等,顧名思義可以知道起對話和控制作用?

RTSP的對話過程中SETUP可以確定RTP/RTCP使用的端口,PLAY/PAUSE/TEARDOWN可以開始或者停止RTP的發(fā)送,等等?

RTCP:?

RTP/RTCP是實際傳輸數(shù)據(jù)的協(xié)議?

RTCP包括Sender Report和Receiver Report,用來進行音頻/視頻的同步以及其他用途,是一種控制協(xié)議

SDP

會話描述協(xié)議(SDP)為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。

會話目錄用于協(xié)助多媒體會議的通告,并為會話參與者傳送相關(guān)設(shè)置信息。SDP 即用于將這種信息傳輸?shù)浇邮斩恕DP 完全是一種會話描述格式 ― 它不屬于傳輸協(xié)議 ― 它只使用不同的適當(dāng)?shù)膫鬏攨f(xié)議,包括會話通知協(xié)議(SAP)、會話初始協(xié)議(SIP)、實時流協(xié)議(RTSP)、MIME 擴展協(xié)議的電子郵件以及超文本傳輸協(xié)議(HTTP)。

SDP 的設(shè)計宗旨是通用性,它可以應(yīng)用于大范圍的網(wǎng)絡(luò)環(huán)境和應(yīng)用程序,而不僅僅局限于組播會話目錄,但 SDP 不支持會話內(nèi)容或媒體編碼的協(xié)商。

在因特網(wǎng)組播骨干網(wǎng)(Mbone)中,會話目錄工具被用于通告多媒體會議,并為參與者傳送會議地址和參與者所需的會議特定工具信息,這由 SDP 完成。SDP 連接好會話后,傳送足夠的信息給會話參與者。SDP 信息發(fā)送利用了會話通知協(xié)議(SAP),它周期性地組播通知數(shù)據(jù)包到已知組播地址和端口處。這些信息是 UDP 數(shù)據(jù)包,其中包含 SAP 協(xié)議頭和文本有效載荷(text payload)。這里文本有效載荷指的是 SDP 會話描述。此外信息也可以通過電子郵件或 WWW (World Wide Web) 進行發(fā)送。

SDP 文本信息包括:

會話名稱和意圖;

會話持續(xù)時間;

構(gòu)成會話的媒體;

有關(guān)接收媒體的信息(地址等)。

協(xié)議結(jié)構(gòu)

SDP 信息是文本信息,采用 UTF-8 編 碼中的 ISO 10646 字符集。SDP 會話描述如下:(標(biāo)注 * 符號的表示可選字段):

v = (協(xié)議版本)

o = (所有者/創(chuàng)建者和會話標(biāo)識符)

s = (會話名稱)

i = * (會話信息)

u = * (URI 描述)

e = * (Email 地址)

p = * (電話號碼)

c = * (連接信息 ― 如果包含在所有媒體中,則不需要該字段)

b = * (帶寬信息)

一個或更多時間描述(如下所示):

z = * (時間區(qū)域調(diào)整)

k = * (加密密鑰)

a = * (0 個或多個會話屬性行)

0個或多個媒體描述(如下所示)

時間描述

t = (會話活動時間)

r = * (0或多次重復(fù)次數(shù))

媒體描述

m = (媒體名稱和傳輸?shù)刂罚?/p>

i = * (媒體標(biāo)題)

c = * (連接信息 — 如果包含在會話層則該字段可選)

b = * (帶寬信息)

k = * (加密密鑰)

a = * (0 個或多個會話屬性行)

RTMP/RTMPS

RTMP(Real Time Messaging Protocol)實時消息傳送協(xié)議是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸 開發(fā)的開放協(xié)議。

它有三種變種:

1)工作在TCP之上的明文協(xié)議,使用端口1935;

2)RTMPT封裝在HTTP請求之中,可穿越防火墻;

3)RTMPS類似RTMPT,但使用的是HTTPS連接;

? ? ? RTMP協(xié)議(Real Time Messaging Protocol)是被Flash用于對象,視頻,音頻的傳輸.這個協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上.

? ? ? RTMP協(xié)議就像一個用來裝數(shù)據(jù)包的容器,這些數(shù)據(jù)既可以是AMF格式的數(shù)據(jù),也可以是FLV中的視/音頻數(shù)據(jù).一個單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流.這些通道中的包都是按照固定大小的包傳輸?shù)?

MMS

MMS (Microsoft Media Server Protocol),中文“微軟媒體服務(wù)器協(xié)議”,用來訪問并流式接收 Windows Media 服務(wù)器中 .asf 文件的一種協(xié)議。MMS 協(xié)議用于訪問 Windows Media 發(fā)布點上的單播內(nèi)容。MMS 是連接 Windows Media 單播服務(wù)的默認方法。若觀眾在 Windows Media Player 中鍵入一個 URL 以連接內(nèi)容,而不是通過超級鏈接訪問內(nèi)容,則他們必須使用MMS 協(xié)議引用該流。MMS的預(yù)設(shè)埠(端口)是1755

當(dāng)使用 MMS 協(xié)議連接到發(fā)布點時,使用協(xié)議翻轉(zhuǎn)以獲得最佳連接。“協(xié)議翻轉(zhuǎn)”始于試圖通過 MMSU 連接客戶端。 MMSU 是 MMS 協(xié)議結(jié)合 UDP 數(shù)據(jù)傳送。如果 MMSU 連接不成功,則服務(wù)器試圖使用 MMST。MMST 是 MMS 協(xié)議結(jié)合 TCP 數(shù)據(jù)傳送。

如果連接到編入索引的 .asf 文件,想要快進、后退、暫停、開始和停止流,則必須使用 MMS。不能用 UNC 路徑快進或后退。若您從獨立的 Windows Media Player 連接到發(fā)布點,則必須指定單播內(nèi)容的 URL。若內(nèi)容在主發(fā)布點點播發(fā)布,則 URL 由服務(wù)器名和 .asf 文件名組成。例如:mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服務(wù)器名,sample.asf 是您想要使之轉(zhuǎn)化為流的 .asf 文件名。

若您有實時內(nèi)容要通過廣播單播發(fā)布,則該 URL 由服務(wù)器名和發(fā)布點別名組成。例如:mms://windows_media_server/LiveEvents。這里 windows_media_server 是 Windows Media 服務(wù)器名,而 LiveEvents 是發(fā)布點名

HLS

HTTP Live Streaming(HLS)是蘋果公司(Apple Inc.)實現(xiàn)的基于HTTP的流媒體傳輸協(xié)議,可實現(xiàn)流媒體的直播和點播,主要應(yīng)用在iOS系統(tǒng),為iOS設(shè)備(如iPhone、iPad)提供音視頻直播和點播方案。HLS點播,基本上就是常見的分段HTTP點播,不同在于,它的分段非常小。

? ? ? ?相對于常見的流媒體直播協(xié)議,例如RTMP協(xié)議、RTSP協(xié)議、MMS協(xié)議等,HLS直播最大的不同在于,直播客戶端獲取到的,并不是一個完整的數(shù)據(jù)流。HLS協(xié)議在服務(wù)器端將直播數(shù)據(jù)流存儲為連續(xù)的、很短時長的媒體文件(MPEG-TS格式),而客戶端則不斷的下載并播放這些小文件,因為服務(wù)器端總是會將最新的直播數(shù)據(jù)生成新的小文件,這樣客戶端只要不停的按順序播放從服務(wù)器獲取到的文件,就實現(xiàn)了直播。由此可見,基本上可以認為,HLS是以點播的技術(shù)方式來實現(xiàn)直播。由于數(shù)據(jù)通過HTTP協(xié)議傳輸,所以完全不用考慮防火墻或者代理的問題,而且分段文件的時長很短,客戶端可以很快的選擇和切換碼率,以適應(yīng)不同帶寬條件下的播放。不過HLS的這種技術(shù)特點,決定了它的延遲一般總是會高于普通的流媒體直播協(xié)議。

根據(jù)以上的了解要實現(xiàn)HTTP Live Streaming直播,需要研究并實現(xiàn)以下技術(shù)關(guān)鍵點

采集視頻源和音頻源的數(shù)據(jù)

對原始數(shù)據(jù)進行H264編碼和AAC編碼

視頻和音頻數(shù)據(jù)封裝為MPEG-TS包

HLS分段生成策略及m3u8索引文件

HTTP傳輸協(xié)議

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,460評論 6 538
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,067評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,467評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,468評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 72,184評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,582評論 1 325
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,616評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,794評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,343評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 41,096評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,291評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,863評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,513評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,941評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,190評論 1 291
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,026評論 3 396
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 48,253評論 2 375

推薦閱讀更多精彩內(nèi)容