音視頻&流媒體

才高八斗船帆ub 發佈 2022-12-10T07:20:13.710230+00:00

對一個技術人員而言,碼率這個種最基本的概率都沒整明白,簡直是奇恥大辱,開個玩笑。音頻編碼方案之間音質比較結果: AAC+ > MP3PRO > AAC> RealAudio > WMA > MP3。

音視頻&流媒體

是什麼促使我要寫這一篇音視頻&流媒體門的初級文章?那是因為和一妹子打賭碼率的概念,結果輸了;對一個技術人員而言,碼率這個種最基本的概率都沒整明白,簡直是奇恥大辱,開個玩笑。有了這個前提之後,發現,還是得多理解下原理和基礎入門知識。

流媒體背景

當下,音視頻、流媒體已經無處不在,直播已經火了幾年,在後續的時間裡面,人們聊天已經不僅僅滿足與文字、而是更多的在於「類面對面」交流,能夠實時感知對方的表情、動作。為此,有必要跟緊時代潮流,好好梳理梳理流媒體這門功課。

流媒體是什麼?流媒體就是指採用流式傳輸技術在網絡上連續實時播放的媒體格式,如音頻、視頻或多媒體文件。流媒體技術也稱流式媒體技術。那麼音視頻就是流媒體的核心。

音視頻常見術語定義規範

音視頻組成

一個完整的視頻文件,包括音頻、視頻和基礎元信息,我們常見的視頻文件如mp4、mov、flv、avi、RMVB等視頻文件,就是一個容器的封裝,裡面包含了音頻和視頻兩部分,並且都是通過一些特定的編碼算法,進行編碼壓縮過後的。

H264、Xvid等就是視頻編碼格式,Mp3、AAC等就是音頻編碼格式。例如:將一個Xvid視頻編碼文件和一個MP3音頻編碼文件按AVI封裝標準封裝以後,就得到一個AVI後綴的視頻文件。

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

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

一個完整的視頻轉換設置都至少包括了上面3個步驟。

編碼格式

音頻編碼格式

音頻編碼格式有如下

  • AAC
  • AMR
  • PCM
  • ogg(ogg vorbis音頻)
  • AC3(DVD 專用音頻編碼)
  • DTS(DVD 專用音頻編碼)
  • APE(monkey’s 音頻)
  • AU(sun 格式)
  • WMA

音頻編碼方案之間音質比較(AAC,MP3,WMA等)結果: AAC+ > MP3PRO > AAC> RealAudio > WMA > MP3

目前最常見的音頻格式有 MP3、AC-3、ACC,MP3最廣泛的支持最多,AC-3是杜比公司的技術,ACC是MPEG-4中的音頻標準,ACC是目前比較先進和具有優勢的技術。對應入門,知道有這幾種最常見的音頻格式足以。

視頻編碼格式

視頻編碼標準有兩大系統: MPEG 和ITU-T,國際上制定視頻編解碼技術的組織有兩個,一個是「國際電聯(ITU-T)」,它制定的標準有H.261、H.263、H.263+、H.264等,另一個是「國際標準化組織(ISO)」它制定的標準有MPEG-1、MPEG-2、MPEG-4等。

常見編碼格式有:

  • Xvid(MPEG4)
  • H264 (目前最常用編碼格式)
  • H263
  • MPEG1,MPEG2
  • AC-1
  • RM,RMVB
  • H.265(目前用的不夠多)

目前最常見的視頻編碼方式的大致性能排序基本是: MPEG-1/-2 < WMV/7/8 < RM/RMVB < Xvid/DIVX < AVC/H.264(由低到高,可能不完全準確)。


【騰訊文檔】FFmpegWebRTCRTMPRTSPHLSRTP播放器-音視頻流媒體高級開發-資料領取FFmpegWebRTCRTMPRTSPHLSRTP鎾斁鍣�-闊寵棰戞祦濯掍綋楂樼駭寮€鍙�-璧勬枡棰嗗彇


