流媒體是什么？

流媒體就是指采用流式傳輸技術在網絡上連續實時播放的媒體格式，如音頻、視頻或多媒體文件。

音視頻就是流媒體的核心。

音視頻組成

一個完整的視頻文件，包括音頻、視頻和基礎元信息。

我們常見的視頻文件如mp4、mov、flv、avi、rmvb等視頻文件，就是一個容器的封裝，

里面包含了音頻和視頻兩部分，并且都是通過一些特定的編碼算法，進行編碼壓縮過后的。

因此，視頻轉換需要設置的本質就是：

• 設置需要的視頻編碼
• 設置需要的音頻編碼
• 選擇需要的容器封裝

編碼格式

音頻編碼格式

• ACC
• AC3
• MP3

視頻編碼格式

• H.26x
• MPEG

MPEG簡介

MPEG-1	MPEG-1的視頻原理框圖與H.261的相似。（制定于1992年，主要應用在VCD制作格式）
MPEG-2	制定于1994年，主要應用在DVD/SVCD的制作壓縮方面。作了擴展和改進，如提升了分辨率，滿足了用戶高清晰度的要求，但由于壓縮性能沒有多少提高，存儲容量還是太大，也不適合網絡傳輸。
MPEG-4	制定于1998年，是為了播放流式媒體的高質量視頻而專門設計的。在低比特率壓縮上有著顯著的提高，更適合網絡傳輸。但由于系統設計過于復雜，很難在視頻會議、可視電話等領域實現，另外對于中國企業來說還有高昂的專利費問題。

H.26x簡介

H.261	在實時編碼時比MPEG所占用的CPU運算量少得多。只有I幀和P幀，沒有B幀，運動估計精度只精確到像素級。
H.263	在H.261基礎上，加入了PB幀預測，運動估計精度精確到半像素精度，性能優于H.261。
H.264	從編碼性能上看，H.264要遠優于MPEG-4，平均節約39%的傳輸碼流，這可以極大地提高存儲設備的效率和網絡利用率。在 H.265 出來之前，H.264是壓縮率最高的視頻壓縮格式，其優勢有：①低碼率：和MPEG2和MPEG4 ASP等壓縮技術相比，在同等圖像質量下，采用H.264技術壓縮后的數據量只有 MPEG2的1/8，MPEG4 的1/3。 ②高質量的圖像：H.264 能提供連續、流暢的高質量圖像（DVD質量） ③容錯能力強：H.264提供了解決在不穩定網絡環境下容易發生的丟包等錯誤的必要工具。 ④網絡適應性強：H.264 提供了網絡抽象層，使得 H.264的文件能容易地在不同網絡上傳輸。
H.265	又稱HEVC（High Efficiency Video Coding，高效率視頻編碼），是ITU-T H.264/MPEG-4 AVC標準的繼承者。帶寬成本：理論上，H.265最高只需H.264編碼的一半帶寬即可傳輸相同質量的視頻。更低的帶寬可以更好地降低存儲及傳輸成本。轉碼成本：當前主流瀏覽器均不支持H.265原生視頻播放，因此通常視頻生產端需要針對瀏覽器做一次H.264視頻的轉碼來適配瀏覽器端如PC場景的播放。

存儲封裝格式

目前市面常見的存儲封裝格式有如下：

• AVI（.avi）
• ASF（.asf）
• WMV（.wmv）
• QuickTime（.mov）
• MPEG（.mpg/.mpeg）
• MP4（.mp4）
• TS/PS

視頻碼率、幀率

碼率

碼流（Data Rate）是指視頻文件在單位時間內使用的數據流量，

是視頻編碼中畫面質量控制中心最重要的部分，一般我們用的單位是kb/s或者Mb/s。

一般來說，同樣的分辨率下，視頻文件的碼流越大，壓縮比就越小，畫面質量就越高。

碼流越大，說明單位時間內采樣率越大，數據流，精度就越高，

處理出的文件就越接近原始文件，

圖像質量越好，畫質越清晰，要求播放設備的解碼能力也越高。

當然，碼率越大，文件體積也就越大，其計算公式是 文件體積=時間x碼率/8。

通常來說，一個視頻文件包括了畫面（視頻）及聲音（音頻），

同一個視頻文件的音頻和視頻的比特率并不是一樣的，

而我們所說的一個視頻文件的碼率大小，一般是指視頻文件中音頻及視頻信息碼率的總和。

幀率

幀率也稱為FPS（Frames Per Second），是指每秒鐘刷新的圖片的幀數，

也可以理解為圖形處理器每秒鐘能夠刷新幾次。越高的幀速率可以得到更流暢、更逼真的動畫。

流媒體的傳輸方式

當前互聯網中的流媒體服務從傳輸方式上大體可以分為兩種方式：順序流式傳輸和實時流式傳輸。

順序流式傳輸

順序流式傳輸的實質就是播放本地文件，

好處主要是減輕了服務器的壓力，即當多媒體文件下載完成后就可以斷開連接，從而節省出服務器資源再為其他客戶端服務。

