30-18 之影音傳輸協議總整理

正文開始

前面的幾面文章,咱們學習了各種型的影音傳輸媒體,接下來將會在這一篇文章中,進行這些協議的總結。

各種影音傳輸協議之比較與整理

一張圖來簡單的理解各種協議的運作方式

RTSP

RTMP

HLS

HTTP-FLV

MPEG-DASH

特點整理

協議 傳輸層選擇 聲音編碼 影像編碼 延遲性
RTSP RTP、TCP、UDP RTP 可支援的都行 RTP 可支援的東行
RTMP TCP AAC、MP3 H.26X 系列
HLS TCP (因為它是用 HTTP ) AAC、MP3 H.26X 系列
HTTP-FLV TCP (因為它是用 HTTP ) AAC、MP3 H.26X 系列
MEPG-DASH TCP (因為它是用 HTTP ) 沒啥限制,不過 AAC 用比較多 H.26X、VPX 系列

應用狀況

RTSP

RTSP 這種協議,大部份都是應用在一些有專線的應用,例如 IPTV 這種 機上盒的應用,比較大的原因我覺得有兩個原因:

  1. 因為 RTSP 的特性就是控制流,也就可以快轉、停止等操作,非常適合 這種類型的應用。
  2. 因為 RTSP 可以基於 UDP 進行傳輸,而在專線上因為網路穩定,所以很適合使用。

RTMP

RTMP 這種協議,目前大部份都使用在網路直播應用中,主要的原因在於:

  1. 因為它的延遲低。
  2. 在直播產業剛起來時,大部份的裝置都有 Flash。
  3. 它支援推流。

HLS

HLS 這種協議,大部份都應用在直播與點播中,其中直播的應用它是屬於比較不重視延遲 的類型,也就是非互動直播,主要的原因在於:

  1. 非互動直播的原因在於,它的延遲高,所以他只適合那種,比賽直播啊、或是一些轉播的應用。
  2. 而點播,也就是由用戶決定要看啥的,不管延遲,所以他一定適合。
  3. 他也很適合在行動網路上看直播與點播,因為它可以動態的調整畫質,當你網路不好,它就會用較少解析度的影片。

HTTP-FLV

HTTP-FLV 這種應用目前都用於直播,點播事實上也可以使用,而且這個協議也慢慢將 HLS 與 RTMP 也替代掉囉,主要有兩個原因:

  1. 因為它延遲低。
  2. 因為它是用 Http 來傳輸,不會被一些東西擋。
  3. 它也支援動態的調整畫質。

MPEG-DASH

DASH 基本上於 HLS 相似,基本上 HLS 可以使用的非互動直播與點播都可以選擇。

支援度

協議 支援度 web html5 支援度 ios 支援度 mac 支援度 android
RTSP 不支援,需使用套件。 不支援,需使用套件。 不支援,需使用套件。 不支援,需使用套件。
RTMP html5 不支援,需使用套件。 不支援,需使用套件。 不支援,需使用套件。 不支援,需使用套件。
HLS 支援 支援 支援 支援
HTTP-FLV 支援 (flv.js) 不支援,需使用套件。 不支援,需使用套件。 不支援,需使用套件。
MPEG-DASH 支援 (dash.js) 不支援,需使用套件。 不支援,需使用套件。 不支援,需使用套件。

結論

今天這篇文章將這幾個協議進行了簡單的總整理,但只是簡單的整理一下,不過這篇文章還會繼續的更新,包含上面提到的各平台支援度的套件支援,我會去調查清楚,又及更協議在那些實際上應用的項目( ex. Youtube 有在用 dash )這些的到時還會慢慢的補上。

comments powered by Disqus