在H.265出來之前,H264是壓縮率最高的視頻壓縮格式,其優勢有:

  • 低碼率(Low Bit Rate):和MPEG2和MPEG4 ASP等壓縮技術相比,在同等圖像質量下,採用H.264技術壓縮後的數據量只有MPEG2的1/8,MPEG4的1/3。
  • 高質量的圖象 :H.264能提供連續、流暢的高質量圖象(DVD質量)。
  • 容錯能力強 :H.264提供了解決在不穩定網絡環境下容易發生的丟包等錯誤的必要工具。
  • 網絡適應性強 :H.264提供了網絡抽象層(Network Abstraction Layer),使得H.264的文件能容易地在不同網絡上傳輸(例如網際網路,CDMA,GPRS,WCDMA,CDMA2000等)。

H.264最大的優勢是具有很高的數據壓縮比率,在同等圖像質量的條件下,H.264的壓縮比是MPEG-2的2倍以上,是MPEG-4的1.5~2倍。舉個例子,原始文件的大小如果為88GB,採用MPEG-2壓縮標準壓縮後變成3.5GB,壓縮比為25∶1,而採用H.264壓縮標準壓縮後變為879MB,從88GB到879MB,H.264的壓縮比達到驚人的102∶1。低碼率(Low Bit Rate)對H.264的高的壓縮比起到了重要的作用,和MPEG-2和MPEG-4 ASP等壓縮技術相比,H.264壓縮技術將大大節省用戶的下載時間和數據流量收費。尤其值得一提的是,H.264在具有高壓縮比的同時還擁有高質量流暢的圖像,正因為如此,經過H.264壓縮的視頻數據,在網絡傳輸過程中所需要的帶寬更少,也更加經濟。

目前這些常見的視頻編碼格式實際上都屬於有損壓縮,包括H264和H265,也是有損編碼,有損編碼才能在質量得以保證的前提下得到更高的壓縮率和更小體積

存儲封裝格式

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

  • AVI (.avi)
  • ASF(.asf)
  • WMV (.wmv)
  • QuickTime ( .mov)
  • MPEG (.mpg / .mpeg)
  • MP4 (.mp4)
  • m2ts (.m2ts / .mts )
  • Matroska (.mkv / .mks / .mka )
  • RM ( .rm / .rmvb)
  • TS/PS

AVI : 可用MPEG-2, DIVX, XVID, WMV3, WMV4, AC-1, H.264 WMV : 可用WMV3, WMV4, AC-1 RM/RMVB : 可用RV40, RV50, RV60, RM8, RM9, RM10 MOV : 可用MPEG-2, MPEG4-ASP(XVID), H.264 MKV : 所有

視頻碼率、幀率、解析度

碼率

碼流(Data Rate)是指視頻文件在單位時間內使用的數據流量,也叫碼率或碼流率,通俗一點的理解就是取樣率,是視頻編碼中畫面質量控制中最重要的部分,一般我們用的單位是kb/s或者Mb/s。一般來說同樣解析度下,視頻文件的碼流越大,壓縮比就越小,畫面質量就越高。碼流越大,說明單位時間內採樣率越大,數據流,精度就越高,處理出來的文件就越接近原始文件,圖像質量越好,畫質越清晰,要求播放設備的解碼能力也越高。

當然,碼率越大,文件體積也越大,其計算公式是文件體積=時間X碼率/8。例如,網絡上常見的一部90分鐘1Mbps碼率的720P RMVB文件,其體積就=5400秒×1Mbps/8=675MB。

通常來說,一個視頻文件包括了畫面(視頻)及聲音(音頻),例如一個RMVB的視頻文件,裡面包含了視頻信息和音頻信息,音頻及視頻都有各自不同的採樣方式和比特率,也就是說,同一個視頻文件音頻和視頻的比特率並不是一樣的。而我們所說的一個視頻文件碼流率大小,一般是指視頻文件中音頻及視頻信息碼流率的總和。

幀率

幀率也稱為FPS(Frames Per Second)- - - 幀/秒。是指每秒鐘刷新的圖片的幀數,也可以理解為圖形處理器每秒鐘能夠刷新幾次。越高的幀速率可以得到更流暢、更逼真的動畫。每秒鐘幀數(FPS)越多,所顯示的動作就會越流暢。

關於幀率有如下幾個基礎數據:

  • 幀率越高,cpu消耗就高
  • 秀場視頻直播,一般幀率20fps
  • 普通視頻直播,一般幀率15fps

解析度

