正文開始
- 30-12之 RTP/RTCP 傳輸協議
- 30-13之 RTSP 傳輸協議
- 30-14之 RTMP 傳輸協議
- 30-15之 HLS 傳輸協議
- 30-16之 HTTP-FLV 傳輸協議)
- 30-17之 MPEG-DASH 傳輸協議)
前面的幾面文章,咱們學習了各種型的影音傳輸媒體,接下來將會在這一篇文章中,進行這些協議的總結。
各種影音傳輸協議之比較與整理
一張圖來簡單的理解各種協議的運作方式
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 這種 機上盒的應用,比較大的原因我覺得有兩個原因:
- 因為 RTSP 的特性就是控制流,也就可以快轉、停止等操作,非常適合 這種類型的應用。
- 因為 RTSP 可以基於 UDP 進行傳輸,而在專線上因為網路穩定,所以很適合使用。
RTMP
RTMP 這種協議,目前大部份都使用在網路直播應用中,主要的原因在於:
- 因為它的延遲低。
- 在直播產業剛起來時,大部份的裝置都有 Flash。
- 它支援推流。
HLS
HLS 這種協議,大部份都應用在直播與點播中,其中直播的應用它是屬於比較不重視延遲 的類型,也就是非互動直播,主要的原因在於:
- 非互動直播的原因在於,它的延遲高,所以他只適合那種,比賽直播啊、或是一些轉播的應用。
- 而點播,也就是由用戶決定要看啥的,不管延遲,所以他一定適合。
- 他也很適合在行動網路上看直播與點播,因為它可以動態的調整畫質,當你網路不好,它就會用較少解析度的影片。
HTTP-FLV
HTTP-FLV 這種應用目前都用於直播,點播事實上也可以使用,而且這個協議也慢慢將 HLS 與 RTMP 也替代掉囉,主要有兩個原因:
- 因為它延遲低。
- 因為它是用 Http 來傳輸,不會被一些東西擋。
- 它也支援動態的調整畫質。
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 )這些的到時還會慢慢的補上。