此外，順序流式傳輸使用的是普通的HTTP服務器，視頻服務商不必花費額外的資金購買流媒體服務器，從而節省了一筆經費。

實時流式傳輸

實時流式傳輸采用專門的流媒體服務器存儲多媒體文件，主要應用于網絡直播和正版影視的點播。

當客戶端發起連接想要觀看多媒體資源的時候，一般通過專有的實時流式傳輸協議把位于流媒體服務器上的多媒體數據直接傳輸給客戶端的播放器，再實時播放。

此外，使用實時流式傳輸方式觀看多媒體資源時，可以隨意跳轉到該音視頻的任何位置，而不必像順序流式傳輸那樣只能觀看已經下載過的部分，大大增加了觀看時的自由度。

流媒體的傳輸協議

協議解封裝

介紹流協議之前，先要介紹我們從云端拿到一份數據，要經過幾個步驟才能解析出最終需要的音視頻數據。

HLS

HLS（HTTP Live Streaming）是蘋果公司實現的基于HTTP短連接的流媒體傳輸協議，可實現流媒體的直播和點播。

HLS 點播

首先需要了解這一協議是以視頻切片的形式分段播放的，

協議中使用的切片視頻格式是TS，也就是我們前文提到的封裝格式。

在我們獲取TS文件之前，協議首先要請求一個M3U8格式的文件。

M3U8 是一個描述索引的文件，它以一定的格式描述了TS地址的指向，

我們根據M3U8文件中描述的內容，就可以獲取每一段TS文件的CDN地址，通過加載TS地址分段播放就可以組合成一整段完整的視頻。

HLS 直播

相對于常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，

HLS 直播最大的不同在于，直播客戶端獲取到的，并不是一個完整的數據流。

HLS 協議在服務器端將直播數據流存儲為連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷地下載并播放這些小文件，

小結

如果是HLS 點播，則只需要在初始化時獲取一次就可以拿到所有的TS切片指向；

如果是HLS 直播，則需要不停地輪詢M3U8文件，獲取新的TS切片，從而達到直播流播放的效果。

由于數據通過HTTP協議傳輸，所以完全不用考慮防火墻或者代理問題。

另外，切片播放的特性特別適用于點播播放中視頻清晰度、多語種的熱切換，

比如我們播放一個視頻，

起初選擇的是超清視頻播放，當我們看了一半覺得不夠流暢，需要換成標清的，

這時候只需要將超清的M3U8文件替換成標清的M3U8文件即可，不需要對視頻做重新初始化。

在直播場景下，HLS 也是一個比較常用的協議，

在移動端，將M3U8文件地址喂給video就可以直接播放，在PC端用MSE解碼后大部分瀏覽器也都能支持，

但由于其分片加載的特性，直播的延時相對較長，主要是以下三個原因：

1）服務端的編碼器和流分割器生成TS文件的時間

2）客戶端下載TS文件的時間，而通常要求下載完兩個TS媒體文件

3）客戶端解碼并播放時間

HLS中用到的TS封裝格式，視頻編碼格式通常是H.264或MPEG-4，音頻編碼格式為AAC或MP3。

HTTP-FLV

HTTP-FLV 是基于HTTP長連接來傳輸FLV封裝格式的一種協議。

FLV 是Flash Video的簡寫，是一種文件體積小，適合在網絡上傳輸的封包方式。

FLV 的視頻編碼格式通常是H.264，音頻編碼格式為ACC或MP3。

FLV 在延遲問題上相比切片播放的HLS會好很多，目前看來FLV的延遲主要是受編碼時設置的GOP長度的影響。

RTMP

RTMP 是基于TCP做的一套實時消息傳輸協議，經常與Flash播放器匹配使用。

RTMP 的封裝格式與HTTP-FLV一樣，都是FLV。

RTMP 協議的優缺點非常明顯，首先和HTTP-FLV一樣，延遲比較低；其次它的穩定性非常好，適合長時間播放。

但是主流瀏覽器漸漸都表示不再支持Flash player插件，在移動端H5基本屬于完全不支持狀態，兼容性是它最大的問題。

MPEG-DASH

MPEG-DASH 協議屬于新興勢力，與HLS一樣，都是通過切片視頻的方式進行播放。

由于同為切片視頻播放的協議，DASH優劣勢與HLS類似，

可以支持切片之間多視頻碼率、多音軌的切換，比較適合點播業務，在直播中還是會有延時較長的問題。

RTSP+RTP

RTSP（Real Time Streaming Protocol），即實時流傳輸協議。

RTSP 用于控制流媒體的傳輸，比如建立連接、播放、暫停等等，但本身并不傳輸多媒體數據。

多媒體數據通常是使用 RTP/RTCP 協議進行傳輸。

RTP/RTCP（Real Time Transport Protocol/Real Time Transport Control Protocol），即實時傳送協議/實時傳送控制協議。

RTP 協議本身只保證實時數據的傳輸，RTCP 協議則負責流媒體的傳輸質量保證，提供流量控制和擁塞控制等服務。

總結

以上是生活随笔為你收集整理的流媒体的基本介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。