視頻解析度是指視頻成像產品所成圖像的大小或尺寸。常見的視像解析度有352×288,176×144,640×480,1024×768。在成像的兩組數字中,前者為圖片長度,後者為圖片的寬度,兩者相乘得出的是圖片的像素,長寬比一般為4:3.

480P : 640 x 480 個像素點 720P : 1280 x 720 個像素點 1080P : 1920 x 1080 個像素點

然後還需要關注每個像素點的存儲格式,每個像素點占用的字節大小。

圖像存儲格式yuv

一幅彩色圖像的基本要素是什麼?

1、寬:一行有多少個像素點。

2、高:一列有多少個像素點,一幀有多少行

3、YUV格式還是RGB格式?

4、一行多少個字節??

5、圖像大小是多少?

6、圖像的解析度多少?

說白了,一幅圖像包括的基本東西就是二進位數據,其容量大小實質即為二進位數據的多少。一幅1920x1080像素的YUV422的圖像,大小是1920X1080X2=4147200(十進位),也就是3.95M大小。這個大小跟多少個像素點和數據的存儲格式有關。

YUV與像素的關係:

YUV格式,與我們熟知的RGB類似,YUV也是一種顏色編碼方法,主要用於電視系統以及模擬視頻領域,它將亮度信息(Y)與色彩信息(UV)分離,沒有UV信息一樣可以顯示完整的圖像,只不過是黑白的,這樣的設計很好地解決了彩色電視機與黑白電視的兼容問題。並且,YUV不像RGB那樣要求三個獨立的視頻信號同時傳輸,所以用YUV方式傳送占用極少的頻寬。

YUV格式有兩大類:planar和packed。對於planar的YUV格式,先連續存儲所有像素點的Y,緊接著存儲所有像素點的U,隨後是所有像素點的V。對於packed的YUV格式,每個像素點的Y,U,V是連續交替存儲的。

YUV,分為三個分量,「Y」表示明亮度(Luminance或Luma),也就是灰度值;而「U」和「V」 表示的則是色度(Chrominance或Chroma),作用是描述影像色彩及飽和度,用於指定像素的顏色。    

YUV是利用一個亮度(Y)、兩個色差(U,V)來代替傳統的RGB三原色來壓縮圖像。傳統的RGB三原色使用紅綠藍三原色表示一個像素,每種原色占用一個字節(8bit),因此一個像素用RGB表示則需要8 * 3=24bit。

如果使用YUV表示這個像素,假設YUV的採樣率為:4:2:0,即每一個像素對於亮度Y的採樣頻率為1,對於色差U和V,則是每相鄰的兩個像素各取一個U和V。對於單個的像素來說,色差U和V的採樣頻率為亮度的一半。如有三個相鄰的像素,如果用RGB三原色表示,則共需要占用:8 * 3 * 3 = 72bits;如果採用YUV(4:2:0)表示,則只需要占用:8 * 3(Y)+ 8* 3 * 0.5(U)+ 8 * 3 * 0.5(V)= 36bits。只需原來一半的空間,就可以表示原來的圖像,數據率壓縮了一倍,而圖像的效果基本沒發生變化。

那麼,具體yuv格式所占用的字節數要怎麼算呢 ?

YUV圖像格式的內存大小

  • 4:4:4 表示色度值(UV)沒有減少採樣。即Y,U,V各占一個字節,加上Alpha通道一個字節,總共占4位元組.這個格式其實就是24bpp的RGB格式了。
  • 4:2:2 表示UV分量採樣減半,比如第一個像素採樣Y,U,第二個像素採樣Y,V,依次類推,這樣每個點占用2個字節.二個像素組成一個宏像素.
    • 需要占用的內存:w * h * 2
  • 4:2:0 這種採樣並不意味著只有Y,Cb而沒有Cr分量,這裡的0說的U,V分量隔行才採樣一次。比如第一行採樣 4:2:0 ,第二行採樣 4:0:2 ,依次類推...在這種採樣方式下,每一個像素占用16bits或10bits空間.
    • 內存則是:yyyyyyyyuuvv
    • 需要占用的內存:w * h * 3 / 2
  • 4:1:1 可以參考4:2:2分量,是進一步壓縮,每隔四個點才采一次U和V分量。一般是第1點采Y,U,第2點采Y,第3點采YV,第4點采Y,依次類推。

幀率、碼率與解析度之間關係

