點擊關(guān)注，與你共同成長！

流媒體概述

所謂流媒體是指采用流式傳輸?shù)姆绞皆?Internet 播放的媒體格式。

流媒體又叫流式媒體，它是指商家用一個視頻傳送服務(wù)器把節(jié)目當(dāng)成數(shù)據(jù)包發(fā)出，傳送到網(wǎng)絡(luò)上。

用戶通過解壓設(shè)備對這些數(shù)據(jù)進(jìn)行解壓后，節(jié)目就會像發(fā)送前那樣顯示出來。

流媒體以流的方式在網(wǎng)絡(luò)中傳輸音頻、視頻和多媒體文件的形式。

流媒體文件格式是支持采用流式傳輸及播放的媒體格式。

流式傳輸方式是將視頻和音頻等多媒體文件經(jīng)過特殊的壓縮方式分成一個個壓縮包，由服務(wù)器向用戶計算機(jī)連續(xù)、實時傳送。在采用流式傳輸方式的系統(tǒng)中，用戶不必像非流式播放那樣等到整個文件全部下載完畢后才能看到當(dāng)中的內(nèi)容，而是只需要經(jīng)過幾秒鐘或幾十秒的啟動延時即可在用戶計算機(jī)上利用相應(yīng)的播放器對壓縮的視頻或音頻等流式媒體文件進(jìn)行播放，剩余的部分將繼續(xù)進(jìn)行下載，直至播放完畢。

RTP (Real-time Transport Protocol)

是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸層協(xié)議.RTP 協(xié)議和 RTP 控制協(xié)議 RTCP 一起使用，

而且它是建立在 UDP 協(xié)議上的.

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

RTCP:Real-time Transport Control Protocol 或 RTP Control Protocol或簡寫 RTCP)

實時傳輸控制協(xié)議,是實時傳輸協(xié)議(RTP)的一個姐妹協(xié)議.

注意: RTP 協(xié)議和 RTP控制協(xié)議(RTCP) 一起使用，而且它是建立在UDP協(xié)議上的.

RTSP(Real Time Streaming Protocol)

實時流媒體會話協(xié)議, SDP(會話描述協(xié)議)，RTP(實時傳輸協(xié)議)。

是用來控制聲音或影像的多媒體串流協(xié)議,RTSP提供了一個可擴(kuò)展框架，使實時數(shù)據(jù)，如音頻與視頻的受控、點播成為可能。

媒體數(shù)據(jù)使用rtp,rtcp協(xié)議。一般使用 udp 作為傳輸層。適合IPTV場景。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中的數(shù)據(jù)。該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、多播UDP與TCP提供途徑，并為選擇基于RTP上發(fā)送機(jī)制提供方法傳輸時所用的網(wǎng)絡(luò)通訊協(xié)定并不在其定義的范圍內(nèi)，服務(wù)器端可以自行選擇使用TCP或UDP來傳送串流內(nèi)容，比較能容忍網(wǎng)絡(luò)延遲.

RTSP 與 RTP 最大的區(qū)別在于：RTSP 是一種雙向?qū)崟r數(shù)據(jù)傳輸協(xié)議，它允許客戶端向服務(wù)器端發(fā)送請求，如回放、快進(jìn)、倒退等操作。當(dāng)然，RTSP 可基于 RTP 來傳送數(shù)據(jù)，還可以選擇 TCP、UDP、組播 UDP 等通道來發(fā)送數(shù)據(jù)，具有很好的擴(kuò)展性。它時一種類似與http協(xié)議的網(wǎng)絡(luò)應(yīng)用層協(xié)議.

WebRTC:

web端實現(xiàn)流媒體的協(xié)議。google剛推出WebRTC的時候巨頭們要么冷眼旁觀，要么抵觸情緒很大。使用RTP協(xié)議傳輸。

RTMP(Real Time Messaging Protocol)

Macromedia 開發(fā)的一套視頻直播協(xié)議，現(xiàn)在屬于 Adobe。和 HLS 一樣都可以應(yīng)用于視頻直播，基于TCP不會丟失。

區(qū)別是 RTMP 基于 flash 無法在 iOS 的瀏覽器里播放，但是實時性比 HLS 要好。

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

iOS 代碼里面一般常用的是使用 RTMP 推流，可以使用第三方庫 librtmp-iOS 進(jìn)行推流，librtmp 封裝了一些核心的 API 供使用者調(diào)用RTMP 協(xié)議也要客戶端和服務(wù)器通過“握手”來建立 RTMP Connection，然后Connection上傳輸控制信息。

RTMP 協(xié)議傳輸時會對數(shù)據(jù)格式化，而實際傳輸?shù)臅r候為了更好地實現(xiàn)多路復(fù)用、分包和信息的公平性，發(fā)送端會把Message劃分為帶有 Message ID的Chunk，每個Chunk可能是一個單獨的Message，也可能是Message的一部分，在接受端會根據(jù)Chunk中包含的data的長度，message id和message的長度把chunk還原成完整的Message，從而實現(xiàn)信息的收發(fā)。

HLS(HTTP Live Streaming)

是蘋果公司(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)了直播。

由此可見，基本上可以認(rèn)為，HLS 是以點播的技術(shù)方式來實現(xiàn)直播。由于數(shù)據(jù)通過 HTTP 協(xié)議傳輸，所以完全不用考慮防火墻或者代理的問題,而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應(yīng)不同帶寬條件下的播放。不過HLS的這種技術(shù)特點，決定了它的延遲一般總是會高于普通的流媒體直播協(xié)議。iOS和Android 都天然支持這種協(xié)議，配置簡單，直接使用 video 標(biāo)簽即可.

VLS：是一種流服務(wù)器，專門用來解決流的各種問題，它也具有一些 VLC 的特征。videolan 作為服務(wù)器可以輸出http，rtp，rtsp的流。

原則上，RTSP，RTMP，HTTP 都可以做直播和點播，但一般做直播用 RTSP 和 RTMP，做點播用 HTTP。我們選用的是RTMP協(xié)議。