碼率和幀率沒有半毛錢關係

碼率關係著帶寬、文件體積

幀率關係著畫面流暢度和cpu消耗

解析度關係著圖像尺寸和清晰度

一個視頻文件的大小為5.86M,播放時長為3分7秒

  • 1,該文件對應的碼率就是
    • 5.86 * 1024 * 1024 * 8 / (3 * 60 + 7) = 262872.95657754bps
  • 2,10M獨享帶寬能支撐的同時在線人數
    • 10 * 1024 * 1024 / 262872.95657754 = 39.889078498294
  • 3, 支撐1000人同時在線的系統最少需要的帶寬數為
    • 262872 * 1000 / (1024 * 1024) = 250.69427490234M

10min,流量消耗41587KB

41587/10*60 = 69KB/s = 69 * 8 Kb/s = 532Kb/s

那麼得到碼率就是 532Kb/s

輸出文件大小公式

一個音頻編碼率為128Kbps,視頻編碼率為800Kbps的文件,其總編碼率為928Kbps,意思是經過編碼後的數據每秒鐘需要用928K比特來表示。

文件大小公式: (音頻編碼率(KBit為單位)/8 + 視頻編碼率(KBit為單位)/8)× 影片總長度(秒為單位)= 文件大小(MB為單位)

一幀圖像大小

一幀圖像原始大小 = 寬像素 * 長像素 ,當然要考慮數據格式,因為數據格式不一樣,大小寫也不相同,一般數據採用rgb、yuv格式,如rgb32、yuv420、yuv422等。最常用的應當屬於yuv420。 因此,計算公式為:

文件的字節數 = 圖像解析度 * 圖像量化位數/8 圖像解析度 = X方向的像素數 * Y方向的像素數 圖像量化數 = 二進位顏色位數

  • RGB24每幀的大小是
    • size=width×heigth×3 Bit
  • RGB32每幀的大小是
    • size=width×heigth×4
  • YUV420每幀的大小是
    • size=width×heigth×1.5 Bit

舉例說明,對於一個1024*768的圖像實際的YUV422數據流大小就為:1024 *768 * 2 = 1572864bit

音頻採樣率、位數

1、聲道數:聲道數是音頻傳輸的重要指標,現在主要有單聲道和雙聲道之分。雙聲道又稱為立體聲,在硬體中要占兩條線路,音質、音色好, 但立體聲數位化後所占空間比單聲道多一倍。

2、量化位數: 量化位是對模擬音頻信號的幅度軸進行數位化,它決定了模擬信號數位化以後的動態範圍。由於計算機按字節運算,一般的量化位數為 8位和16位。量化位越高,信號的動態範圍越大,數位化後的音頻信號就越可能接近原始信號,但所需要的存儲空間也越大。

3、採樣率:也稱為採樣速度或者採樣頻率,定義了每秒從連續信號中提取並組成離散信號的採樣個數,它用赫茲(Hz)來表示。採樣率是指將模擬信號轉換成數位訊號時的採樣頻率,也就是單位時間內採樣多少點。一個採樣點數據有多少個比特。比特率是指每秒傳送的比特(bit)數。單位為 bps(Bit Per Second),比特率越高,傳送的數據越大,音質越好.

採樣率的選擇應該遵循奈奎斯特(Harry Nyquist)採樣理論( 如果對某一模擬信號進行採樣,則採樣後可還原的最高信號頻率只有採樣頻率的一半,或者說只要採樣頻率高於輸入信號最高頻率的兩倍,就能從採樣信號系列重構原始信號 )。根據該採樣理論, CD雷射唱盤採樣頻率為 44kHz,可記錄的最高音頻為 22kHz,這樣的音質與原始聲音相差無幾,也就是我們常說的超級高保真音質。通信系統中數字電話的採用頻率通常為 8kHz,與原 4k帶寬聲音一致的。

比特率(音頻) = 採樣率 x 採用位數 x 聲道數.

以電話為例,每秒3000次取樣,每個取樣是7比特,那麼電話的比特率是21000。 而CD是每秒 44100次取樣,兩個聲道,每個取樣是13位PCM編碼,所以CD的比特率是44100213=1146600,也就是說CD每秒的數據量大約是 144KB,而一張CD的容量是74分等於4440秒,就是639360KB=640MB。

I幀、P幀、B幀、IDR幀

I幀:幀內編碼幀

I幀特點:

  1. 它是一個全幀壓縮編碼幀。它將全幀圖像信息進行JPEG壓縮編碼及傳輸;
  2. 解碼時僅用I幀的數據就可重構完整圖像;
  3. I幀描述了圖像背景和運動主體的詳情;
  4. I幀不需要參考其他畫面而生成;
  5. I幀是P幀和B幀的參考幀(其質量直接影響到同組中以後各幀的質量);
  6. I幀是幀組GOP的基礎幀(第一幀),在一組中只有一個I幀;
  7. I幀不需要考慮運動矢量;
  8. I幀所占數據的信息量比較大。

P幀:前向預測編碼幀

P幀的預測與重構:P幀是以I幀為參考幀,在I幀中找出P幀「某點」的預測值和運動矢量,取預測差值和運動矢量一起傳送。在接收端根據運動矢量從I幀中找出P幀「某點」的預測值並與差值相加以得到P幀「某點」樣值,從而可得到完整的P幀。又稱predictive-frame,通過充分將低於圖像序列中前面已編碼幀的時間冗餘信息來壓縮傳輸數據量的編碼圖像,也叫預測幀

P幀特點:

  1. P幀是I幀後面相隔1~2幀的編碼幀;
  2. P幀採用運動補償的方法傳送它與前面的I或P幀的差值及運動矢量(預測誤差);
  3. 解碼時必須將I幀中的預測值與預測誤差求和後才能重構完整的P幀圖像;
  4. P幀屬於前向預測的幀間編碼。它只參考前面最靠近它的I幀或P幀;
  5. P幀可以是其後面P幀的參考幀,也可以是其前後的B幀的參考幀;
  6. 由於P幀是參考幀,它可能造成解碼錯誤的擴散;
  7. 由於是差值傳送,P幀的壓縮比較高。

B幀:雙向預測內插編碼幀。

B幀的預測與重構:B幀以前面的I或P幀和後面的P幀為參考幀,「找出」B幀「某點」的預測值和兩個運動矢量,並取預測差值和運動矢量傳送。接收端根據運動矢量在兩個參考幀中「找出(算出)」預測值並與差值求和,得到B幀「某點」樣值,從而可得到完整的B幀。 又稱bi-directional interpolated prediction frame,既考慮與源圖像序列前面已編碼幀,也顧及源圖像序列後面已編碼幀之間的時間冗餘信息來壓縮傳輸數據量的編碼圖像,也叫雙向預測幀

B幀特點:

  1. B幀是由前面的I或P幀和後面的P幀來進行預測的;
  2. B幀傳送的是它與前面的I或P幀和後面的P幀之間的預測誤差及運動矢量;
  3. B幀是雙向預測編碼幀;
  4. B幀壓縮比最高,因為它只反映丙參考幀間運動主體的變化情況,預測比較準確;
  5. B幀不是參考幀,不會造成解碼錯誤的擴散。

IDR 幀

IDR(Instantaneous Decoding Refresh)--即時解碼刷新。

I和IDR幀都是使用幀內預測的。它們都是同一個東西而已,在編碼和解碼中為了方便,要首個I幀和其他I幀區別開,所以才把第一個首個I幀叫IDR,這樣就方便控制編碼和解碼流程。IDR幀的作用是立刻刷新,使錯誤不致傳播,從IDR幀開始,重新算一個新的序列開始編碼。而I幀不具有隨機訪問的能力,這個功能是由IDR承擔。IDR會導致DPB(DecodedPictureBuffer參考幀列表——這是關鍵所在)清空,而I不會。IDR圖像一定是I圖像,但I圖像不一定是IDR圖像。一個序列中可以有很多的I圖像,I圖像之後的圖像可以引用I圖像之間的圖像做運動參考。一個序列中可以有很多的I圖像,I圖像之後的圖象可以引用I圖像之間的圖像做運動參考。

對於IDR幀來說,在IDR幀之後的所有幀都不能引用任何IDR幀之前的幀的內容,與此相反,對於普通的I-幀來說,位於其之後的B-和P-幀可以引用位於普通I-幀之前的I-幀。從隨機存取的視頻流中,播放器永遠可以從一個IDR幀播放,因為在它之後沒有任何幀引用之前的幀。但是,不能在一個沒有IDR幀的視頻中從任意點開始播放,因為後面的幀總是會引用前面的幀。

小結

I幀表示關鍵幀,你可以理解為這一幀畫面的完整保留;解碼時只需要本幀數據就可以完成(因為包含完整畫面).

P幀表示的是這一幀跟之前的一個關鍵幀(或P幀)的差別,解碼時需要用之前緩存的畫面疊加上本幀定義的差別,生成最終畫面。(也就是差別幀,P幀沒有完整畫面數據,只有與前一幀的畫面差別的數據).

B幀是雙向差別幀,也就是B幀記錄的是本幀與前後幀的差別,換言之,要解碼B幀,不僅要取得之前的緩存畫面,還要解碼之後的畫面,通過前後畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高,但是解碼時CPU會比較累~。

PTS:Presentation Time Stamp。PTS主要用於度量解碼後的視頻幀什麼時候被顯示出來

DTS:Decode Time Stamp。DTS主要是標識讀入內存中的bit流在什麼時候開始送入解碼器中進行解碼。

DTS主要用於視頻的解碼,在解碼階段使用.PTS主要用於視頻的同步和輸出.在display的時候使用.在沒有B frame的情況下.DTS和PTS的輸出順序是一樣的.

GOP

兩個I frame之間形成一個GOP,在x264中同時可以通過參數來設定bf的大小,即:I 和p或者兩個P之間B的數量。如果有B frame 存在的情況下一個GOP的最後一個frame一定是P.

一般平均來說,I的壓縮率是7(跟JPG差不多),P是20,B可以達到50,可見使用B幀能節省大量空間,節省出來的空間可以用來保存多一些I幀,這樣在相同碼率下,可以提供更好的畫質。在碼率不變的前提下,GOP值越大,P、B幀的數量會越多,平均每個I、P、B幀所占用的字節數就越多,也就更容易獲取較好的圖像質量;Reference越大,B幀的數量越多,同理也更容易獲得較好的圖像質量。

如果一個GOP裡面丟了I幀,那麼後面的P幀、B幀也將會無用武之地,因此必須丟掉,但是一般策略會保證I幀不丟(如通過tcp協議保證) ,如果採用UDP,那麼也會有更多的策略來保證I幀正確傳輸。

編解碼

硬編解碼

通過硬體實現編解碼,減輕CPU計算的負擔,如GPU等

軟編解碼

如 H264、H265、MPEG-4等編解碼算法,更消耗CPU

數據優化

數據優化和編解碼算法息息相關,一般而言

視頻幀大小

  • 一般I 幀的壓縮率是7,P 幀是20,B 幀可以達到50 (數據不精確)
  • P幀大概是3~4KB (480P, 1200k碼率, baseline profile)

音頻幀大小

  • (採樣頻率(Hz)* 採樣位數(bit)* 聲道數)/ 8
  • 48000hz大概經過AAC壓縮後,應該是12KB/s左右

流媒體傳輸協議

常用的流媒體協議主要有 HTTP 漸進下載和基於 RTSP/RTP 的實時流媒體協議,這二種基本是完全不同的東西

CDN直播中常用的流媒體協議包括RTMP,HLS,HTTP FLV

RTP,RTCP

實時傳輸協議(Real-time Transport Protocol),RTP協議常用於流媒體系統(配合RTCP協議),視頻會議和一鍵通系統(配合H.323或SIP),使它成為IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一起使用,而且它是建立在UDP協議上的。

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

RTSP+RTP經常用於IPTV領域。因為其採用UDP傳輸視音頻,支持組播,效率較高。但其缺點是網絡不好的情況下可能會丟包,影響視頻觀看質量。

小結

RTMP

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

它有三種變種:

  • 工作在TCP之上的明文協議,使用埠1935;
  • RTMPT封裝在HTTP請求之中,可穿越防火牆;
  • RTMPS類似RTMPT,但使用的是HTTPS連接;

總結: RTMP協議基於TCP來實現,每個時刻的數據,收到後立刻轉發,一般延遲在1-3s左右

HLS

HTTP Live Streaming(HLS)是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議,可實現流媒體的直播和點播。HLS點播,基本上就是常見的分段HTTP點播,不同在於,它的分段非常小。基本原理就是將視頻或流切分成小片(TS), 並建立索引(M3U8).

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

總結: HLS協議基於HTTP短連接來實現,集合一段時間數據,生成ts切片文件,然後更新m3u8(HTTP Live Streaming直播的索引文件),一般延遲會大於10s

HTTP-FLV

HTTP-FLV基於HTTP長連接,通RTMP一樣,每個時刻的數據,收到後立刻轉發,只不過使用的是HTTP協議,一般延遲在1-3s

CDN

CDN架構設計比較複雜。不同的CDN廠商,也在對其架構進行不斷的優化,所以架構不能統一而論。這裡只是對一些基本的架構進行簡單的剖析。

CDN主要包含:源站、緩存伺服器、智能DNS、客戶端等幾個主要組成部分。

源站:是指發布內容的原始站點。添加、刪除和更改網站的文件,都是在源站上進行的;另外緩存伺服器所抓取的對象也全部來自於源站。對於直播來說,源站為主播客戶端。

緩存伺服器:是直接提供給用戶訪問的站點資源,由一台或數台伺服器組成;當用戶發起訪問時,他的訪問請求被智能DNS定位到離他較近的緩存伺服器。如果用戶所請求的內容剛好在緩存裡面,則直接把內容返還給用戶;如果訪問所需的內容沒有被緩存,則緩存伺服器向鄰近的緩存伺服器或直接向源站抓取內容,然後再返還給用戶。

智能DNS:是整個CDN技術的核心,它主要根據用戶的來源,以及當前緩存伺服器的負載情況等,將其訪問請求指向離用戶比較近且負載較小的緩存伺服器。通過智能DNS解析,讓用戶訪問同服務商下、負載較小的伺服器,可以消除網絡訪問慢的問題,達到加速作用。

客戶端:即發起訪問的普通用戶。對於直播來說,就是觀眾客戶端。

弱網優化

弱網優化的策略包括如下:

  • 播放器Buffer
  • 丟幀策略 (優先丟P幀,其次I幀,最後音頻)
  • 自適應碼率算法
  • 雙向鏈路優化
  • 音頻FEC冗餘算法(20%丟包率)

丟幀

在弱網情況下,為了達到更好的體驗,可能會採取丟幀的策略,但是丟幀,怎麼丟呢?丟音頻幀還是視頻幀呢 ? 因為視頻幀比較大,並且視頻幀前後是有關聯的;音頻幀很小,關鍵是音頻幀是連續採樣的,丟了音頻幀,那聲音就會明顯出現瑕疵。為此,一般的丟幀策略是丟視頻幀

自適應碼率

在弱網情況下,另外一種靠譜的策略是自適應碼率算法,通過設置碼率降級為多個檔次,這樣,當網絡不好的情況下,通過降低碼率進行預測,如果碼率降低後,還不夠buffer緩衝,那麼繼續降低一個檔次,是一個循環探測的過程,如果再次降級一個檔次後,發現buffer緩衝足夠了,那麼說明當前網絡能夠適應這個碼率,因此就會採取當前碼率。同理,升檔也是一樣的。但是這個屬於廠商的核心算法,

實時聊天的挑戰

簡單估算一下大概的網絡延時。眾所周知,光在真空中的速度約為300,000km/s,而在其他介質中光 速會大大降低,所以在普通光纖中,工程上一般認為傳輸速度是200,000km/s。從現實上來說,可以參考如下:

實時聊天的挑戰主要在於以下幾點:

  • 實時性: 600ms以內
  • 網絡的不對稱性
  • 距離

常見問題和解決方案

  • 出現花屏、綠屏問題
    • 採集問題、編解碼問題、聲網傳輸丟幀問題
  • 聲畫不同步
    • 採集問題,或者公有雲SDK問題
  • 畫面有時候有點糊
    • 弱網,碼率的自適應
  • 有聲音沒有畫面
    • 弱網,觸發了丟幀策略
  • 畫面播放有時候卡頓
    • CPU消耗過高導致卡頓,比如AR模塊
    • 弱網
  • 網絡連接不上
    • 弱網
    • 或者代碼有Bug,或者公有雲SDK有Bug
  • 出現馬賽克現象?
    • 是否類似花屏 ?

作者:AllenWu

關鍵字: